Я разрабатываю приложение для Windows 10, которое взаимодействует с пользовательскими драйверами устройств, файловой системой NTFS и DirectX 12. Это приложение является универсальным приложением Windows, написанным на C ++, WRL, XAML и DirectX. Для DirectX я выбрал элемент управления SwapChainPanel, и часть приложения DirectX прекрасно работает. Приложение загружено, поэтому у меня немного больше свободы, чем у приложения, которое нужно пройти через магазин.
К сожалению, универсальные приложения Windows имеют ряд ограничений в отношении вызовов API. WinRt API являются предпочтительными.
Вот список WinRt API, которые нужно вызвать для замены Win32 API:
https://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx
Кроме того, Windows Universal Apps может вызывать API-интерфейсы Win32, которые разделены на приложения (но не на разделы для рабочего стола), как указано в документации по каждой функции и в файле заголовка. Вот ссылка:
https://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx
Кроме того, теперь Winsock API разрешены из универсальных приложений Windows.
Однако я все еще остался без моего любимого (и необходимых API)
CreateFile()
ReadFile()
WriteFile()
DeviceIoControl()
CloseHandle()
В частности, мне нужно читать и записывать файлы во все места без взаимодействия с пользователем (а не в места, ограниченные изолированной программной средой приложений Windows Universal). Кроме того, мне нужно отправить IOCTL на несколько драйверов устройств.
Я мог бы отказаться от Windows Universal Apps и перейти на WPF. Однако у меня есть приложение с интенсивным касанием, и мне нужно, чтобы оно работало очень хорошо Кроме того, меня интересует отсутствие исправлений и приверженность WPF от имени Microsoft. Я рассмотрел другие фреймворки пользовательского интерфейса, но ни одна из них не была столь же многообещающей, как универсальное приложение Windows.
Microsoft допустила два пути в Windows 10 для универсальных приложений, которые позволят вызывать все функции Win32 (для приложений с боковой загрузкой).
Сломанный компонент среды выполнения Windows
а IPC хоть и по TCPIP
Я написал брокерский компонент среды выполнения Windows, и он работает хорошо. Однако решение требует, чтобы приложение C # было в миксе, и мне это не нужно / не нужно, так как мне нужно быстрое время загрузки приложения и я не хочу использовать CLR.
Следующий вариант — IPC через TCPIP. Я бы использовал быструю обратную петлю TCP, как описано в сообщении в блоге: Быстрая производительность обратной петли TCP и низкая задержка с Windows Server 2012 TCP Loopback Fast Path. Я хотел бы дать ссылку на него, но у меня (очень щедрый) лимит в две ссылки на первый пост.
У меня есть пара вопросов:
1) Если я пойду этим путем, должен ли я разместить IPC между элементами управления / кнопками XAML и остальной частью приложения? Это позволило бы остальной части приложения быть строго Win32. Или я должен просто разместить IPC между приложением и вызовами конкретных функций, которые мне нужны, которые выходят за пределы тех, которые разрешены Win32.
2) Я искал библиотеку или документ, в котором есть код и / или идеи для реализации IPC с TCPIP. Однако до сих пор статьи, в которых говорится о IPC с TCPIP, похоже, просто описывают программирование winsock, что я уже знаю, как делать. Мне бы понравилось писать код IPC, но я бы предпочел решение, которое было протестировано. Это должно работать безупречно, и я предпочел бы иметь код с некоторым временем на нем. Кто-нибудь использовал или слышал о коде и / или дизайне для IPC через TCPIP, которым можно поделиться?
Задача ещё не решена.
Других решений пока нет …