https://bugs.winehq.org/show_bug.cgi?id=44373
Bug ID: 44373
Summary: cmd's %0 path variables (e.g. %~dp0) don't match those
of Windows (w.r.t. case and quoting)
Product: Wine
Version: 3.0-rc6
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: cmd
Assignee: wine-bugs(a)winehq.org
Reporter: ryan.prichard(a)gmail.com
Distribution: ---
I'm filing this issue at Fabian Maurer's suggestion, after filing
https://bugs.winehq.org/show_bug.cgi?id=44369.
When %0 starts with a quote character, Windows tends to evaluate the %0 path
variables (%~d0, %~p0, ...) strangely. I think the Wine behavior makes more
sense, but it could also make sense to match Windows bug-for-bug.
Test program (you might have to fix up the C:\bin for your machine):
C:\>mkdir Bin
C:\Bin\ShowArg0.Cmd:
@echo [%0] -------------------- [%~d0] [%~p0] [%~n0] [%~x0]
C:\Bin\RunScript.Cmd
@echo off
setlocal
set PATH=C:\bin;%PATH%
cd \
echo --- Wine and Windows roughly do the same thing.
call showarg0
call SHOWARG0
call showarg0.cmd
call SHOWARG0.CMD
call C:\bin\showarg0
call C:\bin\showarg0.cmd
call c:\bin\showarg0.CMD
call showarg0".cmd"
call showarg0."cmd"
call showarg0.c"md"
call s"ho"warg0.cmd
call s"ho"warg0
call "C:\bin\showarg0.cmd"
call "c:\bin\showarg0.CMD"
echo --- Wine and Windows diverge here.
call "showarg0"
call "SHOWARG0"
call "showarg0.cmd"
call "SHOWARG0.CMD"
call "showarg0".cmd
call "sho"warg0.cmd
call "sho"warg0
call "C":\bin\showarg0.cmd
call "C:"\bin\showarg0.cmd
call "C:\"bin\showarg0.cmd
call "c:\"bin\showarg0.CMD
call "C:\bin\showarg0"
(I edited the script output to align the columns.)
Windows behavior (tested on XP and Win10.0.16299.125):
C:\Bin>RunScript
--- Aside from case, Wine and Windows roughly do the same thing.
--- ... Using c:\bin in PATH
[showarg0] ----------------- [c:] [\Bin\] [ShowArg0] [.Cmd]
[SHOWARG0] ----------------- [c:] [\Bin\] [ShowArg0] [.Cmd]
--- ... Using C:\bin in PATH
[showarg0] ----------------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[SHOWARG0] ----------------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[showarg0.cmd] ------------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[SHOWARG0.CMD] ------------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[C:\bin\showarg0] ---------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[C:\bin\showarg0.cmd] ------ [C:] [\Bin\] [ShowArg0] [.Cmd]
[c:\bin\showarg0.CMD] ------ [c:] [\Bin\] [ShowArg0] [.Cmd]
[showarg0".cmd"] ----------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[showarg0."cmd"] ----------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[showarg0.c"md"] ----------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[s"ho"warg0.cmd] ----------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[s"ho"warg0] --------------- [C:] [\Bin\] [ShowArg0] [.Cmd]
["C:\bin\showarg0.cmd"] ---- [C:] [\Bin\] [ShowArg0] [.Cmd]
["c:\bin\showarg0.CMD"] ---- [c:] [\Bin\] [ShowArg0] [.Cmd]
--- Wine and Windows diverge here.
["showarg0"] --------------- [C:] [\] [showarg0] []
["SHOWARG0"] --------------- [C:] [\] [SHOWARG0] []
["showarg0.cmd"] ----------- [C:] [\] [showarg0] [.cmd]
["SHOWARG0.CMD"] ----------- [C:] [\] [SHOWARG0] [.CMD]
["showarg0".cmd] ----------- [C:] [\] [showarg0"] [.cmd]
["sho"warg0.cmd] ----------- [C:] [\] [sho"warg0] [.cmd]
["sho"warg0] --------------- [C:] [\] [sho"warg0] []
["C":\bin\showarg0.cmd] ---- [C:] [\C":\bin\] [showarg0] [.cmd]
["C:"\bin\showarg0.cmd] ---- [C:] [\"\bin\] [showarg0] [.cmd]
["C:\"bin\showarg0.cmd] ---- [C:] [\"bin\] [showarg0] [.cmd]
["c:\"bin\showarg0.CMD] ---- [c:] [\"bin\] [showarg0] [.CMD]
["C:\bin\showarg0"] -------- [C:] [\Bin\] [showarg0] []
Behavior on wine-3.0-rc6:
C:\Bin>RunScript
--- Aside from case, Wine and Windows roughly do the same thing.
--- ... Using c:\bin in PATH
[showarg0] ----------------- [c:] [\bin\] [showarg0] [.CMD]
[SHOWARG0] ----------------- [c:] [\bin\] [SHOWARG0] [.CMD]
--- ... Using C:\bin in PATH
[showarg0] ----------------- [C:] [\bin\] [showarg0] [.CMD]
[SHOWARG0] ----------------- [C:] [\bin\] [SHOWARG0] [.CMD]
[showarg0.cmd] ------------- [C:] [\bin\] [showarg0] [.cmd]
[SHOWARG0.CMD] ------------- [C:] [\bin\] [SHOWARG0] [.CMD]
[C:\bin\showarg0] ---------- [C:] [\bin\] [showarg0] [.CMD]
[C:\bin\showarg0.cmd] ------ [C:] [\bin\] [showarg0] [.cmd]
[c:\bin\showarg0.CMD] ------ [c:] [\bin\] [showarg0] [.CMD]
[showarg0".cmd"] ----------- [C:] [\bin\] [showarg0] [.cmd]
[showarg0."cmd"] ----------- [C:] [\bin\] [showarg0] [.cmd]
[showarg0.c"md"] ----------- [C:] [\bin\] [showarg0] [.cmd]
[s"ho"warg0.cmd] ----------- [C:] [\bin\] [showarg0] [.cmd]
[s"ho"warg0] --------------- [C:] [\bin\] [showarg0] [.CMD]
["C:\bin\showarg0.cmd"] ---- [C:] [\bin\] [showarg0] [.cmd]
["c:\bin\showarg0.CMD"] ---- [c:] [\bin\] [showarg0] [.CMD]
--- Wine and Windows diverge here.
["showarg0"] --------------- [C:] [\bin\] [showarg0] [.CMD]
["SHOWARG0"] --------------- [C:] [\bin\] [SHOWARG0] [.CMD]
["showarg0.cmd"] ----------- [C:] [\bin\] [showarg0] [.cmd]
["SHOWARG0.CMD"] ----------- [C:] [\bin\] [SHOWARG0] [.CMD]
["showarg0".cmd] ----------- [C:] [\bin\] [showarg0] [.cmd]
["sho"warg0.cmd] ----------- [C:] [\bin\] [showarg0] [.cmd]
["sho"warg0] --------------- [C:] [\bin\] [showarg0] [.CMD]
["C":\bin\showarg0.cmd] ---- [C:] [\bin\] [showarg0] [.cmd]
["C:"\bin\showarg0.cmd] ---- [C:] [\bin\] [showarg0] [.cmd]
["C:\"bin\showarg0.cmd] ---- [C:] [\bin\] [showarg0] [.cmd]
["c:\"bin\showarg0.CMD] ---- [c:] [\bin\] [showarg0] [.CMD]
["C:\bin\showarg0"] -------- [C:] [\bin\] [showarg0] [.CMD]
I see two differences:
- In most cases, when a path starts with a quote, Windows somehow doesn't
parse the path correctly and/or doesn't find the batch file in the PATH.
- As long as Windows *does* find the batch file, it uses the canonical case
for the path, filename, and extension. It doesn't canonicalize the drive;
instead it uses the drive from the PATH or %0. I also tested a SMB share on XP
and Win10 (\\nAs\nAs and \\NaS\NaS), and Windows didn't canonicalize the server
name or share name. (Maybe it never does.)
--
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.
https://bugs.winehq.org/show_bug.cgi?id=45576
Bug ID: 45576
Summary: Disabling game controllers does not work
Product: Wine
Version: 3.13
Hardware: x86-64
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ahyattdev(a)icloud.com
Disabling game controllers in control panel has no effect. It says you need to
restart the applet to see the change take affect but it never ends up
preventing the controllers from showing up in the connected controller list.
I am not sure if this is macOS specific or not, I have not tested this on
Linux.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=5129
--- Comment #25 from Grant <ggustaf(a)math.utah.edu> ---
Confirmed that the reinstall of winetricks into Mint 17.3 followed by running
winetricks and selecting comctl32 to add caused the bug to vanish in default
wine 1.6.2 and Faststone 5.5. Previously this failed to remove the bug.
The "fix" is untested in Mint 18 or 19.
Temporary workarounds cited in message 22
https://bugs.winehq.org/show_bug.cgi?id=5129#c22
still apply on other version combinations of wine and faststone.
The comctl32 fix also worked on a Lenovo laptop /w mint 17.3, which was running
Faststone 5.5 under default wine 1.6.2. The version of winetricks was the
latest and there was no re-install of winetricks. Ran wintricks from a
terminal, clicked options to add comctl32. Exited winetricks, ran FastStone
again and the bug was gone.
--
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=34893
Bug #: 34893
Summary: LaTale Launcher gives WSASocketW Failed to create a
socket of type SOCK_RAW, this requires special
permissions
Product: Wine
Version: 1.7.6
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: iyeru42(a)gmail.com
Classification: Unclassified
tried using the regnum fix:
sudo setcap CAP_NET_RAW=ep /usr/bin/wine
sudo setcap CAP_NET_RAW=ep /usr/bin/wineserver
sudo setcap CAP_NET_RAW=ep LaTaleLauncher.exe
Also applied it to the ogplauncher, Still gave the error.
LaTale also requires GC_DONT_GC=1 before the wine command on the downloader for
the client, since it's pandomediabooster.
Get the client here: http://latale.ogplanet.com/en/download/client.og
Pastebin: http://pastebin.com/FTT71zb1
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.
https://bugs.winehq.org/show_bug.cgi?id=45211
Bug ID: 45211
Summary: Steam LTE 4G connection, instability
Product: Wine
Version: 3.0.1
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: shitman71(a)hotmail.com
Distribution: ---
Created attachment 61429
--> https://bugs.winehq.org/attachment.cgi?id=61429
Steam.exe log
With 4G-internet on steam or with wine in general i am having troubles with my
connection, using virtualisation and playing games works flawlessly. Its only
wine making problems.
Starting steam sometimes doesn't work and if it works it only runs a few
minutes and then crashes.
Iam getting the message:
0073:err:ntdll:RtlpWaitForCriticalSection section 0x603375c "?" wait timed out
in thread 0073, blocked by 006e, retrying (60 sec)
My firewall is having no problems, it just sometimes work and sometimes not.
The signal is very good and it is also working on everything else except of
wine.
Iam guessing something is wrong the way wine handles network-connections. So
far i only got this error-message.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=44951
Bug ID: 44951
Summary: Add neon/xenial to your repository
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: roadriverrail(a)gmail.com
Distribution: ---
Created attachment 61058
--> https://bugs.winehq.org/attachment.cgi?id=61058
Error when I add the repository
I use KDE Neon installed on my Ubuntu xenial setup, and Neon requires a
different entry in the repository. Could you please replicate your existing
xenial entries for neon/xenial?
--
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.
https://bugs.winehq.org/show_bug.cgi?id=43436
Bug ID: 43436
Summary: Would it be possible to add Mageia 6 back to the
Install page?
Product: Wine-staging
Version: 2.13
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: arichter(a)lobo.net
CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de,
sebastian(a)fds-team.de
Distribution: ---
I would sure like to see Mageia added back to the wine-staging Install page,
Mageia has been very good about keeping up with the stable releases but staging
is where all the fun is.
I have been successfully building RPMS for both i586 and x86_64 under Mageia 6
and would be glad to submit RPMS or SRPMS for both architectures.
Mageia 6 also now supports mock, which is what I have been using to build the
i586 RPMs under x86_64.
I apologize for submitting this as a bug since it's not a bug but I would
either like to see Mageia back under the Install page or contribute built RPMS
and SRPMS to help make it happen.
I'm a bit new to this RPM building thing but the stuff I've made has worked out
for me, and I've tried to be more active in the winedb.
Thank you for your time and efforts, I only want to help on the Mageia side of
things.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=45556
Bug ID: 45556
Summary: libgtk3-nocsd.so.0
Product: Packaging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: Ulf.Zibis(a)gmx.de
CC: michael(a)fds-team.de, sebastian(a)fds-team.de
Distribution: ---
On Ubuntu 18.04 I get:
$ wine --version
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded
(cannot open shared object file): ignored.
wine-3.0.2
Workaround:
sudo apt install libgtk3-nocsd0:i386
--
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.
https://bugs.winehq.org/show_bug.cgi?id=42430
Bug ID: 42430
Summary: Page fault on read access to 0x78c000bd in 32-bit code
when loading .Net application
Product: Wine
Version: 2.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: franknleslie(a)gmail.com
Distribution: ---
Created attachment 57261
--> https://bugs.winehq.org/attachment.cgi?id=57261
GarminExpressInstaller backtrace 1
When trying to execute GarminExpressInstaller.exe I run into a page fault
exception as the installer window is opening.
Environment:
openSUSE Tumbleweed x86_64
kernel 4.9.8-1-default
wine 2.1
Initially when the installer was launching I was receiving the following error:
fixme:win:EnumDisplayDevicesW ((null),0,0x6c1e414,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x6c1e528,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),1,0x6c1e528,0x00000000), stub!
fixme:d3d:wined3d_guess_card No card selector available for card vendor 0000
(using GL_RENDERER "Gallium 0.4 on llvmpipe (LLVM 3.9, 128 bits)").
I resolved that by installing Mesa-dri-nouveau-32bit (since I have a NVidia
video card).
After restarting the application I am now receiving the following unhandled
exception:
fixme:win:EnumDisplayDevicesW ((null),0,0x6c1e414,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x6c1e528,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),1,0x6c1e528,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x6c1e414,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x6c1e528,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),1,0x6c1e528,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x6c1e414,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x6c1e528,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),1,0x6c1e528,0x00000000), stub!
fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime"): stub
fixme:advapi:ReportEventW
(0xcafe4242,0x0001,0x0000,0x00000402,(nil),0x0001,0x00000000,0x6c1c920,(nil)):
stub
err:eventlog:ReportEventW L"Application: GarminExpressInstaller.exe\nFramework
Version: v4.0.30319\nDescription: The process was terminated due to an
unhandled exception.\nException Info: exception code c0000005, exception
address 7CB686E3\n"
fixme:advapi:DeregisterEventSource (0xcafe4242) stub
wine: Unhandled page fault on read access to 0x78c000bd at address 0x7cb686e3
(thread 0044), starting debugger...
fixme:thread:NtQueryInformationThread info class 16 not supported yet
fixme:service:QueryServiceConfig2W Level 6 not implemented
I have attached the backtrace to this bug.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=5129
--- Comment #24 from dodog <gaal(a)centrum.sk> ---
(In reply to unxed from comment #23)
> Workaround for Mint 19/Ubuntu 18.04.
>
> --
Thank you very much, this workaround really works. I can confirm this on
Manjaro 17 (arch), Wine 3.12 and Faststone 5.2
--
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.