Есть ли способ обойти ограничения UWP для определенных API?

Я экспериментировал с созданием xaml-приложения Windows-10 C ++ UWP.

Моя мотивация при выборе этой платформы заключалась в том, чтобы избежать использования нескольких языков (C # для WPF gui, C ++ - CLI для взаимодействия) и использовать C ++ только с некоторыми C ++ - CX.

Моя цель состояла в том, чтобы создать собственный инструмент для отладки драйвера PCI, а не создавать какое-то приложение для магазина Windows с высокой степенью защиты.

Мне показалось, что приложение UWP очень ограничивает использование некоторых функций WIN API. Например, я не могу использовать свои статические библиотеки, потому что они используют CreateFile и DeviceIoControl. Я получаю сообщение об ошибке: error C3861: 'CreateFileA': identifier not found.

Даже если мне каким-то образом удастся связать мои собственные библиотеки (скрывая использование этих функций в файлах .cpp), эти функции, похоже, не работают во время выполнения.

Есть ли способ обойти эти ограничения? Я хочу использовать эту платформу только из-за ее возможностей пользовательского интерфейса C ++.


uwp win-universal-app windows-10-universal c++-winrt c++-cx
person    schedule 03.05.2018    source источник
comment
Попробуйте приложения настольного моста uwp   -  person Shubham Sahu    schedule 04.05.2018
comment
Настоящий вопрос здесь в пресловутой банке червей - xaml + idl 3.0 + cppwinrt .... это лучшее будущее по сравнению с прошлым win32? Почему бы не создать приложения с графическим интерфейсом для рабочего стола, отличные от uwp, с помощью комбинации xaml + idl3.0 + cppwinrt? И не менее важно. Почему бы не создать серверные приложения (без графического интерфейса) с помощью cppWINRT ...?   -  person    schedule 07.06.2018
comment
@DusanJovanovic: Какое значение имеет XAML в настольных графических приложениях, отличных от UWP?   -  person IInspectable    schedule 22.06.2018
comment
@IInspectable Я бы сказал, что общее направление MSFT для WIN UI основано на XAML как части инструментальной цепочки. UWP или нет. C ++ или нет. Вместе с попытками отказаться от WIN32. Может быть, что-нибудь в этом роде: youtu.be/LYelIAwH7w8 ...   -  person    schedule 23.06.2018
comment
@DusanJovanovic: Стандартные общие элементы управления Windows традиционно использовали формат файла определения ресурса в качестве языка разметки. Уже примерно 3 десятилетия. Microsoft не пойдет ни в каком другом направлении. Непонятно, откуда у вас такое впечатление. Единственная другая технология GUI, не относящаяся к UWP, - это WPF. Это в значительной степени идентично по функциям технологии графического интерфейса пользователя UWP, но с интерфейсом только для управления (по какой-либо причине). По сути, в качестве технологий графического интерфейса есть только UWP и Windows API, причем последний никогда не будет переходить на XAML.   -  person IInspectable    schedule 23.06.2018

Ответы (2)


arrow_upward
4
arrow_downward

Извините за плохие новости. Действительно, если вы не соответствуете указанным ограничениям, ваш выбор - не UWP. Вместо этого сделайте WPF.

Приложения UWP предназначены для централизованного управления. Таким образом, вы можете распространять их через Store, ограничивать доступ к их файловой системе, управлять объемом памяти и временем жизни и т. Д. Вы можете думать об этом как о попытке прекратить поддержку Win32 API (который довольно старый, хакерский и анархичный) и использовать песок- бокс как суперседер.

person Yury Schkatula    schedule 03.05.2018
comment
Действительно разочаровывающие новости. Как жаль, что эти ограничения не являются необязательными. - person Elad Maimoni; 03.05.2018
comment
@NinaKaprez, вы не можете подписаться или отказаться от них, потому что это жизненно важная часть идеологии UWP. Более того, даже при наличии неиспользуемых ссылок импорта на CreateFileA или аналогичный персонал WinAPI автоматически отклоняет отправку вашего приложения в MS Store. - person Yury Schkatula; 03.05.2018
comment
@NinaKaprez: Если бы ограничения были необязательными, никто бы не соглашался ограничивать себя, и мы все равно продолжали бы писать приложения, которые должны запускаться с правами администратора. Кроме того, вы можете получить доступ к большей части поверхности UWP API из обычного настольного приложения Windows. Я считаю, что сейчас ведется работа, чтобы сделать доступными и остальные части, в первую очередь пользовательский интерфейс. В настоящее время вам необходимо использовать Desktop Bridge. См. Расширьте свое настольное приложение современными компонентами UWP для более подробной информации. - person IInspectable; 03.05.2018
comment
@IInspectable Мне было интересно, сделает ли Microsoft пользовательский интерфейс UWP доступным для обычных настольных приложений. В последнем обновлении VS (15.7) они добавили чистый собственный C ++ с приложениями XAML UWP и собственным консольным приложением WinRT. Но все же нет C ++ с Xaml для обычного рабочего стола. - person Elad Maimoni; 21.06.2018
comment
@NinaKaprez: Об этом уже говорилось в этом выпуске GitHub. Я не уверен, каков здесь текущий статус. Поддерживаемый вариант - использовать технологию Desktop Bridge, как объяснено в ссылке, которую я разместил ранее. Если Desktop Bridge не подходит для вашего варианта использования, вы должны оставить комментарий к записи UserVoice, связанной с проблемой GitHub, объяснив, почему. Однако из вашего вопроса кажется, что Desktop Bridge - подходящее решение. - person IInspectable; 21.06.2018
comment
@NinaKaprez, я мог бы также добавить, что был бы весьма удивлен, если XAML (в ближайшем будущем) не будет полностью отделен от UWP. Если еще нет. Это также часть попытки отказаться от WIN32. Довольно интересно, что MS Research уже сделала это два года назад: youtu.be/LYelIAwH7w8 - person ; 23.06.2018
comment
@NinaKaprez Кто-то может подумать, что проблема в том, что UWP уже выглядит как одна очень большая ножная пушка. Чтобы его сбросить, требуется большой, медленный и чуткий маневр. - person ; 23.06.2018
comment
DesktopBridge - это вообще ужасное решение проблем IPC. Вы должны обернуть то, что обычно является синхронным API-интерфейсом, вокруг асинхронных брокеров, при этом привнося неисчислимые накладные расходы. Забудьте о UWP, используйте WPF. - person BAR; 29.06.2018
comment
@NinaKaprez Чтобы получить обновления пользовательского интерфейса UWP для настольных приложений, посмотрите здесь - person Michael Vach; 04.08.2018
comment
@nin: теперь есть частичная поддержка элементов управления XAML в настольных приложениях Win32. См. элементы управления UWP в настольных приложениях . Технология придумана островами XAML. - person IInspectable; 06.11.2018

arrow_upward
2
arrow_downward

Многие «старые» функции win32 все еще доступны или стали доступны в Windows 1803. Ориентация на UWP API, конечно, отличается от Win32 API. У Microsoft есть список официальных поддерживаемых API Win32 по адресу: https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis

CreateFileA отсутствует в этом списке, но CreateFile2 есть.

Для доступа к устройствам UWP предоставляет функциональные возможности в пространстве имен Windows.Devices.Custom.

LoadLibrary \ GetProcAddress также может быть решением.

Большинство ограничений применяется только к приложениям UWP, которые загружаются в Магазин, а не к приложениям, загружаемым параллельно. Вы можете просто создать пакет и поместить его в общий сетевой ресурс или на http-сервер.

person Victor Derks    schedule 20.06.2018
comment
Я не уверен, что это совсем правильно. Это процесс RuntimeBroker.exe, который контролирует доступ к Windows API. Это происходит независимо от того, как было установлено приложение UWP (Store, с боковой загрузкой, MSIX). - person IInspectable; 21.06.2018
comment
Кроме того, похоже, что 1803 вообще не представил каких-либо новых вызовов Windows API. Кроме того, LoadLibrary недоступна для приложений UWP. также, поэтому вы не можете получить дескриптор kernel32.dll для импорта CreateFileA. Даже если бы вы могли, он был бы отклонен во время выполнения процессом RuntimeBroker. Вы действительно пробовали это или у вас есть ссылка на справочную документацию, в которой объясняется, что это было возможно? - person IInspectable; 21.06.2018
comment
Я исследую свой ответ. Возможно следующее (проверено в отладчике): - создать стандартную C ++ Win32 DLL, которая экспортирует функцию, имеющую вызов CreateFile; - создать приложение UWP и использовать LoadPackagedLibrary и GetProcAddress для получения экспортированной функции. - Выполнение вызова CreateFile для //// L \\\\? \\ pci # ... не удается, однако с ошибкой ACCESS_DENIED, которая обычно отлично работает из консольного приложения Win32. Похоже, что в INF-файле драйвера устройства должны быть установлены явные права безопасности для UWP. - person Victor Derks; 22.06.2018
comment
@VictorDerks Ваш тест не проходит при попытке открыть простой файл с помощью CreateFile? Не думаю, что права безопасности нужны именно драйверу. API не сработает, несмотря ни на что. - person Elad Maimoni; 05.08.2018
comment
@ VictorDerks .. вы можете получить обработчик драйверов и выполнить IOCTL? - person RDX; 23.11.2018
comment
Мне не удалось разобраться с моим драйвером. На данный момент я прекратил свой эксперимент. - person Victor Derks; 19.12.2018