Is it possible call a legacy Win32 API from a UWP app written using C++/WinRT? I'm trying to call a legacy API from BluetoothApis.h.
Is this possible? App is a pure desktop app. Tks.
The only Win32 APIs that are supported from a UWP app are listed here.
All other Win32 legacy APIs are not available, which means:
The WINAPI_FAMILY_PARTITION macros in the headers won't define the declaration for those unsupported functions, so use of them will result in a compile-time error.
If you tried to use one of those legacy Win32 APIs anyway, then when you submitted to the Windows Store the WACK tool would detect it and fail the application.
If you try to run the unsupported UWP app on some other Device Family than Desktop (i.e. Xbox One), those legacy Win32 imports will likely be missing.
If you misconfigure the WINAPI_FAMILY macro or locally declare unsupported functions, only-side load because you never try to submit to the Store, and only attempt to run it on a Desktop PC, then the function may or may not work anyhow. It depends on how the Win32 legacy function reacts to the restricted ACLs of the AppContainer process context that all UWPs run in.
TL;DR: No, you can't use BluetoothAPis.h in a UWP app
#pragma region Desktop Family
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
.. all functions and types in BluetoothApis.h are here...
#endif /* WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP) */
#pragma endregion
Related
Our Mac application can (sadly) only build and run in 32bit-only. Reason is: a huge bunch of very old 32bit-only C++ code shared with other platforms (Windows, Android, Linux, etc.). This is cross server-client networking-protocol code, so it can't really be replaced. Until EVERYONE needs is 64bit, we're bound to build our app 32bit only.
Now I'm building a new module for this application as an external private dynamic framework. I'd like to use ARC, and the new niceties of modern Obj-C runtime, but these are only available in 64bit-only builds.
So… Could my 32bit Mac Application link, and use, and load a 64bit-only framework?
Well, I found the answer, which is on the whole --- NO.
Here are the details, and a work-around.
First off, a 32bit process can’t load 64bit code. The linker complains when you try to link the 64bit-only framework to your 32bit app.
I was offered two ways around this, both rely on parting the 32bit-only code and the 64bit-only code into 2 different processes, talking using XPC.
The first way would be to create a "host" 64bit process that will load my 64bit framework, and the 32bit application can then use XPC to talk to it.
The second option would be to extract all the 64bit-unsafe code (things I MUST compile 32bit-only) and put THAT in a special 32bit-only process then I can make my application 64bit only on Mac, add the new framework, and talk via XPC to the 32bit helper process.
Marmalade SDK supports making projects to generate arm-shared-libs. It also supports loading "libraries" via its s3eLibraryOpen(). However these seem to only be able to open x86 PE images that can also be generated with Marmalade SDK, but obviously as soon as I get a symbol and try calling the function it will crash since it's x86 and the calling process is ARM.
So just to re-iterate, the question is: Is there any support in Marmalade SDK for dynamically loading arm shared libraries at runtime?
s3eLibraryOpen will allow you to load dynamic libraries on platforms that support it as as well as the dynamic library built for that platform Android (.so),Windows(.dll) , IOS does not support it.
I'm trying to use Cirrious.MvvmCross.Plugins.Network.Reachability on Windows Phone 8. I have added the Network Plugin to my WP8 project and my core. The plugin bootstrapper has been added to the Bootstrap folder. I'm trying to pass an IMvxReachability in the constructor of one the dependencies of my View Model. When I run the app, I get this exception..
Failed to load ViewModel for type MyNamespace.MyViewModel from locator MvxDefaultViewModelLocator
Not all plugins and not all interfaces are available on all platforms.
Reachability was added to iOS because it was a requirement from the App Store.
The same interface is not currently available on any other platforms.
If you need to get hold of the implementation of an interface which might not always be available, then the ways to do this currently are using:
if (Mvx.CanResolve<T>())
myT = Mvx.Resolve<T>();
or (better):
Mvx.TryResolve<T>(out myT);
There is currently an open issue (feature request) to allow optional parameters for IoC construction - see https://github.com/slodge/MvvmCross/issues/239
There are currently no open requests for Reachability - native APIs do exist (sometimes with app-capability protection flags), but most Droid and Windows apps don't test for network state...
This is a question related to Get OS-Version in WinRT Metro App C# but not its duplicate.
Is there any option to detect from a Metro application whether there is the desktop feature available on the system? I understand that detection of the OS version is not supported and that is OK imo.
However my metro app needs to know whether there is a Desktop available on the system it is running on.
By Desktop I mean extendable desktop - desktop, where 3rd party desktop applications can be installed. As we know ARM based units will have the desktop too, but only with Microsoft built-in programs.
Can I distinguish whether my Metro app is running on a ARM based tablet with non-extendable desktop vs on all other (Intel based) devices with extendable desktop?
After some more extensive search I found GetNativeSystemInfo method. The hint was right away on SO site - this question. This approach seems to be fully supported by Windows Store applications - the App Cert Kit test ran smoothly despite the fact that pinvoke was used.
I ended up with the following code:
[DllImport("kernel32.dll")]
internal static extern void GetNativeSystemInfo(ref SystemInfo lpSystemInfo);
internal static bool IsArmBased()
{
var sysInfo = new SystemInfo();
GetNativeSystemInfo(ref sysInfo);
return sysInfo.wProcessorArchitecture == ProcessorArchitectureArm; //ushort 5
}
This seems to be as a solution I was looking for. Please tell me if not or make me aware of whatever problems connected to such an approach. Thank you.
If this is HTML, you can use window.cpuClass to get if it's ARM, x86 or amd64.
A non dynamic version is to use target specific architectures rather than AnyCPU, and then use the flavours with #ifdefs to hard code it at build time. You have to submit 3 packages to the store, however.
Use a try {} catch(){} to access those libraries, if anything goes wrong assume the ARM version.
How would I go about calling a dll from kernel mode?
I have tried making a custom lib file using multiple techniques but I cannot get anything to work. I have also researched on google but cannot seem to find anything. I was also curious if it was possible to create entries in the import address table from c++ or at link time?
The fundamental issue for a DLL in kernel mode is whether the DLL calls any user-mode code. If a DLL contains anything other than native kernel API calls, you'll get linker errors if you try to link your driver with it when you build (and the kernel wouldn't load it anyway)
check the following link
Calling a DLL in a Kernel-Mode Driver
Edit:
Another useful link
DLLs in Kernel Mode Tim Roberts