Is it possible to open or to manage at all Windows 8 apps (e.g. the built-in Mail or News app) via WinAPI functions from a desktop program?
With 'manage', I mean to open, close, snap (to left and right) or to enumerate Windows 8 apps.
I know that apps can register for special URI schemes so they can be opened by a link (and probably via ShellExecute() and related functions), but what if they don't?
I've just found a blog post of Ashwin Needamangala in a Win8 App Dev blog which covers app activation and automating lifecycle states with C++, WinAPI and COM: http://blogs.msdn.com/b/windowsappdev/archive/2012/09/04/automating-the-testing-of-windows-8-apps.aspx
Enumeration works via the PackageManager class.
Opening an app is possible using the IApplicationActivationManager interface.
And if you're the one who opened it and you have a handle, you can probably call TerminateProcess on it, too, but I haven't tried that one.
Edit: we open-sourced our apprunner utility, it can install, run and uninstall packages and shows the use of PackageManager and IApplicationActivationManager.
Apart from that, other interaction (i.e. snapping/unsnapping) doesn't seem to be possible from the outside.
Related
I want to get CLSID for Control Panel and Add or Remove Programs on Windows XP.
Example:
shell:::{26EE0668-A00A-44D7-9371-BEB064C98683} - only works from Vista (Control Panel).
Any suggestions how to get it?
I want to get CLSID for Control Panel
You can use shell:ControlPanelFolder instead of CLSID which is supported on Win XP.
You may also get the folder location via SHGetSpecialFolderLocation() by passing CSIDL_CONTROLS for parameter nFolder.
and Add or Remove Programs
Raymond Chen has a blog post, where he comments:
Windows NT/2000/XP doesn't have a "Programs and Features" folder, so
the question is moot. If you mean "enumerate all installed
applications", there's no built-in way of doing this. You have to
mimic what "Add/Remove Programs" does, which is messy because
Add/Remove Programs enumerates apps from some places that may not be
obvious (like the MSI store).
I am developing an application on Windows 10 that interacts with custom device drivers, the NTFS filesystem and DirectX 12. The app is a Windows Universal App written in C++, WRL, XAML and DirectX. For DirectX I have chosen a SwapChainPanel control and the DirectX portion of the app works great. The app is Sideloaded so I have a bit more freedom than an app that needs to go through the store
Unfortunately the Windows Universal Apps have a number of restrictions with regards to API calls. WinRt APIs are favored.
Here are a list of WinRt APIs to call to replace Win32 APIs:
https://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx
In addition Windows Universal Apps can call Win32 APIs that are partitioned to the application (however not the ones partitioned to the desktop) as indicated in the documentation of each function and in the header file. Here is a link:
https://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx
In addition the Winsock APIs are now allowed from Windows Universal Apps
However I am still left without my favorite (and necessary APIs)
CreateFile()
ReadFile()
WriteFile()
DeviceIoControl()
CloseHandle()
In particular I need to read and write files to all locations without user interaction (and not to the locations restrict by the Windows Universal App Sandbox). In addition I need to send IOCTLs to my multiple device drivers.
I could abandon Windows Universal Apps and go with WPF. However I have a touch intensive application and I need touch to work really well. In addition I have to wonder about the lack of fixes and commitment to WPF on the behalf of Microsoft. I have considered other UI frameworks but none have been as promising as a Windows Universal App.
Microsoft has allowed two paths in Windows 10 for Universal Apps that will allow calling all Win32 functions (For side loaded apps).
Brokered Windows Runtime Component
and IPC though TCPIP
I have written a brokered windows runtime component and it works well. However the solution requires a C# app to be in the mix and I do not need/want that as I need fast load times of the app and do not want to pull the CLR in.
The next option is IPC through TCPIP. I would use Fast TCP Loopback as explained in the blog post: Fast TCP Loopback Performance and Low Latency with Windows Server 2012 TCP Loopback Fast Path. I would link to it but I am at my (very generous) two link limit for a first post.
I have a couple of questions:
1) If I go this route should I place the IPC between the XAML controls/buttons and the rest of the App? This would allow the rest of the app to be strictly Win32. Or should I just place the IPC between the app and calls to the specific functions I need that fall outside of the those allowed by Win32.
2) I have looked for a library or paper that has code and/or ideas for implementing IPC with TCPIP. However so far the papers that talk about IPC with TCPIP seem to simply describe winsock programming which is something I already know how to do. I would enjoy coding up IPC but would prefer a solution that has been tested. This needs to work flawlessly and I would rather have code with some time on it. Has anyone used or heard of code and or a design for IPC over TCPIP that is available to share?
I'm trying to attempt to build a UI similar to the ones coming out of Microsoft these days. Particularly those targeting the Windows 10 operating system (a la Office 2016).
Currently I use WinAPI, but all of the controls provided by Windows.h and CommCtrl.h appear to be legacy/old style UI elements. I'm particularly looking for the titlebar/menu/status bar elements (the main clientarea will consist of a GDI/Direct2D context, so nothing special necessary there).
I found some information pointing to XAML, but I don't think that's what I want. WPF seems to be a more likely candidate, but I'm not sure if that's the case either.
I would like for this to be 100% native (WinAPI/C&C++), but if there's absolutely no other option I can use C# for the UI and stub in the native code.
You use XAML and either C++, C# or JavaScript to write a Windows Store (previously Metro) app. If you use C++, the app is 100% native, but if you use C# or JavaScript, of course the required virtual machine is used.
The API that your code calls is WinRT, which looks like Silverlight. In addition, your app can also call some, but not all, Win32 API's similar to how .NET apps can call Win32 (e.g. By using P/Invoke). However, even if you use C++ and thus your app is 100% native, it is still sandboxed like a browser. Meaning it cannot do things like access the entire disk or write to HKLM in the registry. This is for security; a Windows Store app needs to be safe, and thus more limited, like a mobile app you buy from the Apple AppStore. This means that you can't call e.g. CreateFile. This says:
Minimum supported client
Windows XP [desktop apps only]
When MS mentions 'Desktop Apps' as above, they mean Win32 apps. This excludes Windows Store Apps. But this is confusing, because on Win 8/8.1, these Windows Store apps are full screen, but on Windows 10 they are resizeable and overlapping, appearing next to, and mixed in with traditional Win32 apps like Explorer and Task Manager. So even though they appear on the same desktop as Desktop apps, they are not Desktop apps.
I believe if a Windows Store app also targets Windows Phone 10, Windows IoT, etc. then it is called a Windows Universal app.
I need to customize right click so that I can scan a directory with my anti-virus. I know how to do that using registry keys, but the problem is that I don't want to start a new instance of my program every time I want to scan a directory. My anti-virus needs to load some signature databases so it will take around 15 seconds for the program to load those. I need to use the instance of the program which I have already opened and is running for scanning the directory. How can I do that?
I am using C++Builder.
Thanks.
Considering you already know how to add the item to the right click contextual menu, I suggest implementing a client/server set of applications:
A server that loads up when you turn your computer on and does the scanning, and
The client that tells it what to do using IPC - inter-process communication.
You then add the client application to various contextual menus, passing it arguments that indicate what it should get the server to do depending on what you right-clicked on.
IPC is a bit of a pain in the butt, the easiest way is to use TCP/IP to and do local networking using a network library. There are many out there, however given you'll likely want to have other features such as UI elements and a tray icon, I suggest you look at Qt, namely the following components:
QtNetwork: For performing communication between the client and the server executable.
QSystemTrayIcon: For displaying a small icon on the tray.
There are quite a few other little bits of Qt you'll no doubt encounter (like all the fabulous UI stuff), and fortunately Qt is well documented and help is always available here, and from the Qt Developer Network. You can get started with Qt by downloading and installing the SDK:
http://qt.nokia.com/downloads/
Best of luck :).
Implement a DDE server in your anti-virus, and then add a ddeexec subkey to your Registry key. Alternatively, add an OLE Automation object to your app that implements the IDropTarget interface, and then add a DropTarget subkey to your Registry key that specifies the object's CLSID.
Either way, whenever your menu item is then invoked, Windows will call into your existing app instance if it is already running, otherwise it will launch a new instance and then call into it. Either way, Windows is handling all of that for you. All you are doing is providing an entry point for Windows to call into.
I would suggest the IDropTarget method, because DDE is deprecated, and because IDropTarget is more flexible. While your app is running, you could re-use the same IDropTarget object to handle OLE Drag&Drop operations on your app's UI window and Taskbar button, and support automated invokations of your scanner by other apps.
I'm trying to understand event hooks in C++. I know what an event is, I've used them a lot in Java, C# and Javascript.
What I'm having trouble with is finding the documentation, and tutorials on stuff like global hooks, dll injection, global hooks without a DLL.
Lets say that I wanted to iterate through the browser tabis in FireFox .. would I need to hope that FireFox has an API for C++? Or lets say I wanted to do something when a user opens a new tab would I need to use a hook that FireFox would provide in their API?
The above is just an example so people know what I'm trying to learn/understand. Am I thinking on the right ines?
I seen a post on a forum and for the past 2 hours I've took an interest. I always say that a tricky challange, or a new challange, makes a stronger programmer.
Any resources, or any help, would be very much appreciated.
C++ itself does not have events or hooks, but a lot of C++ libraries and frameworks implement them. For an example of generic events library, see Boost.Signals.
Some of the implementations allow their events to be seen by other applications, but the API is application-specific (e.g. for Firefox, see XPCOM).
Windows has a mechanizm of hooks that allows to monitor various events in its windowing system. However, it is an OS feature, not related to C++. As it's a system mechanizm, all Windows applications are affected even if they don't do anything for it. The documentation for Windows hooks can be found here. Also, since you mentioned "global hooks without a DLL", see SetWinEventHook, which is a higher-level API than Windows hooks linked above and can be used with hook functions both implemented in DLLs or EXEs.
Look up MSDN for SetWindowsHookEx. It should be your entrance in Windows hooks. If you ar etargetting a parituclar window for mthe system then a less intrusive option is SetWindowLongPtr. For the first API you are going to need some Dll injection - which gets automatically for you by the system. Just follow these steps:
Create a Dll that exports a HOOKPROC function (actual type dependent upon the hook tpe - read in the docs)
Load that Dll in your application and retrieve a pointer to the HOOKPROC function. LoadLibrary / GetProcAddress APIs may be used for this.
From your application, make a call to SetWindowsHookEx feeding in the appropriate parameters - this will inject the dll in the target process. So, the dll is now loaded into both your app's process and in the target process. So you will need a mechanism to IPC between the two processes probably. Lots of ways here - sockets, pipes, shared segment in DLL, filesystem, windows messages, COM servers + events, etc etc.
The former API, while less powerful, does not require DLL injection.
Choose wisely & good luck!
I dont think firefox would be having a C++ aPI to find the open tabs....
If you want to find out open tabs or whenever a new tab is open , you can basically hook the firefox window and get all events happening on that window to your hook procedure.
If you open spy++ in VC++ and track firefox window , you can see a new MozillaContentWindowClass gets created every time whenever a new tab is opened. So you can basically iterate through window handles and get information about open tabs.
You can use SetWindowLongPtr to set the subclass procedure for that window.