Flash and Audio Hooking - c++

I'm trying to capture the audio which an activeX flash component is playing.
I do this by finding the flash.ocx module and hook the waveOutWrite function.
This seems to work well, however I cannot differentiate between different activex instances which call waveOutWrite internally as the audio seems to come from the same thread and target the same output device.
My question is how I could differentiate between who is calling waveOutWrite?
I think the answer lies in somewhere in loading a flash.ocx instance for each activex instance, not sure how to achieve that though as the module loading is handled automatically by COM. One idea I had was to create the activex components in different processes, which hopefully would cause the waveOutWrite function to be called from different threads. However, this seems to be a rather complicated way to achieve this.
Any ideas?

I am really surprised that several OCX instances share the same thread. I could have sworn that they get unique ones. Hence my previous [deleted] answer.
May I ask: why are you playing several sounds at once? Is that absolutely necessary? Or, if the other OCX instances are playing "mute" sound, you could identify them by looking into the waveform buffer. Or possibly, other data in the WAVEHDR struct, perhaps dwUser...

Related

Is it possible to get a list of processes that's doing actions on an application? (eg, bot on a game client controlling it)

Like title,
Is it possible in some way to get processes that are hooked to your application?
Either directly, or via DLLs?
My application is written in C++ and it can obtain processes, windows, and DLLs just fine.
But I noticed that some "bots" can connect to it, without leaving an obvious DLL-trace which makes me forced to find other solutions on how to track bots.
You don't have to know anything about bots or so.. any answers to my primary question are very appreciated no matter your experience.
Thanks in advance!

capture audio from specific program [duplicate]

I am taking my first dives in to the WASAPI system of windows and I do not know if what I want is even possible with the windows API.
I am attempting to write program that will record the sound from various programs and break each in to a separate recorded track/audio file. From the reseacrch I have done I know the unit I need to record is the various audio sessions being rendered to a endpoint, and the normal way of recording is by taking the render endpoint and performing a loopback. However from what I have read so far in the MSDN the only interaction with sessions I can do is through IAudioSessionControl and that does not provide me with a way to get a copy of the stream for the session.
Am I missing something that would allow me to do this with the WASAPI (or some other windows API) and get the individual sessions (or individual streams) before they are mixed together to form the endpoint or is this a imposable goal?
The mixing takes place inside the API (WASAPI) and you don't have access to buffers of other audio clients, esp. that they don't exist in the context of the current process in first place. Perhaps one's best (not so good, but there are no better alternatives) way would be to hook the API calls and intercept data on its way to WASAPI, if the task in question permits dirty tricks like this.

How to implement low latency keyboard/mouse input for UWP application?

I got stuck at this basic matter.
I can't find any other way to obtain input but through CoreWindow class (handling KeyDown/KeyUp/PointerMoved events or calling GetKeyState in the loop).
I thought that I had to deal with input device directly, but it turns out that interactions with generic HID devices are blocked for UWP applications.
There is also a "low latency" sample among UWP samples, that uses some twisted method through creating dedicated XAML control, but it seems more like a method to coexist with XAML rendering loop while I'm dealing with non-xaml application.
Maybe someone knows a good workaround for this?

How can I communicate between two C++ MFC plugins?

I have a plugin for a c++ MFC app. I'm working with the developer of another plugin for the same app, that's trying to get notifications of events in my code. Both plugins are in the form of c++ dlls.
How can I pass messages from my plugin to his plugin? The solution needs to be robust to mismatched versions of our two plugins, as well as the host app. The notifications are during control point movement, so several times a second.
I could set up a callback mechanism, where upon load his plugin calls a function in my plugin with a function pointer. We're not guaranteed any loading order, but we could probably just check periodically.
I know Win32 has a messaging system, but I'm not sure how it works, really. We could add a hook, and I could send messages, but I'm a bit fuzzy on how we'd synchronize what the message id is, or any details other than what I said, really.
Any other ideas on how to do this?
I'm a bit fuzzy on how we'd synchronize what the message id
Use the RegisterWindowMessage API.
Take a look at this article here, it shows the available IPC mechanisms in windows. I might try COM, Mailslots, Pipes or Shared Memory (file mapping) in your case, in addition to windows messages which you already mentioned.

Easiest way to create a drawing canvas from within a C++ dll?

The scenario is such: there's a program which loads my .dll/.so and calls a function from within it, possibly multiple times, each time expecting a different pointer to state. It uses the different states later in other calls into the dll. (It's a game AI, if you need context; each state is a AI player.)
What I want is a cross-platform way of creating a canvas window for each of those states (for visualization, debugging, etc.) I tried wx, but put it on hold, since it didn't appear to be easy at all. Are there any neat and small libraries that could do that or should I just go with WinAPI/X...?
Edit: Assume I cannot modify the host program.
Qt is simpler to set up and drive than Wx, in my experience. It's very cross platform too.
If you want to render some graphics from inside your DLL function without passing in any pointers to QImage or QWidget type things, probably the thing to do is use OpenGL. Your DLL should just render to the current OpenGL context, which is global state and can just be setup outside the DLL (maybe using QGLWidget).
Update: Ah, I just noticed your edit re not being able to modify the host code. This is a problem: any windows you create really need to be plugged into the host apps' event loop to work properly (e.g receive WM_PAINT when exposed/resized). It's certainly possible in win32 for any old code (e.g your library) to just CreateWindow and draw its contents with GDI whenever it gets the chance, but the general window behaviour may be pretty broken (it may not work at all with Vista's double buffering; I haven't tried). What I typically find easiest in this situation is simply to dump out image files and review then afterwards with image viewer of choice. IMHO this is actually more useful for debugging than a "live" window because you can step backwards and forwards, zoom in, apply image-enhancement to highlight various issues, compare against previous runs for regression testing etc etc. (If you really want the "live" views, write an image displayer which monitors a directory for new images, or streams them through a named pipe or something).
If you just want simple graphics, no widgets, SDL is very easy to use. If you do need complex controls, use Qt, as timday said.
You might check out IUP. It interfaces really well with Lua, and can be used entirely from an extension DLL there so it seems plausible that its C API could be used from a DLL plugged into something else.
IUP will get you a framework for opening a window containing the usual suspect kinds of controls, including a canvas. Its related library CD will give you the usual drawing operations in that canvas.
Current releases are portable between Windows and *nix. The next major release will support MacOSX too.