I would like to know if it is possible to mute only a specific window. For example I have got Firefox open and two more windows. I want to mute everything related to Firefox but not the whole sound of my computer.
Is this possible? If so, how can it be done?
look, basically, there isn't any relation between the window handle and the sound which something in its code is playing.. the audio card can't tell who wants it to play.
theoretically, there is an option to do what you want on web browsers, but it's not easy, and not 100%. it goes like this:
most of the audio that is playing from browsers are from known objects like wmp/quick time/vlc/flash/etc..
when the user will choose to mute all audio from firefox, your application will search those known objects in the firefox tabs, and mute/unmute them using their api.
in order to do that, you will need to write an extension to firefox, so you could have an access to the tabs memory from your application.
btw, what os?
and check this out: http://www.indev.no/?p=projects#flashmute (flashmute) i believe it does what is said - only for flash.
On Vista/Windows 7:
I expect there to be some API which can change the volume on a per process basis which the audiomanager uses. Should be relatively straight forward to use.
On XP
I don't think there is any built in functionality for what you want to do. I recommend just not offering that feature on XP. But if you really want to, there are some hackish solutions:
Usermode API hooking. Intercept the calls to audioapis with your own functions. These change the volume or manipulate the audiosignal so you get what you want. You need to do this differently for any of the several available audio-apis. I guess DirectSound and DirectShow are particularly annoying. And this requires injection of a dll into any process you want to manipulate. And this dll better not require the .net runtime. Search for IAT(import address table) or EAT(export address table) hooking.
Kernel mode audio hooking. Write a driver which intercepts the audio in the kernel and changes it on a per process basis. No clue how to do that.
But as you can see both solutions aren't good.
Related
I am making a C# app to capture graphic from an avermedia pcie capture card.
But it seems that there are no out of box tools to do so.
So I made a C++ directshow app to do the capture, which is a console app and opens a capture window when running.
How can I redirect the output to a C# app? for example, to a CaptureElement?
So you want to have XAML CaptureElement connected to AverMedia PCIe capture card. This sounds like a well-understood challenge overall, however every other piece of technology you mentioned is eventually a bad choice: DirectShow, multiple apps with piping, redirection and fitting of cutsom code to XAML CaptureElement control.
Microsoft has intentionally been limited ways you can integrate different APIs and so there are not so many ways to get everything together.
Let us go over the supposed integration path. The capture card is supposed to be shipped with a compatible driver:
Video capture devices are supported through the UVC class driver and must be compatible with UVC 1.1
When this is the case, such devices are visible to Media Foundation API handling video capture among tasks. XAML CaptureElement would be able to see a video capture device through this API and this way everything is supposed to work without need to fit anything from your end.
If this is not happening, it suggests you are dealing with an unsupported device coming without suitable or compatible driver.
Previous media API in Windows was DirectShow but its days are gone. It remains perfectly working as a legacy framework, a lot of applications out there are still relying on it. Specifically it will not integrate with new technology like XAML and UWP. More to that, even Media Foundation itself, the current media API, in its public offering is lagging behind when it comes to fitting with most recent technology. Having said that it is a good idea to stay well clear of DirectShow here if this is at all possible.
I see no need for cross-process design with video travelling between process through piping. There is no good reason for such design and even though this can work efficiently (Windows itself proves it can work great in terms of performance by having so called Frame Server service in it), this is not to be built on piping. In your case it is unlikely to be have to be built on multiple processes either. Instead you can develop a native code DLL project that takes care of video acquisition and connects to managed code via suitable glue layer: C++/CLI, COM, C++/WinRT and such.
Then next thing is fitting to XAML CaptureElement. The control is designed to work with Windows.Media.Capture.MediaCapture class that talks to hardware and you don't have suitable hardware as you plan to implement your own acquisition layer. Long story short you are not supposed to forward external data to CaptureElement and you would have hard time doing this. Your best strategy is to upload externally obtained data to Windows.Graphics.Imaging.SoftwareBitmap or alike and take involved performance impact as acceptable. That is, you will be dealing with video frames as images.
An alternative way is to upload acquired video frames into Direct 3D 11 textures and it would open you a more performant way of integration with video related controls, such as Windows.UI.Xaml.Controls.SwapChainPanel however it would also require that you put much more development effort in there.
i need to block any screen capture software on the computer from taking screen shots. Since all of them are work on standard API-functions, i think i could monitor and block them.
I need to use C#.
All i have found is how to monitor and block them in a certain program (screen capture program). They are looking for a function in the program, then they change it address on mine function address.
But how can i do it, if i haven't any certain programs? I need to block anyone which tries to take a screenshot.
If your final goal is possible or not I don't know, but for the hooking the API portion I can help you out.
I have used the library EasyHook many times in the past, this will let you hook and intercept system function calls from C# code fairly easily. Just read through the PDF tutorial for setup instructions.
For actually finding the API's I recommend Rohitab's API Monitor, it's still in Alpha stages but it works really well and is free. You just hook it on to a processes and it tells you every external DLL call it makes (with the parameters it passed if you have the xml definition file for the DLL, the program comes with almost all of the windows API dll's pre-defined).
The combination of EasyHook and API Monitor is a great 1-2 punch for mucking with other program's calls.
It is not possible to prevent screenshots from being taken. The battle is already lost because of the DWM (Desktop Window Manager). It's lower level than Win32 and device contexts.
If you want to protect the text in your program, there are a lot easier ways to extract it than doing screenshots and OCR. TextOut and/or Direct2D hooking and accessibility APIs.
If there's a lot of IP in your program. Then don't make it all available onscreen. Make sure it's tedious to crawl the GUI for text, and hard to automate it. And don't load whole texts in memory of the program.
Possible solutions:
1. To prevent copying of text. Draw the text as an image.
2. To prevent accessibility technologies, like screen readers - override WndProc in your control, handle and ignore the window message WM_GETOBJECT.
3. To make it harder if they try to use OCR. Draw graphics behind the text. Human readable, but much harder for a machine to interpret it.
Neither of these methods are invasive for the user.
** A very invasive suggestion **:
If you are really serious about preventing anyone from "stealing" your content.
Implement mouse and keyboard hooks. Filter out typical copy shortcuts. Prevent the mouse from leaving the boundaries of your application.
Allow your application to only run when the OS runs well-known processes and services.
If any process starts which you don't recognize, black out the application and notify the user about it, and request the user to close it. And ofc make sure someone is not just spoofing a well-known process.
Monitor the clipboard as you suggested yourself.
You can ofc soften some of these suggestions based on the context of your application.
As Scott just posted it likely can be prevented with API hooks to see that paint events only go to desktop bound handles and not others, and refuse to paint otherwise. However, you need to consider the following scenarios and see if they're relevant threat to your approach or not:
Your software may be running in a virtual machine like VMWare. Such software has capapbilities to capture screen that does so at "virtual hardware" level, and your API hooks will not be able to discern it - and this would be the easiest way approach if I wanted to bypass your protections.
As a post suggests here, nothing also prevents someone to take monitor cable and plug it into another computer's capture card, and take screenshot that way. Again, your hooks will be helpless here.
Bottom line, you can make it somewhat harder to do, but bypassing such protection may be pretty trivial thing to do.
My 2c.
I am making a program and I want to find and mute programs that are playing audio so all you hear is mine.
(This is an option for the program, nothing malicious about it)
I have looked it up and I cannot seem to find a way to check what programs are playing audio (Much like windows does)
I don't have any code examples of attempting this because id has no idea.
In case someone misses reads or I don't word the above sentences correct I would like to find EVERY process with audio playing and either KILL or MUTE the process
If you can get Peak meters for individual programs on Windows 7, you can identify sessions and applications. IAudioSessionControl interface offers you muting options similar to what user can do via standard Volume Mixer application (session muting in particular).
There was a pretty similar question, maybe the same approach I posted in my answer would fit your scenario: https://stackoverflow.com/a/14828598/674700. What you'd need to change are the types of files (into .mp3, .wav and so on) and kill the processes found, with the exception of your application's.
The drawbacks: you'll need to run your application as administrator and it also requires a third party console app.
We are developing a platform with Windows CE 5 (soon to be upgraded to 6) in .Net CF 2 C#.
What we have recently discovered is that if we are touching the touchscreen while using our peripheral, the peripheral data trafic times out and our application crashes. So it seems like the touchscreen is blocking it. As a quick fix we would like to disable the touchscreen while using the peripheral, and the reenabling it.
So our question is, how do we do it?
Do we need some extra packages in the OS build or can we do it manually. We have had a look at touchpaneldisable() and touchpanelenable(...). But the enable method requires a handle to the callback function. So I have no idea on how to fix this.
From an application perspective tehre really isn't a fix. Touchpanel ddrivers a re alittle different than otehrs becasue they get loaded by (and into) GWES, rather than device.exe. They are not designed to be disabled and enabled, though some OEMs do provide the capability (typically by just masking the touch panel interrupt).
It sounds like the touchpanel sampling rate is really high and the device is saturating the processor when it startes sampling. It's something that the OEM probably needs to fix. Some OEMs do provide registry entries to adjust the driver behavior, so check with them to see if this might be available to you. In that case you may be able to fix the issue yourself.
If you have the BSP you might want to go through this blog post as it suggest possible bottle necks for the touch driver.
Using ExternalInterface in AS3 is it possible to call OS (C#?) functions within XP?
Example: Set the desktop background to a image supplied by a flash app?
If it is possible would it be different calls when applied to different OS. And what about cross over the Mac?
Any information would be great
Thanks
If you're launching the swf from within a C# app, external interface will do just fine. Nothing will change on the flash side, but you'll need to go through a couple hoops to get it to work in C#. It's not as simple as AMF or External Interface to JS.
All the communications to C# get converted to XML describing the data, and you've gotta write XML to send back to flash. Other than that though, its relativly simple.
Here's some info on how to do it. The AS portion is Flash 8/AS2, but the C# portion should say the same.
When working with Flash from a webpage or as a desktop app, you are limited to a small security sandbox and you will not be able to make any relevant OS call. I thought that switching to AIR would give the developper more flexibility but it doesn't seem correct either. From "The Pros and Cons of Adobe Air":
AIR apps have
file access, clipboard access, support
multiple windows, support drag and
drop, and can trigger notifications
(toast in Windows). If you app needs
to interact with the desktop in other
ways, the chances are that AIR is not
suitable. For example, there is no
access to COM automation, and no way
to execute external applications. The
reason is to maintain cross-platform
compatibility. That's a worthy goal,
but it would be good to have a way out
of the sandbox. Unlike Java or .NET,
you cannot extend AIR with custom
native code libraries. Nor can you
call operating system APIs.
As Alex Jillard commented, if your swf is called inside a C# desktop application, you should be able to access more OS funcionalities although I'm not sure how.
You could use as already mentioned AIR. Another idea would be to use HippoHX (I haven't written this, the similarity with my username is just coincidence). It runs on top of the NekoVM and gives you unrestricted (so no limitations like in AIR ) access to the system.