[Bug 59272] New: COM ports resolved relative to working directory instead of dosdevices
http://bugs.winehq.org/show_bug.cgi?id=59272 Bug ID: 59272 Summary: COM ports resolved relative to working directory instead of dosdevices Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: kernel32 Assignee: wine-bugs@list.winehq.org Reporter: hilgert@mail.ru Distribution: --- Wine incorrectly resolves COM port paths relative to the current working directory instead of using the symlinks in ~/.wine/dosdevices/, causing CreateFile() calls for COM ports to fail when the application is launched from subdirectories. STEPS TO REPRODUCE: 1. Create a symlink in dosdevices: ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com1 2. Create a test application that calls: CreateFile("COM1", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); 3. Run the application from C:\: cd ~/.wine/drive_c/ wine test.exe Result: COM1 opens successfully via /dev/ttyUSB0 4. Run the application from a subdirectory: cd ~/.wine/drive_c/subdir/ wine test.exe Result: CreateFile fails with ERROR_FILE_NOT_FOUND EXPECTED BEHAVIOR: COM ports should always resolve through dosdevices symlinks regardless of working directory, matching Windows behavior where COM1 is a global device namespace. ACTUAL BEHAVIOR: Wine attempts to open "C:\subdir\COM1" as a regular file instead of resolving COM1 through dosdevices. DEBUG TRACE: trace:file:CreateFileW L"COM1" GENERIC_READ GENERIC_WRITE creation 3 attributes 0x0 trace:file:NtCreateFile name=L"\\??\\C:\\subdir\\COM1" warn:file:NtCreateFile L"\\??\\C:\\subdir\\COM1" not found (c0000034) WORKAROUND: Creating a symlink directly in the working directory allows the application to open the port, but this is not portable and breaks when changing directories: ln -s /dev/ttyUSB0 ~/.wine/drive_c/subdir/COM1 ADDITIONAL NOTES: This affects serial communication applications that rely on standard COM port naming conventions. The issue appears to be in how Wine's file path resolution handles device names. On real Windows, device names like COM1, LPT1, etc. are resolved through the device namespace regardless of the current directory. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59272 Maotong Zhang <zmtong1988@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zmtong1988@gmail.com --- Comment #1 from Maotong Zhang <zmtong1988@gmail.com> --- The COM1 registry can be set directly: Run "wine regedit" and set: HKEY_LOCAL_MACHINE\Software\Wine\Ports COM1 /dev/ttyUSB0 Then run "wineboot". A symlink will be created in the dosdevices directory: com1 -> /dev/ttyUSB0 I tested it following your steps. I wrote a test program that calls: CreateFile("\\\\.\\COM1", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); It works fine when run from any directory. Example: WINEPREFIX=/xxx1/xxx2 wine /xxx1/xxx2/drive_c/test.exe Run it and see the results. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59272 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |11.0-rc3 --- Comment #2 from Alexandre Julliard <julliard@winehq.org> --- What Wine version are you using? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59272 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|11.0-rc3 |unspecified -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59272 --- Comment #3 from Hilgert <hilgert@mail.ru> --- Latest version from wine-hq repository I apologize for the problem description. Perhaps Claude misinterpreted the trace and misdiagnosed it. The issue might not be with subdirectories at all. I tried running some ancient software. Attached is the trace: 3685.092:0020:0024:Call KERNEL32.GetPrivateProfileStringA(005bedb0 "OBD",0286dbb4 "PORT",0286dbbc "COM1",005bed9c,00000014,005bedc4 "c:\\bmw\\ediabas\\bin\\OBD.INI") ret=02862920 3685.092:0020:0024:trace:profile:GetPrivateProfileStringW L"OBD",L"PORT",L"COM1",0061B1F0,20,L"c:\\bmw\\ediabas\\bin\\OBD.INI" 3685.098:0020:0024:Call KERNEL32.CreateFileA(0286d944 "COM33",c0000000,00000000,00000000,00000003,00000000,00000000) ret=0286189b 3685.098:0020:0024:Call ntdll.RtlInitAnsiString(005beee0,0286d944 "COM33") ret=7b6442a2 3685.098:0020:0024:trace:file:CreateFileW L"COM33" GENERIC_READ GENERIC_WRITE creation 3 attributes 0x0 3685.098:0020:0024:Call ntdll.RtlDosPathNameToNtPathName_U(7ffc2c00 L"COM33",005beee8,00000000,00000000) ret=7b5e1450 3685.098:0020:0024:trace:file:RtlDosPathNameToNtPathName_U_WithStatus (L"COM33",005BEEE8,00000000,00000000) 3685.098:0020:0024:trace:file:RtlGetFullPathName_U (L"COM33" 520 005BEC2C 00000000) 3685.098:0020:0024:trace:file:RtlGetFullPathName_UEx (L"COM33" 520 005BEC2C 00000000 00000000) 3685.098:0020:0024:trace:file:NtCreateFile handle=0x5beee4 access=c0100080 name=L"\\??\\C:\\BMW\\EC-APPS\\INPA\\BIN\\COM33" objattr=00000040 root=(nil) sec=(nil) io=0x5beef0 alloc_size=(nil) attr=00000000 sharing=00000000 disp=1 options=00000060 ea=(nil).0x00000000 3685.098:0020:0024:trace:file:get_nt_and_unix_names L"\\??\\C:\\BMW\\EC-APPS\\INPA\\BIN\\COM33" -> ret c0000034 3685.098:0020:0024:warn:file:NtCreateFile L"\\??\\C:\\BMW\\EC-APPS\\INPA\\BIN\\COM33" not found (c0000034) 3685.098:0020:0024:warn:file:CreateFileW Unable to create file L"COM33" (status c0000034) 3685.284:0020:0024:trace:imm:imm_coinit_thread implicit COM initialization -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59272 --- Comment #4 from Alexandre Julliard <julliard@winehq.org> --- Please don't use AI to write bug reports, that's a waste of everybody's time. If the app is indeed using "COM33" then the behavior is expected. Only COM1-COM9 are treated as magic file names, others are treated as normal files. The app would have to use something like "\\.\COM33". It's the same on Windows. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59272 Hilgert <hilgert@mail.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #5 from Hilgert <hilgert@mail.ru> --- Then, I apologize. I didn't get to the bottom of this. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59272 Gijs Vermeulen <gijsvrm@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from Gijs Vermeulen <gijsvrm@gmail.com> --- Closing INVALID. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla