How to P/Invoke into kernel32.dll on WinRT 8.1

Question

I'm trying to use a native API method (GetNativeSystemInfo) that is marked as supported for both phone and desktop Store apps on Windows 8.1. In the documentation, it is listed as living in kernel32.dll. Great! So my first attempt at P/Invoke looked like this:

[DllImport("kernel32.dll", CharSet = CharSet.Unicode, ExactSpelling = false, PreserveSig = true)]
private static extern void GetNativeSystemInfo(ref SYSTEM_INFO lpSysInfo);

Unfortunately this fails to run on actual devices - kernel32 is not found! As it happens, there is kernelBase.dll, and thus my second attempt:

[DllImport("kernelBase.dll", CharSet = CharSet.Unicode, ExactSpelling = false, PreserveSig = true)]
private static extern void GetNativeSystemInfo(ref SYSTEM_INFO lpSysInfo);

While this runs fine on my phone, it causes the app to fail certification; the method name and "kernelBase.dll" don't seem to be whitelisted.

Is this an oversight of WACK, or a bug that renders this API unusable in Store apps? My goal is to get information about the running processor (architecture, type, etc), and I'd prefer not to drop in to C++ for something this simple. If this API is not usable in practice, is there another way to get this info?

Answer 1

You'll need different pinvoke signatures for the Windows Phone and the Windows Store versions. For the phone reference GetNativeSystemInfo from api-ms-win-core-sysinfo-l1-2-0.dll

#if WINDOWS_PHONE_APP
     [DllImport("api-ms-win-core-sysinfo-l1-2-0.dll", CharSet = CharSet.Unicode, ExactSpelling = false, PreserveSig = true)]
     private static extern void GetNativeSystemInfo(ref SYSTEM_INFO lpSysInfo);
#else
     [DllImport("kernel32.dll", CharSet = CharSet.Unicode, ExactSpelling = false, PreserveSig = true)]
     private static extern void GetNativeSystemInfo(ref SYSTEM_INFO lpSysInfo);
#endif

See Supported Win32 APIs for Windows Phone 8 for a list (targetted for SL, but also valid for your Runtime app). The right reference will be automatically referenced if you call the function natively, but the tooling isn't there to do so for pinvoke. In general wrapping the function in a native Windows Runtime Component is easier than p-invoke, unless you only have a few, simple p-invokes.