openFileAbsoluteW is broken

[LemonBoy]

NtCreateFile (at least under Wine) doesn't really like wide-string paths without the leading \\??\ prefix, this makes it extremely cumbersome to use as you'd have to somehow append the prefix before the path can be used with the Win32 API.

[andrewrk]

I've been using the W suffix on function names to mean that the function asserts all the following things:

• the path already has the \\??\ prefix
• the path is WTF-16 encoded, null-terminated
• the native target OS is Windows

Most code would be using functions without the W suffix, which will happily convert. This is what I would recommend to do. What's this use case where you need to use the W suffix function and find it cumbersome?

[LemonBoy]

the path already has the \??\ prefix

This is not checked, there's a single call to isAbsoluteWindowsW and that's it.

What's this use case where you need to use the W suffix function and find it cumbersome?

AFAIK no Win32 API returns fully-qualified paths, I've tried with GetModuleFileNameW and it definitely doesn't (I've tested this on Wine & Windows 10 so I'm pretty sure I'm not hitting some Wine bug)

[andrewrk]

I think this has to do with using NtDll vs Kernel32. Related issue is #1840.

I suppose we could have 3 different abstraction levels here, rather than 2. I was trying to get away with having things be utf-8 encoded slices as you would expect, or the very specific format that NtDll expects. I would still like to continue exploring that possibility. I wonder what NtDll function GetModuleFileNameW is ultimately calling, and if that would return the \\?\ prefixed path.

[Sobeston]

I think this has to do with using NtDll vs Kernel32.

This is correct - winapi uses the more user-centric path strings, whereas Nt uses its own path strings.

I wonder what NtDll function GetModuleFileNameW is ultimately calling

From reading some of reactOS, I know that GetModuleFileNameExW calls FindModule.

GetModuleFileNameW I could not immediately find because of some microsoft constructed macro maze; I believe the only difference between ex and non-ex is that ex allows you to operate across processes.

FindModule has the signature:

static BOOL NTAPI
FindModule(IN HANDLE hProcess,
           IN HMODULE hModule OPTIONAL,
           OUT PLDR_DATA_TABLE_ENTRY Module)

GetModuleFileNameExW uses FindModule to get a LDR_DATA_TABLE_ENTRY of the module, and reads the memory of (&Module.FullDllName)->Buffer to get the string before handling nul termination and returning.

LDR_DATA_TABLE_ENTRY contains both FullDllName and BaseDllName (of type UNICODE_STRING), with UNICODE_STRING being a struct containing [*]u16 with a length and a cap. Due to MS' wisdom, there is no guarantee of nul termination.

I'm unsure how to solve these annoyances at the standard library level, but will look into it.

[andrewrk]

This has been solved for a while now.