I'm working on a UWP app (C++/WinRT) that must communicate extensively with a background process. Unfortunately, the background process must remain a full trust "Win32" process. Both are packaged in an MSIX.
For performance and programmability reasons, my first choice would be to turn the background process into an out-of-process WinRT component. App Services is a possibility but not ideal.
I've found numerous code samples for creating an OOP WinRT component via WRL. However, activation is performed via CoreApplication::RunWithActivationFactories(), which (as far as I know) requires an AppContainer.
I know I can consume a WinRT component in a Win32 process. Can I create one? If so, what would activation look like in C++/WinRT?
Yes, from the Windows 10 Version 1903, May 2019 Update, the windows have added support for non-packaged desktop apps to make use of user-defined (3rd party) Windows Runtime (WinRT) Components, which means that we can consume a Winrt component from the Win32 process directly. To successfully reference a C++ Windows Runtime component from a Win32 app, you need to use C++/WinRT to generate projection header files of your component. You can then include these header files in your app code to call your component.
For the detailed information, please refer to this article:
https://blogs.windows.com/windowsdeveloper/2019/04/30/enhancing-non-packaged-desktop-apps-using-windows-runtime-components/.
For the detailed sample, please refer to here:
https://github.com/microsoft/RegFree_WinRT/tree/master/Cpp.
Thanks.
Related
I want to share an image file between Desktop application and the windows store application. What is the best way to do the communication between the desktop app and the windows store app.I have tried creating the shared memory between the apps, but i think this is not possible( Reference ).
It's not possible to communicate and share date directly, except launching via protocol handler. As Aniruddha already said sharing via Filesystem (e.g. pictures library) is a convenient way to do it.
If you are on Windows 8.1 and don't have the requirement to put your application in the public Windows Store there's another option:
Windows Runtime Brokered Components. This is quite awesome stuff. It allows you to freely communicate between a Windows Store App and any other application. It is documented here: https://msdn.microsoft.com/en-us/library/windows/apps/dn630195.aspx
The setup isn't exactly easy but it is very powerful. Keep in mind that you won't get this app published into the public Windows store, if you're using brokered components.
I haven't tried Brokered Components on Windows 10 yet, I'm not sure if this is still supported.
Recently I began working in WinRT for Windows Store Apps (and the upcoming Windows 10 Universal Apps) using C#. After working in .NET for awhile previously, I was excited to work with .NET on mobile devices, only to find that WinRT did not feel like home at all.
Constantly I find myself having to search for alternatives to certain classes that I'm familiar with in .NET since often they're not the same or even implemented in WinRT. I figure that the lack of implementation derives from the fact that WinRT at its core is unmanaged, even though the CLR binds to it from managed code.
My question is: What is stopping Microsoft from allowing developers to import and use all of the familiar .NET classes from managed code, even with WinRT running from behind? I know it's not a limitation of the device because my Surface Pro can run desktop .NET apps just fine and the Mono project has succeeded in porting almost the entire .NET API to devices of every kind.
Thanks for your input!
This is a big topic but there are three basic reasons why you don't get the full .NET API from a Windows Store app.
The APIs don't fit on smaller devices like phones. Since the purpose of the Universal Windows Platform is to have apps that can run everywhere, it can't include APIs that are too resource-intensive (disk, memory, CPU, etc.) to run on smaller devices. (Note that even if the managed API appears to be small, it might have a dependency on a large underlying Win32 API).
The APIs aren't compatible with the Store app model. Many APIs that require permissions not granted to Store apps fall into this category, as do APIs that would enable apps to do "unwanted" things to your machine (the degree of "unwantedness" is subjective).
The APIs are deprecated or there are newer alternatives. This was the case with a lot of APIs in Windows 8, where things like file-system access and network sockets were blocked from Store apps because there were newer WinRT equivalents.
Note that Microsoft is always open to re-evaluating whether a specific API should be included or not. For example, Windows 10 brings back many APIs that were banned from Windows 8.1 (such as System.IO and System.Net.Sockets) and has expanded the capabilities granted to apps. You can file feedback via the Windows Feedback app or on UserVoice if you want additional APIs brought back (adding detailed justification never hurts).
I have created a Flex Desktop Application with Adobe Air.
I need to protect the application from being captured. By changing the window display affinity of the application, the application can be protected from being captured.
How to use win API in flex?
Is there any other way to protect the window from being captured?
First you have to make sure that the main window does not have the WS_EX_LAYERED Windows style. That style makes SetWindowDisplayAffinity fails with code 8 (ERROR_NOT_ENOUGH_MEMORY), at least on my machine (Seven Pro 64 bits). In your -app.xml file, set the value to false for the node <transparent> under <initialWindow>.
Second, you have to choose how to inject a regular C DLL in the application process, as the API will fail with error 5 (ERROR_ACCESS_DENIED) if you try to change the affinity of a window not living in the caller process.
One possible injection method is using the SetWindowsHookEx API. Google will give you many hits about that one. Feel free to ask for some details. You obviously needs cooperation of another process, here (and some Win32 APIs practice).
Another possible way is coding an 'ACTIONSCRIPT® Extensions for ADOBE® AIR®' (PDF).
The later seems preferable:
No collaboration from an external process needed.
Adobe AIR does the DLL loading for you.
C/C++ code much more simple.
I used the first technique, as I am more fluent in raw Win32 APIs about DLL, than I am with AIR and Action Script...
I successfully tested that first technique with a very simple "Hello World" AIR Desktop application, and get a nice "All Black" image after Print Screen.
I want to add analytics to my Windows Phone 8 app and that's all fine except I now want to trace when my background agent triggers a specific event.
Does App Insights support this?
I'd like to say that Application Insights does support the scenario you are describing. Recent versions of the Application Insights should support background tasks. However, you should use the "core" package, and not the full platform package.
This core package provides all the APIs needed to send telemetry to AppInsights. It doesn't provide any of the automatic context or telemetry collection, and hence doesn't have any dependencies (for example on the dispatcher) which allows it to work on a background task.
We would love to hear more about how this scenario is working out for you.
I need to wrap a C library with Adobe AIR native extension API (ANE).The extension should target IOS and Android.First,I realize that for Android , if not using NDK API , I have to port that library to Java.But my main concern is IO operations like read and write to file system which exist in that library.I read through the ANE development manual but found no note on restriction of native lib communication with the host file system.Does it mean my native library is allowed to read and write files inside AIR extension freely ?
You definitely can access the filesystem to read and write files.
The only thing of note here is that you'll only have access to the parts of the filesystem that the application has permission to access. So you basically just have to obey any restrictions that a normal native application developer has.
I've used the java.io.File to access files in ANE's no problem.
Based on what I see scanning through that too it reads to me like it's doable but I can't confirm 100%
When you create a native extension, you provide the following:
ActionScript extension classes that you define. These ActionScript classes use the built-in ActionScript APIs that allow access to and data exchange with native code.
A native code implementation. The native code uses native code APIs that allow access to and data exchange with your ActionScript extension classes.
sounds to me like you have whatever native API available for writing your native extension in and they're just providing a "bridge" or "data tunnel" to communicate between the actionscript code and the native extension. They have one import from the android library for log in their example as well so I imagine you can use whatever objects/methods are available for each platform, I suppose the only real question is then what access the native process has on the file system for each platform. If you don't get an answer please try and post back (if I have time I'll do the same).