ShellExecuteEx doesn't support '\\?\' prefix, however TC could try something like this:
Code: Select all
if Length(FileName) < MAX_PATH then
ShellExecuteEx(...)
else
if Win32Platform = VER_PLATFORM_WIN32_NT then
CreateProcess(PChar('\\?\'+FileName),...) {This will work only for executable images}
If the launched file is not an executable, but for example a doc file, CreateProcess returns ERROR_BAD_EXE_FORMAT, so TC could display same error message as for the normal ShellExecuteEx call (ShellExecuteEx returns ERROR_PATH_NOT_FOUND in this case).
MVV wrote:AFAIK any Unicode API function supports prefixed paths up to 1023 characters.
According to my tests, under Windows NT family you can use both ANSI and Unicode APIs with '\\?\' prefix and they works. And MSDN
says, that the limit is as large as 32767 chars (+ null) in this case. But this works only with some functions from kernel32.dll, which is a wrapper around ntdll.dll, which passes calls to kernel-mode. AFAIK in the kernel mode all paths use '\\?\' prefix, so such paths can also be passed directly from the user mode.
MVV wrote:But is there any reason to keep applications in such deep places? Are you sure that app is able to work correctly in that place?
I was waiting for this question

I don't keep anything in such long locations, but sometimes I need/want to test something (for example if app is able to work correctly in that place

). Currently I must call CreateProcess to do this.
TC can use long paths almost everywhere, so this small improvement would be very nice.
Regards