[Bug 42446] New: Native Access - missing api-ms-win-core-file-l2-1-2.dll and virtdisk.dll
https://bugs.winehq.org/show_bug.cgi?id=42446
Bug ID: 42446 Summary: Native Access - missing api-ms-win-core-file-l2-1-2.dll and virtdisk.dll Product: Wine Version: 2.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: api-ms-win-* Assignee: wine-bugs@winehq.org Reporter: demattcp@gmail.com Distribution: ---
At first, Native Access was just missing Virtdisk.dll. Then, I copied that specific dll file from my other Windows 10 computer into wine's system32 directory.
Now this is the output:
fixme:winediag:start_process Wine Staging 2.1 is a testing version containing experimental patches. fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org. err:module:import_dll Library api-ms-win-core-file-l2-1-2.dll (which is needed by L"C:\windows\system32\VirtDisk.dll") not found err:module:import_dll Library VirtDisk.dll (which is needed by L"C:\Program Files\Native Instruments\Native Access\Native Access.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\Program Files\Native Instruments\Native Access\Native Access.exe" failed, status c0000135
I am hoping this is something I can fix with winetricks.
https://bugs.winehq.org/show_bug.cgi?id=42446
fjfrackiewicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fjfrackiewicz@gmail.com
--- Comment #1 from fjfrackiewicz@gmail.com --- Virtdisk.dll has been implemented in Wine-git: http://source.winehq.org/git/wine.git/commit/e0d4b6896aa4158407826faf4775bed...
As for the other DLL, you should be able to work around it with "winetricks vcrun2015".
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #2 from demattcp@gmail.com --- What exactly is Wine-git? Is this something extra I need to download?
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #3 from fjfrackiewicz@gmail.com --- (In reply to demattcp from comment #2)
What exactly is Wine-git? Is this something extra I need to download?
Wine-git is the nightly version of Wine AKA the latest possible version of Wine's codebase.
Yes, you would need to download the source code via a program called "git" and then compile the downloaded source code.
https://bugs.winehq.org/show_bug.cgi?id=42446
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Native Access - missing |Native Access needs |api-ms-win-core-file-l2-1-2 |api-ms-win-core-file-l2-1-2 |.dll and virtdisk.dll |.dll CC| |austinenglish@gmail.com
--- Comment #4 from Austin English austinenglish@gmail.com --- (In reply to fjfrackiewicz from comment #3)
(In reply to demattcp from comment #2)
What exactly is Wine-git? Is this something extra I need to download?
Wine-git is the nightly version of Wine AKA the latest possible version of Wine's codebase.
Yes, you would need to download the source code via a program called "git" and then compile the downloaded source code.
See https://wiki.winehq.org/Building_Wine
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #5 from Austin English austinenglish@gmail.com --- (In reply to fjfrackiewicz from comment #1)
Virtdisk.dll has been implemented in Wine-git: http://source.winehq.org/git/wine.git/commit/ e0d4b6896aa4158407826faf4775bed09de78913
As for the other DLL, you should be able to work around it with "winetricks vcrun2015".
This particular version isn't in vcrun2015. I also looked in the latest update, but it's also missing there.
https://bugs.winehq.org/show_bug.cgi?id=42446
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox_xerox2000@yahoo.co.uk
--- Comment #6 from Louis Lenders xerox_xerox2000@yahoo.co.uk --- I think that api-ms-win-core-file-l2-1-2.dll is only loaded because native virtdisk is used. I tested with current git and I could get initial window up with only native concrt140.dll and msvcp140. Unfortunatetely the window says that the app couldn`t start because it can not be run from a mounted disk. I don`t know why that message appears.
Current encountered bugs:
wine: Unimplemented function concrt140.dll.??0_ReentrantBlockingLock@details@Concurrency@@QAE@XZ called at address 0x7b43ea87 (thread 0009), starting debugger..
With native concrt140:
wine: Unimplemented function msvcp140.dll.__crtCreateThreadpoolTimer called at address 0x7b43ea87 (thread 0009), starting debugger...
tested : sha1sum Native\ Access\ 1.0.25\ Setup\ PC.exe 0ea4ad6e84258a6b9583d0f91efd9b67d059c858 Native Access 1.0.25 Setup PC.exe
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #7 from fjfrackiewicz@gmail.com --- (In reply to Louis Lenders from comment #6)
wine: Unimplemented function msvcp140.dll.__crtCreateThreadpoolTimer called at address 0x7b43ea87 (thread 0009), starting debugger...
That's a new bug...
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #8 from fjfrackiewicz@gmail.com --- (In reply to fjfrackiewicz from comment #7)
(In reply to Louis Lenders from comment #6)
wine: Unimplemented function msvcp140.dll.__crtCreateThreadpoolTimer called at address 0x7b43ea87 (thread 0009), starting debugger...
That's a new bug...
The concrt140 one has already been filed :)
https://bugs.winehq.org/buglist.cgi?quicksearch=ReentrantBlockingLock%40deta...
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #9 from demattcp@gmail.com --- Hey everyone thanks for all the help!
However, I'm still a little lost lol. I purged my system of Wine (at least I think I did: deleted ~/.wine) and then built Wine from source. Cloned the git repository and then ran the commands to make Wine.
Here is where I am lost. Now that wine is built, I don't know how to run it. Running wine --version simply returns a command not found error.
And to address the looming "new bug" concern, the reason I hadn't mentioned the api-ms-win-core-file-l2-1-2.dll issue was due to the fact that I just grabbed the Virtdisk.dll from my old system. So I think Louis is probably right about that.
Thanks and sorry for being a noob.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #10 from Austin English austinenglish@gmail.com --- (In reply to demattcp from comment #9)
Here is where I am lost. Now that wine is built, I don't know how to run it. Running wine --version simply returns a command not found error.
Use ~/wine-git/wine instead of wine. Adjust if you put the source in a different directory.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #11 from demattcp@gmail.com --- I was able to run the installer, and when I search for Native Access, I find it. However, when I launch the app it simply closes after a few seconds.
So in an attempt to run Native Access from the terminal, I went to ~/.wine/drive_c but Native Access is not located in any either of the Program Files directories. Where do applications get installed with wine-git?
Also, do I need to reinstall all of the dynamically linked libraries? I'm referring to the ones I manually installed via winetricks.
https://bugs.winehq.org/show_bug.cgi?id=42446
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|api-ms-win-* |-unknown
--- Comment #12 from Nikolay Sivov bunglehead@gmail.com --- This one is implemented concrt140.dll.??0_ReentrantBlockingLock@details@Concurrency@@QAE@XZ. What's the status of this bug, how does it fail currently?
https://bugs.winehq.org/show_bug.cgi?id=42446
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #13 from Louis Lenders xerox_xerox2000@yahoo.co.uk --- (In reply to Nikolay Sivov from comment #12)
This one is implemented concrt140.dll.??0_ReentrantBlockingLock@details@Concurrency@@QAE@XZ. What's the status of this bug, how does it fail currently?
Call from 0x7b43e8b7 to unimplemented function msvcp140.dll.??0task_continuation_context@Concurrency@@AAE@XZ, aborting
This is already covered by other bugreport. I suggest to leave this one open for the bug that happens after using native msvcp140:
A window comes up that says:
``You cannot starts Native Access from the mounted disk. Please drag and drop Native Access.app to your Applications folder and then start it from there``.
https://bugs.winehq.org/show_bug.cgi?id=42446
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Native Access needs |Native Access can not be |api-ms-win-core-file-l2-1-2 |started |.dll | URL| |https://www.native-instrume | |nts.com/en/specials/native- | |access/ Keywords| |download
--- Comment #14 from Louis Lenders xerox_xerox2000@yahoo.co.uk --- changed title/filled some fields
https://bugs.winehq.org/show_bug.cgi?id=42446
intosamadhi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |intosamadhi@gmail.com
--- Comment #15 from intosamadhi@gmail.com --- Has any progress been made on this?
Trying to run Native Access 1.1.3 using wine 2.4
Program opens with error message:
You cannot start Native access from the mounted disk. Please drag and drop Native Access.app to your 'Applications' folder and then start it from there.
It seems to be detecting a 'mac' environment.
Setting wine to windows 10
Using overrides:
api-win-core-file-l2-1-2 concrt140 msvcp120 msvcp140 msvcr120 virtdisk
Terminal output gives:
ixme:ntdll:EtwRegisterTraceGuidsW (0x10003650, 0x1000a3a0, {e14dcdd9-d1ec-4dc3-8395-a606df8ef115}, 1, 0x33fcec, (null), (null), 0x1000a3a8): stub fixme:ntdll:EtwRegisterTraceGuidsW register trace class {e14dcdd9-d1ec-4dc3-8395-a606df8ef115} fixme:ntdll:EtwEventRegister ({4d20df22-e177-4514-a369-f1759feedeb3}, 0x10003530, 0x1000a008, 0x1000a3d0) stub. fixme:vcruntime:__telemetry_main_invoke_trigger (0x360000) fixme:d3d:wined3d_dxtn_init Wine cannot find the txc_dxtn library, DXTn software support unavailable. fixme:vcruntime:__telemetry_main_invoke_trigger (0x1930000) fixme:win:RegisterDeviceNotificationW (hwnd=0x20048, filter=0x33ea1c,flags=0x00000004) returns a fake device notification handle! fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenElevation, ...) semi-stub fixme:ntdll:NtLockFile I/O completion on lock not implemented yet fixme:file:FindFirstFileExW flags not implemented 0x00000002 fixme:shcore:SetProcessDpiAwareness (2): stub fixme:shcore:GetProcessDpiAwareness ((nil), 0x33e5fc): stub fixme:ntdll:NtPowerInformation semi-stub: SystemPowerCapabilities fixme:heap:GetPhysicallyInstalledSystemMemory stub: 0x33e6d4 fixme:file:FindFirstFileExW flags not implemented 0x00000002 fixme:file:FindFirstFileExW flags not implemented 0x00000002 fixme:msg:ChangeWindowMessageFilterEx 0x3005a c05a 1 (nil) fixme:nls:get_dummy_preferred_ui_language (0x8 0x33e44c 0x33e3bc 0x33e440) returning a dummy value (current locale) fixme:secur32:schannel_get_mac_algid unknown algorithm 200 fixme:file:FindFirstFileExW flags not implemented 0x00000002 fixme:file:FindFirstFileExW flags not implemented 0x00000002 fixme:file:FindFirstFileExW flags not implemented 0x00000002 fixme:file:FindFirstFileExW flags not implemented 0x00000002 fixme:font:RemoveFontMemResourceEx (0x877e2ca9) stub fixme:font:RemoveFontMemResourceEx (0x8f174311) stub fixme:font:RemoveFontMemResourceEx (0x8f113df9) stub fixme:font:RemoveFontMemResourceEx (0x8f13b921) stub fixme:font:RemoveFontMemResourceEx (0x8f1c37a1) stub fixme:font:RemoveFontMemResourceEx (0x8f1eac09) stub fixme:secur32:schannel_get_mac_algid unknown algorithm 200 fixme:font:RemoveFontMemResourceEx (0x87797a49) stub fixme:font:RemoveFontMemResourceEx (0x8f1b2851) stub fixme:font:RemoveFontMemResourceEx (0x8fe5a939) stub fixme:font:RemoveFontMemResourceEx (0x8fe62661) stub fixme:font:RemoveFontMemResourceEx (0x8fe09ce1) stub fixme:font:RemoveFontMemResourceEx (0x8fed1949) stub fixme:wgl:X11DRV_wglGetPixelFormatAttribivARB unsupported 2008 WGL Attribute fixme:dwmapi:DwmIsCompositionEnabled 0x33c974
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #16 from Austin English austinenglish@gmail.com --- (In reply to intosamadhi from comment #15)
In the future, please attach output instead of pasting inline
fixme:d3d:wined3d_dxtn_init Wine cannot find the txc_dxtn library, DXTn software support unavailable.
Done installing libdxtn help?
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #17 from intosamadhi@gmail.com --- (In reply to Austin English from comment #16)
(In reply to intosamadhi from comment #15)
In the future, please attach output instead of pasting inline
Thanks, sorry for that, am a bit new to this.
fixme:d3d:wined3d_dxtn_init Wine cannot find the txc_dxtn library, DXTn software support unavailable.
Done installing libdxtn help?
Any tip on how to install it? is it part of a direct3d package that I could download via winetricks?
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #18 from intosamadhi@gmail.com --- Created attachment 58552 --> https://bugs.winehq.org/attachment.cgi?id=58552 Native Access - Terminal output
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #19 from intosamadhi@gmail.com --- after install libtxc-dxtn0:i386 the d3d error is gone, but still the same result once the window opens.
I have a feeling it is reading the file path and interpreting it as a mac environment, since this was installed via a windows binary I can't think of another explanation for why it would return a mac oriented error.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #20 from intosamadhi@gmail.com --- (In reply to intosamadhi from comment #19)
after install libtxc-dxtn0:i386 the d3d error is gone, but still the same result once the window opens.
I have a feeling it is reading the file path and interpreting it as a mac environment, since this was installed via a windows binary I can't think of another explanation for why it would return a mac oriented error.
Any ideas on what these are about or how to resolve them:
fixme:mountmgr:harddisk_ioctl Unsupported fixme:file:FindFirstFileExW flags not implemented fixme:system:SetProcessDPIAware stub! fixme:nls:get_dummy_preferred_ui_language fixme:secur32:schannel_get_mac_algid unknown algorithm
https://bugs.winehq.org/show_bug.cgi?id=42446
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |kernel32 CC| |focht@gmx.net Summary|Native Access can not be |Native Instruments 'Native |started |Access' 1.1.x fails to | |start, reports 'You cannot | |start Native Access from | |the mounted disk'
--- Comment #21 from Anastasius Focht focht@gmx.net --- Hello folks,
--- quote --- Any ideas on what these are about or how to resolve them:
<fixme messages> --- quote ---
they are harmless and can be ignored.
Relevant part of trace log:
--- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Native Instruments/Native Access
$ WINEDEBUG=+tid,+seh,+relay,+volume wine ./Native\ Access.exe >>log.txt 2>&1 ... 002f:Call KERNEL32.GetVolumePathNameW(01779880 L"C:/Program Files/Native Instruments/Native Access/Native Access.exe",0033e094,00000400) ret=00490740 ... 002f:trace:volume:GetVolumePathNameW (L"C:/Program Files/Native Instruments/Native Access/Native Access.exe", 0x33e094, 1024) ... 002f:trace:volume:GetVolumePathNameW Successfully translated path L"C:/Program Files/Native Instruments/Native Access/Native Access.exe" to mount-point L"C:\Program Files\Native Instruments\Native Access\Native Access.exe\" ... 002f:Ret KERNEL32.GetVolumePathNameW() retval=00000001 ret=00490740 ... 002f:Call KERNEL32.GetVolumeInformationW(0033e094 L"C:\Program Files\Native Instruments\Native Access\Native Access.exe\",00000000,00000000,00000000,00000000,0033e078,00000000,00000000) 002f:Ret KERNEL32.GetVolumeInformationW() retval=00000000 ret=00490796 ... --- snip ---
GetVolumeInformation() lasterror = ERROR_DIR_NOT_ROOT (obvious)
--- snip --- Wine-dbg>bt
Backtrace: =>0 0x7b48b882 GetVolumePathNameW(filename="C:/Program Files/Native Instruments/Native Access/Native Access.exe", volumepathname="??@", buflen=0x400) [/home/focht/projects/wine/wine.repo/src/dlls/kernel32/volume.c:1667] in kernel32 (0x0033e8b8) 1 0x00434597 in native access (+0x34596) (0x0033eaf0) 2 0x00444e33 in native access (+0x44e32) (0x0033fdb8) 3 0x00a6f4e4 in native access (+0x66f4e3) (0x01696e88) 4 0x00000000 (0x01696ea0) 5 0x65766974 (0x614e2f2e) ...
Wine-dbg>n 1707 if (!RtlDosPathNameToNtPathName_U( volumenameW, &nt_name, NULL, NULL )) Wine-dbg>n 1709 volumenameW[pos] = '\0'; Wine-dbg>n 1710 status = wine_nt_to_unix_file_name( &nt_name, &unix_name, FILE_OPEN, FALSE ); Wine-dbg>p volumenameW "C:/Program Files/Native Instruments/Native Access/Native Access.exe"
...
1785 for (p = volumepathname; *p; p++) if (*p == '/') *p = '\'; Wine-dbg>p p "C:/Program Files/Native Instruments/Native Access/Native Access.exe"
--- snip ---
$ sha1sum Native_Access_Installer.zip 7f54fec76c6336b90739092261aa15b953aec256 Native_Access_Installer.zip
$ sha1sum Native\ Access\ 1.1.3\ Setup\ PC.exe fbcbe4a5c65430c6474dc3437eb5c846f96fc7d3 Native Access 1.1.3 Setup PC.exe
$ du -sh Native\ Access\ 1.1.3\ Setup\ PC.exe 59M Native Access 1.1.3 Setup PC.exe
$ wine --version wine-2.11
Bug 43240 ("Java 8 believes the filesystem is read-only)" is related, potentially a dupe.
Regards
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #22 from intosamadhi@gmail.com --- Thanks! that looks like progress, only I am too new to solving wine error's to know what to do about this.
Bug 43240 ("Java 8 believes the filesystem is read-only)" is related, potentially a dupe.
Following the advice in the above bug and setting up a drive in winecfg pointing to the directory containing "Native Access.exe" and executing wine start "G:\Native Access.exe" yields the same error.
I don't know yet how to run the debugger to see if this change makes any difference at all.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #23 from intosamadhi@gmail.com --- Am I correct in assuming that the problem is that the function is translating the volume path into this:
C:\Program Files\Native Instruments\Native Access\Native Access.exe\
where the double backslash at the end of the line breaks the functionality?
from:
002f:trace:volume:GetVolumePathNameW Successfully translated path L"C:/Program Files/Native Instruments/Native Access/Native Access.exe" to mount-point L"C:\Program Files\Native Instruments\Native Access\Native Access.exe\"
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #24 from intosamadhi@gmail.com --- (In reply to intosamadhi from comment #23)
Am I correct in assuming that the problem is that the function is translating the volume path into this:
C:\Program Files\Native Instruments\Native Access\Native Access.exe\
where the double backslash at the end of the line breaks the functionality?
from:
002f:trace:volume:GetVolumePathNameW Successfully translated path L"C:/Program Files/Native Instruments/Native Access/Native Access.exe" to mount-point L"C:\Program Files\Native Instruments\Native Access\Native Access.exe\"
just ran a trace and I see this happening as well:
trace:volume:GetDiskFreeSpaceExW L"G:",(nil),(nil),0x33e6a8
So it is reading the volume, not finding any free space and concluding it is read-only ?
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #25 from intosamadhi@gmail.com --- Created attachment 58591 --> https://bugs.winehq.org/attachment.cgi?id=58591 terminal output Native Access.exe 1.2
Using wine staging 2.11 and Native Access 1.20 still yields no success. I cannot see anything in the terminal output.
The trace using WINEDEBUG=+tid,+seh,+relay,+volume wine start "G:\Native Access.exe" is over 500mb and searching through it I am only finding what seem to be minor issues when searching for "getlasterror".
could this problem be caused by the use of qt5 ?
010a:Call KERNEL32.CreateFileW(015e52d0 L"\\?\D:\bamboo-build\THIRDP-QT31-BAPMN\sources\Qt-5.8.0-R3-msvc2015-x86-dll\qtlogging.ini",80000000,00000003,0033e69c,00000003,00000080,00000000) ret=6710bcb4 010a:Ret KERNEL32.CreateFileW() retval=ffffffff ret=6710bcb4 010a:Call KERNEL32.GetLastError() ret=6701c58a 010a:Ret KERNEL32.GetLastError() retval=00000003 ret=6701c58a
I feel completely lost in this :-( any tips or guidance on how to figure this out would be wonderful.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #26 from intosamadhi@gmail.com --- I find numerous SetProcessDpiAwareness error's when viewing the file below:
/home/michael/.wine/drive_c/users/michael/Local Settings/Application Data/cache/Native Instruments/Native Access/NativeAccess_1.log
[20170626 10:19:15.351 W] 68 SetProcessDpiAwareness(2) failed: COM error 0x80004001 E_NOTIMPL (Unknown error 0x080004001), using 0
is this relevant ?
https://bugs.winehq.org/show_bug.cgi?id=42446
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #27 from winetest@luukku.com --- (In reply to intosamadhi from comment #26)
I find numerous SetProcessDpiAwareness error's when viewing the file below:
/home/michael/.wine/drive_c/users/michael/Local Settings/Application Data/cache/Native Instruments/Native Access/NativeAccess_1.log
[20170626 10:19:15.351 W] 68 SetProcessDpiAwareness(2) failed: COM error 0x80004001 E_NOTIMPL (Unknown error 0x080004001), using 0
is this relevant ?
You just have to wait for now. The bug has been basically analyzed already and it sounds like a dupe.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #28 from intosamadhi@gmail.com --- With wine 2.12 Native Access 1.2
console output gives a new error:
wine: Unhandled page fault on read access to 0xffff0000 at address 0xffff0000 (thread 001f)
https://bugs.winehq.org/show_bug.cgi?id=42446
Stan markau0@lycos.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markau0@lycos.com
--- Comment #29 from Stan markau0@lycos.com --- The Native Access bug is due to the GetVolumePathNameW function (dlls kernel32 volume.c) which has
c = strrchrW( volumenameW, '\' );
which searches the volumenameW string for backslash's whereas it should be searching for slash's
changing
c = strrchrW( volumenameW, '\' );
to
c = strrchrW( volumenameW, '/' );
results in correct volumename being returned and Native Access then works normally.
Native Access is calling GetVolumePathNameW and then GetVolumeInformationW to see if it's being run from a read only volume.
GetVolumeInformationW is getting the wrong volume path from GetVolumePathNameW because of the backslash/slash bug in GetVolumePathNameW and GetVolumeInformationW is returning an error which Native Access interprets as being because it's being run on a read only filesystem and then Native Access puts up the error about it can't be run from the mounted volume and to move it to the Applications folder which is really a mac error but that's the error message NI use.
https://bugs.winehq.org/show_bug.cgi?id=44685
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #30 from Louis Lenders xerox.xerox2000x@gmail.com --- Hi Stan, thanks for the analysis. I can confirm your fix works around the bug.
Any chance you could convert this into patch (most likely there sould be some teste included)
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #31 from Louis Lenders xerox.xerox2000x@gmail.com ---
changing
c = strrchrW( volumenameW, '\' );
to
c = strrchrW( volumenameW, '/' );
results in correct volumename being returned and Native Access then works normally.
Hi Stan, just checked but that single change breaks the tests in kernel32/tests so I guess a fix is more complicated then this single change
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #32 from Stan markau0@lycos.com --- The printout of GetVolumePathNameW volumenameW is a path with forward slashes ie
"C:/home/user/.wine/drive_c/Program Files/App/App.exe"
then the loop code traverses that path starting at the end and moving toward the start but the loop code is searching for backslash's in volumenameW which don't exist and the loop breaks after one iteration and the return volume path is the original path with slash's converted to double backslashes with an extra backslash on the end which is useless for GetVolumeInformationW which flags an error.
Original entry path with slash's in GetVolumePathNameW volumenameW
"C:/Program Files/Native Instruments/Native Access/Native Access.exe"
The returned volume path with backslash's from GetVolumePathNameW
"C:\Program Files\Native Instruments\Native Access\Native Access.exe\"
This has got to affect a lot of Windows apps and not just Native Access, and the only thing I can think of is that most Windows apps are ignoring the GetVolumeInformationW error return whereas Native Access takes the error to mean that it's being run from a read only filesystem and therefore the GetVolumePathNameW bug has been brought out into the open via the Native Access read only error.
The GetVolumePathNameW loop does this
Since we can have very complicated drive/path * relationships on Unix systems, due to symbolic links, the safest way to * handle this is to start with the full path and work our way back folder by * folder unil we find a folder on a different drive (or run out of folders).
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #33 from Stan markau0@lycos.com --- The returned volume path with backslash's from GetVolumePathNameW
should be C:\
and not
"C:\Program Files\Native Instruments\Native Access\Native Access.exe\"
That means that multiple windows apps are getting the wrong volume info and it might lead to strange behaviours with those apps.
It seems that most apps don't halt on the wrong volume info error but Native Access does and so the bug has been noticed.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #34 from Stan markau0@lycos.com --- (In reply to Louis Lenders from comment #31)
changing
c = strrchrW( volumenameW, '\' );
to
c = strrchrW( volumenameW, '/' );
results in correct volumename being returned and Native Access then works normally.
Hi Stan, just checked but that single change breaks the tests in kernel32/tests so I guess a fix is more complicated then this single change
Maybe some things are sending a backslash path to GetVolumePathNameW and some things are sending a forward slash path to GetVolumePathNameW.
Anyway, something is wrong with the forward slashes and back slashes in regards to GetVolumePathNameW
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #35 from Stan markau0@lycos.com --- A printout of volumenameW when the tests are being run, will give the answer regarding the path slash's.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #36 from Zebediah Figura z.figura12@gmail.com --- *** Bug 44685 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #37 from Stan markau0@lycos.com --- On further testing I think that Native Access is passing a pathname with unix style slashes maybe because it thinks it's on a mac due to some bug in Native Access.
Native Access seems to be passing
"C:/Program Files/Native Instruments/Native Access/Native Access.exe"
to GetVolumePathNameW and GetVolumePathNameW is not prepared for the unix style slashes and Native Access should be passing
"C:\Program Files\Native Instruments\Native Access\Native Access.exe" to GetVolumePathNameW
Pretty weird but I think that that is what it is.
Native Access seems to have some mac detection code in it and hence the can't run from mounted volume move Native Access to the Applications folder error and maybe the unix style pathname sent to GetVolumePathNameW
If GetVolumePathNameW is altered to be able to handle unix style paths (see my code above) then Native Access runs ok but that is not normal for GetVolumePathNameW which needs to handle window style paths and so the Wine volume tests fail as would be expected.
I don't know what a fix would be, maybe detect unix style paths at the start of GetVolumePathNameW and convert them to windows style paths.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #38 from Stan markau0@lycos.com ---
As a rough test (forgetting my previous changes post) I added a rough unix to windows path convert to just after strcpyW( volumenameW, filename );
so that it looks like
strcpyW( volumenameW, filename );
WCHAR *p2;
/* Normalize path */ for (p2 = volumenameW; *p2; p2++) if (*p2 == '/') *p2 = '\';
With this the wine volume tests work and Native Access works.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #39 from Stan markau0@lycos.com --- Bug https://bugs.winehq.org/show_bug.cgi?id=43240 is doing the same thing, passing a unix path name to GetVolumePathNameW
I'm passing in the filename "Z:\tmp\winebugtest\winebugtest.java"
If GetVolumePathNameW converts unix path name slash's / to \ before it begins processing the path name then these bugs are fixed.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #40 from Stan markau0@lycos.com --- It would be interesting to know if GetVolumePathName on Windows can actually handle forward slash's in the path name.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #41 from Stan markau0@lycos.com --- I just tested a unix style path with GetVolumePathName using Vista.
Both
"C:\Program Files\Native Instruments\Native Access\Native Access.exe"
and
"C:/Program Files/Native Instruments/Native Access/Native Access.exe"
return
C:\
Native Access is doing nothing wrong using / instead of \ and it is pretty well known that Windows paths can accept / or \ ie CreateFile etc.
So I would say that Wines GetVolumePathNameW needs to be changed to be able to handle / as well as \ in the path name for compatibility.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #42 from Stan markau0@lycos.com --- Created attachment 60709 --> https://bugs.winehq.org/attachment.cgi?id=60709 Vista GetVolumePathName slash test
Vista GetVolumePathName slash test
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #43 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Stan from comment #42)
Created attachment 60709 [details] Vista GetVolumePathName slash test
Vista GetVolumePathName slash test
Hi Stan, could you add an appropriate test case to the existing tests (in kernel32/tests)?
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #44 from Stan markau0@lycos.com --- I added
WCHAR *fwdslash;
/* forward slash backslash replace */ for (fwdslash = volumenameW; *fwdslash; fwdslash++) if (*fwdslash == '/') *fwdslash = '\';
to
GetVolumePathNameW
in dlls kernel32 volume.c
and I added
{ /* test 42: a reasonable forward slash path that is guaranteed to exist */ "C:/windows/system32", "C:\", sizeof(volume_path), NO_ERROR, NO_ERROR },
to
test_GetVolumePathNameA
in dlls kernel32 tests volume.c
I then ran the volume test and it seems ok.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #45 from Stan markau0@lycos.com --- Created attachment 60714 --> https://bugs.winehq.org/attachment.cgi?id=60714 dlls kernel32 volume.c Wine 3.3
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #46 from Stan markau0@lycos.com --- Created attachment 60715 --> https://bugs.winehq.org/attachment.cgi?id=60715 dlls kernel32 tests volume.c Wine 3.3
https://bugs.winehq.org/show_bug.cgi?id=42446
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #47 from Zebediah Figura z.figura12@gmail.com --- I suspect what should rather be done is to pass the path through GetFullPathName() first; the current implementation doesn't handle relative paths either (and, as my testing shows, should).
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #48 from Stan markau0@lycos.com --- There are going to be some Windows apps that use forward slash paths for programming convenience or maybe because mac programmers were doing a Windows port or whatever.
Windows path routines can mostly handle forward slash paths from what I've read and the few things I've tested (GetVolumePathName).
I don't know enough about what Wine is set up for regarding forward slash paths.
I would think that Wine should cover the forward slash path possibility and therefore avoid compatibility problems such as this Native Access one.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #49 from Stan markau0@lycos.com --- As far as I can tell, GetVolumePath does convert forward slash's to back slash's via collapse_path.
GetVolumePathNameW seems to be a separate case where forward slash's are getting through and not being covered by the current code.
The current GetVolumePathNameW gets a forward slash path name
"C:/Program Files/Native Instruments/Native Access/Native Access.exe"
and can't handle it and it returns
"C:\Program Files\Native Instruments\Native Access\Native Access.exe\"
whereas it should return
C:\
If GetVolumePathNameW gets a forward slash name
"C:\Program Files\Native Instruments\Native Access\Native Access.exe"
then it returns C:\ as expected.
So all that is needed in GetVolumePathNameW's case is to convert the forward slash's to back slash's at the start of GetVolumePathNameW and then GetVolumePathNameW can handle path names with back slash's and forward slash's.
Windows GetVolumePathNameW routine can handle forward slash's and back slash's and that means Wine's GetVolumePathNameW is not totally compatible with Windows GetVolumePathNameW.
If Windows GetVolumePathNameW gets a forward slash path name
"C:/Program Files/Native Instruments/Native Access/Native Access.exe"
then it returns C:\ whereas Wines current GetVolumePathNameW is returning "C:\Program Files\Native Instruments\Native Access\Native Access.exe\"
which causes GetVolumeInformation to return an error.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #50 from Stan markau0@lycos.com --- Whoops I meant GetFullPathName(). so my last comment should read
As far as I can tell, GetFullPathName() does convert forward slash's to back slash's via collapse_path.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #51 from Stan markau0@lycos.com --- I'll try that again (disregard my last 2 comments they have errors).
As far as I can tell, GetFullPathName() does convert forward slash's to back slash's via collapse_path.
GetVolumePathNameW seems to be a separate case where forward slash's are getting through and not being covered by the current code.
The current Wine GetVolumePathNameW gets a forward slash path name
"C:/Program Files/Native Instruments/Native Access/Native Access.exe"
and can't handle it and it returns
"C:\Program Files\Native Instruments\Native Access\Native Access.exe\"
whereas it should return
C:\
If the current Wine GetVolumePathNameW gets a back slash name
"C:\Program Files\Native Instruments\Native Access\Native Access.exe"
then it returns C:\ as expected.
So all that is needed in GetVolumePathNameW's case is to convert the forward slash's to back slash's at the start of GetVolumePathNameW and then GetVolumePathNameW can handle path names with back slash's and forward slash's.
Windows GetVolumePathNameW routine can handle forward slash's and back slash's and that means Wine's GetVolumePathNameW is not totally compatible with Windows GetVolumePathNameW.
If Windows GetVolumePathNameW gets a forward slash path name
"C:/Program Files/Native Instruments/Native Access/Native Access.exe"
then it returns C:\ (as expected) whereas Wines current GetVolumePathNameW is returning "C:\Program Files\Native Instruments\Native Access\Native Access.exe\"
which causes GetVolumeInformation to return an error.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #52 from Zebediah Figura z.figura12@gmail.com --- Indeed, it seems as though you have the problem nailed down quite well. A patch to fix it would be quite welcome ;-)
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #53 from Stan markau0@lycos.com --- (In reply to Zebediah Figura from comment #52)
Indeed, it seems as though you have the problem nailed down quite well. A patch to fix it would be quite welcome ;-)
I posted as attachments an updated dlls kernel32 volume.c with the GetVolumePathNameW forward slash changes for Wine 3.3 a few posts back if anyone is interested and also an added forward slash test (dlls kernel32 tests volume.c) and the volume tests pass with the forward slash changes.
The problem gets down to if a Windows app calls GetVolumePathName directly with a forward slash path name which is not an error as far as Windows is concerned, it's just that most Windows apps will be calling GetVolumePathName directly with a back slash path name but Windows still caters for calls to GetVolumePathName that have a forward slash path name and maybe Mac programmers porting to Windows might happen to use forward slash pathnames or whatever, so there is a possibility that some Windows apps are going to call GetVolumePathName directly with a forward slash path name and so Wines GetVolumeNameW would need to be changed to cater for this as Windows can cater for it.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #54 from Zebediah Figura z.figura12@gmail.com --- It would be appreciated to send it as a patch to wine-devel@winehq.org; see https://wiki.winehq.org/Submitting_Patches for instructions.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #55 from Stan markau0@lycos.com --- (In reply to Zebediah Figura from comment #54)
It would be appreciated to send it as a patch to wine-devel@winehq.org; see https://wiki.winehq.org/Submitting_Patches for instructions.
Thanks for the welcome message.
I read
"As stated on that bug report, I think a better solution is to use GetFullPathName() instead. Testing shows that GetVolumePathName() should also handle relative paths (and currently doesn't), and GetFullPathName() would take care of both problems."
If a programmer calls GetVolumePathName directly with a forward slash pathname then I can't see GetFullPathName being involved unless I'm missing something in GetVolumePathName relying on GetFullPathName somehow.
If you mean alter GetVolumePathName to use the GetFullPathName then I might see what you mean.
"GetVolumePathName() should also handle relative paths", if that's the case then it should.
I did try a GetFullPathName test on Vista and Wine because of what you said and I seem to be getting different return values
https://bugs.winehq.org/show_bug.cgi?id=44721
https://bugs.winehq.org/show_bug.cgi?id=42446
winetaste@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetaste@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #56 from Stan markau0@lycos.com --- I have altered GetVolumePathNameW to use the GetFullPathNameW function, so that should enable GetVolumePathNameW to handle back and forward slash paths and relative paths.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #57 from Stan markau0@lycos.com --- Using GetFullPathName to translate the path name that GetVolumePathNameW receives did seem to initially work for Native Access but it broke a lot of the volume tests as well, so GetFullPathName is not suitable to translate the path names (and deal with the forward slash path name problem) in GetVolumePathNameW.
So the previous code to scan the GetVolumePathNameW path name and replace forward slash's with back slashs is the one that works and the volume tests pass (Comment 44, Comment 45, Comment 46)
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #58 from Stan markau0@lycos.com --- I've tested GetVolumePathNameW (using my patches above) with relative paths and forward and back slash paths and it all seems ok to me.
https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #59 from Stan markau0@lycos.com --- This Native Instruments bug is fixed with my patches as far as I can tell from running Wine volume tests and running Native Access.
https://bugs.winehq.org/show_bug.cgi?id=42446
Ed ed.clements@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ed.clements@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42446
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |d37d9860a1b598c5a32e4f42e7c | |5b40224a60de2 Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #60 from Louis Lenders xerox.xerox2000x@gmail.com --- This was fixed by d37d9860a1b598c5a32e4f42e7c5b40224a60de2
Thanks Mark
https://bugs.winehq.org/show_bug.cgi?id=42446
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |d37d9860a1b598c5a32e4f42e7c | |5b40224a60de2 Regression SHA1|d37d9860a1b598c5a32e4f42e7c | |5b40224a60de2 |
--- Comment #61 from Louis Lenders xerox.xerox2000x@gmail.com --- Corrected field (filled in regression instead of fixed by sha1 ......)
https://bugs.winehq.org/show_bug.cgi?id=42446
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #62 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.6.
https://bugs.winehq.org/show_bug.cgi?id=42446
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |3.0.x
https://bugs.winehq.org/show_bug.cgi?id=42446
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|3.0.x |---
--- Comment #63 from Michael Stefaniuc mstefani@winehq.org --- Removing the 3.0.x milestone from bugs included in 3.0.2.
-
wine-bugs＠winehq.org