So I have been trying to create something like discord game activity: When you open an app, discord displays it as the game you are currently playing. Now I don't want to query all open applications every second, so I was wondering whether there were alternatives like a callback when an application starts(I don't own the program, so I can not modify it). At first, I would like it to work on windows, but if you have solutions for other platforms I won't mind. I'm also using electron.js
You will get a loads more callbacks than you might expect from anything in win32 land that notifies you that a process has started. There used to be such an api a long way back [http://www.rohitab.com/discuss/topic/40418-process-notification-on-81/?p=10093378] . So... The only way I suspect you can do it now is through DDL hooking - which as far I recall requires admin privilege to install the hook. It's pretty low level thing to want to do here, so you will need to be writing some IPC code to talk between your hook and your Electron app. Probably a decent place that lays out your options is here https://www.apriorit.com/dev-blog/679-windows-dll-injection-for-api-hooks Note: Most AV will want to flag your app as malicious depending on which route you do follow.
Related
I am making an app for my cousin that blocks apps at certain times of the day. I am trying to setup an easy gui based approach to block apps that is intuitive and easy to use. I get all of the apps from the start menu folders, then get their corresponding executables, and then put them in a grid list so that from the apps user interface, the user can add app and remove applications easily.
Unfortunately, some apps aren’t quite so easy… If an app has an updater app for it, most often, the shortcut in the start menu will refer the the updater app, then the updater will check for updates, apply updates, then run the program. But with my system, it would automatically pick up the updater program as the blocked app, not the actual app. That’s why I want to be able to see what program started another program. Then I can see if a program was started by the updater, then I will know that it is part of the app too, and I should block that app aswell.
I am pretty sure that this is possible, but I don’t know how to do this in rust. This forum says it should be possible: https://superuser.com/questions/541210/find-what-process-started-another-process.
The sysinfo crate should be helpful here - if you know the name of the app you want to block, you can use the list of all processes to find the process you want to block and find its parent process. You may have to repeat this traversal a few times to find the original launching process, but be wary about what process are blocking - you may find your way back to an OS/root process which you definitely don't want to block.
I need to check if an app is making a certain sound. This app only produces a single specific sound, so a solution that simply checks if there's any sound whatsoever from the app will also work.
I don't need to find out which app makes a sound or anything like that. I know the app that should produce a sound and I know what sound it's going to be, I simply need to detect the exact time this sound is played.
The only solution I know of is to listen to the audio output for the whole OS and then detect my specific sound with some audio recognition software, but it won't work properly if there's music or a movie playing on the background, so it's not an option.
I need a solution to do it via WinAPI methods. The language isn't very important here - I can use C#, javascript, Python or another language. I just need to find out a general approach on how to extract sound produced by a specific application in Windows 7.
The general approach here is to trace calls from a given process to OS to play audio. These calls are more commonly known as "system calls".
This will show only direct attempts by a process to produce sound.
The only hardest part here is to identify all the system calls, that play sound in windows.
This question has some answers on how to trace system calls on Windows
Have you looked at SO answer on similar topic with a bunch of useful .Net wrappers for IAudioSessionManager2 and related API: Controlling Application's Volume: By Process-ID
I think that general approach of
Finding IAudioSession by process name
Subscribing to its events via IAudioSessionEvents
Listening to the OnStateChanged event
should do it for you.
And don't forget that you should pump Windows messages which might require some explicit code in non-UI applications. In UI applications this is what Application.Run does internally anyway.
I have a situation which would be easily solved if we were using android as originally designed (and partially coded). Unfortunately, we're going the MS C++ on Windows Enterprise route because of some vital legacy applications. Basically we're coding a launcher that needs to start an application and when that application is closed, the user is brought back to the previous application (the one that launched the 2nd application). I hope that makes sense.
I know this can be done because I vaguely recall an application I used in college for taking exams did something like this, but when I do a search all I get are android solutions. Any help or links to libraries to look at will be wonderful.
there are may ways here are 2 most obvious:
most easy and safe way is that launched application send message to launcher that it is closing
but you need to add code to that application
you can use windows messaging or mailbox or semaphores or whatever else.
launcher periodically checks if there is active window handle of the right class/type/GUID.
if not then pop up the restore/maximize or visibility and set focus to it self.
you need to know what class is that app of yours
of course if there are more apps of the same class/id/type/GUID this way you cannot know which one is which
I'm currently working on a Backup Application, and I have received a lot of requests for features to be added recently, and the top one of them is adding a checkbox like "Back Up when on Battery Power" like Time Machine has.
So, is there a way I can get the status of the Power Adapter (plugged in and plugged in)? I assume that if one had a Desktop Mac, like iMac, etc, I would probably just get Plugged In all the time. Therefore, I need means of detecting if the computer is a portable or not.
I assume IOKit would be a library to look at, but I simply could not find anything in the docs, that are barely existent anyways on that Framework. Then, since it is an older Carbon Framework, is there a way to register a callback that gets called when that power state changes? That way I can properly implement this checkbox's functionality.
I'd appreciate help in clarifying this subject.
IOPowerSources.h has the functions you need. Start with IOPSNotificationCreateRunLoopSource() to create a run loop source and in your callback interrogate the power source info starting with IOPSCopyPowerSourcesInfo() and working your way down. There may be better examples, but this file appears to be a reasonable demonstration of how it's done; enough to get you started.
So I have this program that I really like, and it doesn't support Applescript. I'd like to automate it a little bit. Now, I know that I could use applescript to tell the program to tell the menu to tell the submenu to tell the menuitem to activate or whatever, but frankly I don't like applescript very much anyway.
When I open the NIB file in IB, I can see the messages that are being sent to FirstResponder; for example, the Copy menu item sends "copy:". Is there any way for me to invoke this directly from another program?
No. It's called protected memory for a reason, you know. The other program is completely insulated from your application. There are ways to put code into other apps, but (a) it's very inadvisable (b) requires root privileges, which means the rest of your app needs to be ROCK SOLID AND IMPREGNABLE, and (c) writing such code is a black art requiring knowledge of the operating system kernel interfaces, virtual memory management, the ABI, the internals of the linker/loader, assembler programming, and the operational parameters and other specifics of the particular processor upon which your app happens to be running.
Really, AppleEvents and other such IPC mechanisms are there for a reason.
Your other alternatives (all of which are a bit hacky, to be honest, and give you the fairly significant burden of ensuring the target app is in the state you want/expect) the access the data you're looking for are:
The Accessibility APIs from the ApplicationServices framework, through which you can traverse the UI tree to grab the text from wherever you need it directly, or can activate the menu item. Access for your app has to be explicitly granted by the user, however (although this is much the same as the requirement for UI scripting).
You can use the CoreGraphics APIs (within the ApplicationServices framework again) to send keyboard events to the target application (or just to the system) directly. This would mean sending four events: Command-down, C-down, C-up, Command-up.
None of these are ideal. To be honest, your best approach would be to look at your requirements and figure out how you can best engineer around the problem by changing those requirements in some way, i.e. instead of grabbing something directly, ask the user to provide some input, etc.
You might be interested in SIMBL or in mach_inject. SIMBL is a daemon (in my fork based on mach_inject, in the original version based on injection via some ScriptingAdditions hack) which does the injection for you, so you just need to put a bundle with your code into the SIMBL directory and SIMBL will inject it for you into the target application. Or you can do so yourself via mach_inject. Or probably more convenient, mach_inject_framework which injects and runs code which just loads some framework.
I think Jim may overstate the point a bit; he's not wrong, but it seems misleading. There are lots of ways to cause a Cocoa program to execute its own code under you control (Carbon is harder). The Accessibility API is very commonly used this way (so commonly that I expect it to be repurposed eventually). Fscript can give you all kinds of access to the innards of another Cocoa program. While Input Managers may well exit the scene at some point, SIMBL is still out there today to do this kind of stuff.
Whether you like Applescript or not, Apple Events are the primary way Apple provides for inter-program control. Have you double-checked Script Editor's Open Library function to find out if the program really does have any Applescript support? You can code Apple Events entirely in Objective-C these days using Leopard's Scripting Bridge. I wrote up a tutorial if you like (it's still under-documented by Apple).
Cocoa is a reverse-engineer's dream. The same guys who host SIMBL have a nice intro to the subject. "Wolf" also writes a lot of useful information on this.
Jim's right. Many of these approaches can completely destabilize the system if done incorrectly (sometimes even if done correctly). I don't do much of this stuff on my production systems; I need them to work. But there are a lot of things you can make a Mac app do, and it's a good part of a Mac developer's training to understand how all the pieces really work.