Is it possible to build LibUV for Windows UWP Platform ?

[supercairos]

I have a build my app around libuv's event queue and would like to port my app to Xbox One. Any idea if someone managed to build libuv for UWP before ?

[bnoordhuis]

Not to my knowledge.

[supercairos]

Ok! Could it be done? If so what would I need to do in libuv to make it work?

I'm really interested in the core function: socket, timer & async.

Thanks :)

Le 6 juil. 2017 16:46, "Ben Noordhuis" notifications@github.com a écrit :

Not to my knowledge.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/libuv/help/issues/14#issuecomment-313418196, or mute the thread https://github.com/notifications/unsubscribe-auth/AAr_IxQsAhANM7OZMRBqCCuzklOlpoWyks5sLPNPgaJpZM4OPbKJ .

[bnoordhuis]

I don't have much experience with UWP but I suspect it's a fair bit of work. The Windows port of libuv isn't very modular so porting to UWP piecemeal probably won't work.

[txdv]

Yes it is.

The API is async as a default design decision. AFAIK everything that could block longer than 20ms (or some other low number) is made to be asynchronous.

Also one of the supported languages is C++, so technically exposing it as a simpler C api should be no problem. It is technically C++/CLI or something like that, but it is possible to hide the /cli part behind a simpler C interface.

[supercairos]

@txdv I'm sorry, I don't really understand your answer. I'm building a messaging app and want to port it to XBox One. I've tried to compile libuv with Windows Store compliant API (reimporting souce files into a static lib UWP project) and it fails (as expected) due to missing functions. From what I could see, pipe, process and some utils are not availlable to the uwp platform. I'm trying to remove these when building for uwp and see if it works.

[txdv]

The UWP api is different, of course it will fail: https://docs.microsoft.com/en-us/windows/uwp/networking/networking-basics

[supercairos]

Libuv makes great use of winsocks2 as a socket back-end on Windows which is available to UWP platform.

No problem here.

Le 25 juil. 2017 06:12, "Andrius Bentkus" notifications@github.com a écrit :

The UWP api is different, of course it will fail: https://docs.microsoft.com/en-us/windows/uwp/networking/networking-basics

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/libuv/help/issues/14#issuecomment-317623748, or mute the thread https://github.com/notifications/unsubscribe-auth/AAr_IzEZ90UlZEV62C2nU8SsvbT96w9Sks5sRWsZgaJpZM4OPbKJ .

[LB--]

I tried manually building under UWP with Visual Studio 2019 and here's what I found:

