1

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?

KernelCoder
  • 19
  • 3
  • What about COM/DCOM? – Jonathan Nov 08 '15 at 08:05
  • @Jonathan That would be an elegant solution. I can also call WIn32 DLLs directly through C++. Both techniques seem to be allowed. It would be nice to have clarification that all Win32 APIs are allowed in the COM server and/or Win32 DLL. It would sure simplify things. – KernelCoder Nov 08 '15 at 08:21
  • I for one have never heard of such limitation and don't think such limitation exists. As a side note Windows itself relies heavily on dlls and com objects. – Jonathan Nov 08 '15 at 09:21
  • @Jonathan Windows Universal Apps can call WinRT APIs and Win32 APIs partitioned to the application. In addition Winsock has been added for newer OS versions. A native Windows Universal App can call the Win32 APIs partitioned to the application space natively. A side loaded app can also call Win32 APIs partitioned to the desktop without complaint however the behavior is claimed to be undefined. Managed apps must use pInvoke to call Win32 APIs. By using IPC we can overcome this limitation for side loaded apps however it is limited to TCPIP and brokered runtime apps. – KernelCoder Nov 09 '15 at 16:55
  • I meant the limitation in regards to dlls that you thought might exist. I believe limitations exist for universal apps due to its sandbox nature. – Jonathan Nov 10 '15 at 07:37
  • @Jonathan I appreciate the help. I would like to find an IPC implementation over TCP. as a permitted method to overcome this limitation. – KernelCoder Nov 10 '15 at 16:55

0 Answers0