• In process.c: STARTF_USESTDHANDLES and STARTF_USESHOWWINDOW are not defined. They are used as part of a call to CreateProcessW, which is available to UWP apps for launching other executables that are part of the UWP app package, but the STARTUPINFOW structure is listed as not being available to UWP apps. So, maybe these two constants just need to be defined and they might work, or maybe this particular usage of the API isn't yet supported, the documentation from Microsoft isn't clear.
• In dl.c, winapi.c: LoadLibraryExW isn't supported for UWP apps, but the nearly identical API LoadPackagedLibrary is supported and can be a drop-in replacement, but only for DLLs packaged with the app, not for external or system DLLs.
• In poll.c, process-stdio.c, tcp.c: HANDLE_FLAG_INHERIT isn't defined. It's used as part of a call to SetHandleInformation, which isn't supported under UWP. The ramifications of this lack of support are unclear to me.
• In core.c: SEM_FAILCRITICALERRORS, SEM_NOGPFAULTERRORBOX, SEM_NOOPENFILEERRORBOX are not defined. They are used as flags to call SetErrorMode, which Microsoft's documentation lists as being supported under UWP, so maybe them not being defined is just a mistake in the Windows headers and providing the correct definitions for them will work.
• In tty.c: MAPVK_VK_TO_VSC is not defined. It is used as part of a call to MapVirtualKeyW and later WriteConsoleInputW, which aren't supported under UWP. Interestingly, UWP does support console applications, but I am not sure how necessary this API is for supporting that.
• In util.c: PROCESSENTRY32 is not defined. It's used in uv_os_getppid as part of calls to Process32First and Process32Next, which aren't supported under UWP. I think it is safe to assume that for security reasons it will never be possible to support uv_os_getppid under UWP.
• In util.c: PERF_DATA_BLOCK, PERF_OBJECT_TYPE, PERF_COUNTER_DEFINITION are not defined. They are used to implement uv_uptime in conjunction with RegQueryValueExW, which isn't supported under UWP. For security reasons it may never be possible to get the system uptime from within a UWP app, so uv_uptime likely just can't be supported under UWP.
• In fs-event.c: [GetShortPathNameW]() is not supported under UWP. Looks like the short path code is optional and can be ifdef'd out for the same behavior as if short paths are disabled under Win32.
• In tty.c, fs-event.c, fs.c, pipe.c, process-stdio.c: CreateFileW is not supported under UWP, but the replacement function CreateFIle2 is. From the documentation, the main relevant differences are that named pipes can't be opened. It seems like you can just implement your own definition for CreateFileW that forwards to CreateFIle2.
• In fs.c: CreateSymbolicLinkW is not supported under UWP. I don't know of any alternative currently. Since UWP apps can only access their own read-only package directory and their read-write application data directory, I don't think symlinks and such are relevant to UWP.
• In getaddrinfo.c: ConvertInterfaceIndexToLuid and ConvertInterfaceLuidToNameW are not supported under UWP. I don't have experience or knowledge in this area to provide suggestions here, maybe it just can't be supported.
• In pipe.c, tty.c: [CreateFileA]() isn't supported under UWP, as discussed earlier with CreateFileW. Looks like they can just use the CreateFileW replacement, though of course named pipes are not supported under UWP, so perhaps pipe.c just shouldn't be compiled at all under UWP.
• In tty.c: [QueueUserWorkItem]() is not supported under UWP. As mentioned earlier, UWP does have support for console apps but I am not sure how it works with what uv expects on Windows.
• In process.c: CreateJobObjectW, SetInformationJobObject, AssignProcessToJobObject aren't supported under UWP. I don't know much about what this code is for but it doesn't seem relevant to UWP.
• In process.c: LCMapStringW is unfortunately not currently supported under UWP. I'm not sure of a good replacement.
• In process.c, tcp.c, tty.c: RegisterWaitForSingleObject, UnregisterWait, UnregisterWaitEx are not supported under UWP. Creating processes is supported on UWP though for executables within the same app package, but I am not sure what the expected replacement for these functions is in that case.
• In tcp.c: HasOverlappedIoCompleted is not defined. It's just a macro, and it seems like copying the definition from WinBase.h might work despite the documentation saying it isn't supported, but I genuinely have no idea what a proper alternative is.
• In util.c: RegOpenKeyExW, RegQueryValueExW, RegCloseKey, RegGetValueW are not supported under UWP other than with special permission from Microsoft. It's likely best to just not support accessing the registry under UWP.
• In util.c: VerifyVersionInfo, VER_SET_CONDITION are not defined or supported under UWP since UWP only runs on Windows 10. UWP has its own separate mechanism for checking API availability since API availability does not necessarily correlate with OS version, so it is likely best to just not support this API under UWP.
• In util.c: [GetProcessIoCounters]() is not supported under UWP. More zeros for this I guess.
• In util.c: GetUserProfileDirectoryW, GetUserNameW are not supported under UWP for privacy and security reasons. UWP apps can only access their own read-only app package directory and their read-write app data directory, so it's not relevant anyway.
• In winsock.c: [GetSystemMetrics]() isn't supported under UWP. It seems to be only used here for avoiding calling network APIs in safe mode without networking support... I think UWP apps don't really work in that environment anyway, but either way it's safe to ignore this check.
• In winapi.c: GetModuleHandleA isn't supported under UWP. Seems like this is for security purposes, to prevent calling unauthorized functions. Most of the functions that uv_winapi_init tries to obtain in this manner are not allowed in UWP, but a few are, they just need to be used directly instead of trying to get their address indirectly.
• In detect-wakeup.c: PowerRegisterSuspendResumeNotification isn't supported under UWP. The UWP app lifecycle has its own suspend/resume handling that only the app developer is privy to, uv can't know about it without being explicitly told, so this API isn't relevant under UWP.
• In util.c, tcp.c: RtlGetVersion isn't supported under UWP, but surprisingly GetVersionExW is supported despite being deprecated, so that fallback might be fine under UWP.
• In core.c: GetQueuedCompletionStatusEx is supported under UWP actually, so it can be used directly since it was introduced before UWP even existed.
• In util.c, fs.c: NtQuerySystemInformation, RtlNtStatusToDosError, NtSetInformationFile, NtQueryDirectoryFile, NtQueryInformationFile, NtQueryVolumeInformationFile, NtDeviceIoControlFile aren't supported under UWP. That shouldn't be surprising. I am not sure what alternatives to use for most of these, but SetEndOfFile does have support under UWP so at least there's that alternative.

In order to patch these issues I have made liberal use of the WINAPI_FAMILY_PARTITION macro function, but I have not always matched the conditions to the conditions under which the functions are actually available, I mostly just tried to make sure things would still compile for both DESKTOP and UWP. There are other family partitions such as GAMING and such that may also need special treatment. I also have not tested the changes at all, I've only ensured that a static library and DLL can be built. I am certain some of the changes I made are incorrect in some way or another, but the point of this is mainly for it to be a good starting point for expanding Windows support.

Here's the patch I came up with, completely untested but it compiles and links: uwp.zip (based on https://github.com/libuv/libuv/commit/285a5ea819035ff777b8b7c6a367f3f5b55d8809 )

EDIT: Apparently pipes are supported under UWP for interprocess communication between processed within the same app package, but I could only find such support for C#, I am not sure how it is supported in C or C++.