https://bugs.winehq.org/show_bug.cgi?id=42030
Bug ID: 42030
Summary: winedbg: Internal crash at 0x9f58fd40
Product: Wine
Version: 1.8.1
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winedbg
Assignee: wine-bugs(a)winehq.org
Reporter: kenorb(a)gmail.com
Distribution: ---
The following command crashes:
$ winedbg --command < <(echo help)
winedbg: Internal crash at 0x9f58fd40
Probably syntax isn't right, but still shouldn't internally crash.
--
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=51821
Bug ID: 51821
Summary: EVE Online Sisi Client Crashes Due to differences in
how Wine and Windows handle LoadLibraryExW Undefined
Behavior
Product: Wine
Version: 6.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: algebro(a)tuta.io
Distribution: ---
I've been chasing this for the last few days and think I may finally have
enough information to finally open a bug report. As of a few days ago, the Sisi
testing client for EVE stopped working in recent versions of Wine, and the logs
showed an unhandled Python error in a module called launchdarkly_client.pyd:
```ImportError: Failed to load DLL: Success```
I chased this down in a debugger and noticed they're passing a relative path to
LoadLibraryExW for this library only (full/absolute paths for every other
module), and 8 for dwFlags:
```hLibModule = LoadLibraryExW((LPCWSTR)plVar4[3],(HANDLE)0x0,8)```
Per the Microsoft documentation, 8 for dwFlags is undefined when the first
argument is a relative path:
https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloade…
Weirdly enough, the library loads fine on Windows (I've confirmed in windbg),
but it fails with error code 0x7e (Module not found) when trying to load it in
wine. Other users running Wine 4.4 say Sisi launches fine and doesn't run into
the error, although I havent been able to get older versions to build to try
and test it, but it sounds like there is a difference between how recent Wine
versions implement LoadLibraryExW() and how Windows does, at least with regards
to the undefined behavior.
Let me know if I can provide any other information that would be helpful for
tracking this down.
Thanks!
--
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=52224
Bug ID: 52224
Summary: inetmib1:main test times out in linux
Product: Wine
Version: 7.0-rc1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: bernhardu(a)mailbox.org
Distribution: ---
inetmib1 times out regularly in testbot.
https://test.winehq.org/data/patterns.html#inetmib1:main
--
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=52200
Bug ID: 52200
Summary: Yamizome Liberator (demo): In game video isn't played.
Product: Wine
Version: 6.23
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winegstreamer
Assignee: wine-bugs(a)winehq.org
Reporter: sagawa.aki+winebugs(a)gmail.com
Distribution: Ubuntu
Yamizome Liberator -Yamiochi Yuusha to Ochiru Senki- Trial Edition[1] is a demo
version of NSFW visual novel released in 2020 by Escu:de in Japan.
After playing through the demo, I noticed in-game video isn't played when it
should be.
In detail, opening video, opening.wmv, should be played when the title screen
is idle for 60 seconds. Please note that the playback only happens after
playing through the demo due to some reason.
[1] https://vndb.org/r75003
--
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=52076
Bug ID: 52076
Summary: Wrong icons placement when using a theme
Product: Wine
Version: 6.22
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: uxtheme
Assignee: wine-bugs(a)winehq.org
Reporter: aros(a)gmx.com
Distribution: ---
Application: WinSCP
Just compare the screenshots. One is without using themes, the other one with
the default Light theme.
--
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=51220
Bug ID: 51220
Summary: version:info - The GetFileVersionInfoEx() checks fail
in non-English locales
Product: Wine
Version: 6.8
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: version
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The GetFileVersionInfoEx() checks fail in non-English locales because the
returned information seems to be localized even when they shouldn't be, i.e.
for flags=0 and flags=FILE_VER_GET_NEUTRAL:
https://test.winehq.org/data/patterns.html#version:info
fr_FR:
info.c:709: Test failed: [0] got 1036, expected lang is 1033
ja_JP:
info.c:709: Test failed: [0] got 1041, expected lang is 1033
I suspect this is because this code block in GetFileVersionInfoSizeExW()
systematically fails to find the English resource:
LANGID english = MAKELANGID( LANG_ENGLISH, SUBLANG_DEFAULT );
hRsrc = FindResourceExW( hModule,
MAKEINTRESOURCEW(VS_VERSION_INFO),
(LPWSTR)VS_FILE_INFO, english );
I tried some alternative combinations for MAKELANGID() (though maybe not the
right one) to no avail. So it's unclear to me if the issue is a bug in
FindResourceExW() or an issue in the set up of the file version information in
kernel32.dll.
Note:
* The fg-deb64-* tests are run in the fr_FR.UTF-8 locale.
--
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=32183
Bug #: 32183
Summary: Cannot open console device read only, then read from
it to get input
Product: Wine
Version: 1.5.17
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: us(a)edmeades.me.uk
Classification: Unclassified
Created attachment 42462
--> http://bugs.winehq.org/attachment.cgi?id=42462
CON test program (source and exe)
(Email sent to wine-devel for assistance, but logging bug to track issue in
case I do not get anywhere)
CreateFile("\\.\CON", GENERIC_READ...) followed by ReadFile(...) works on
windows and fails on wine. I need this particular sequence of events to work in
order for a patch I have for cmd.exe to support CON input 'nicely' (read
'without hacks').
For simplicity sake I've cut this down to a tiny test program, which works on
windows and fails on wine which does the following:
Opens the device ("\\.\CON") with CreateFile with GENERIC_READ rights (which
internally opens a CONIN$ device with the same access rights)
Reads from the device with ReadFile
- Because its a console device, this drops through to ReadConsoleW, which
creates a CONOUT$ and then waits on a keystroke
- Once the key is pressed (WCEL_Get) the key is 'inserted' into the input
buffer by calling WriteConsoleInputW
The issue is that WriteConsoleInputW requires GENERIC_WRITE access, but the CON
device (\\.\CON) was opened as GENERIC_READ (and in fact fails if I try to open
it with GENERIC_WRITE). CreateFile("CONIN$"...) will let me open in
GENERIC_READ/GENERIC_WRITE mode and the program works on both windows and wine,
but if you open CONIN$ GENERIC_READ only then it fails on wine and works on
windows, with the same issue.
Now on windows, this works... the question is how to make it work on wine...
My gut feeling, with nothing backing this at all, is that WCEL_Get should not
use WriteConsoleInputW to inject the values into the input buffer, instead
making the server call directly, but passing through to the server call
something to indicate that it is ok to add the data to the buffer, but I'm fast
getting out of my depth!
How to reproduce: Compile sample source (exe provided in zip)...
Run as:
"test 1" - this is the one I need to work... \\.\CON GENERIC_READ case
"test 2" - this is a similar problem but opens CONIN$ GENERIC_READ
"test 3" - this works on both windows and wine, opening CONIN$
GENERIC_READ|GENERIC_WRITE
"test 4" - this fails on both windows and wine as you cannot open CON device
with WRITE access
Except for case 4, When its 'failing' - when you press a key in wine, it exits.
When its 'working' it reads from keyboard, echos to screen until ctrl+Z (crtl+D
on wine) is pressed and ends
--
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=51911
Bug ID: 51911
Summary: vbscript does not handle strings in if clauses
Product: Wine
Version: 6.19
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: vbscript
Assignee: wine-bugs(a)winehq.org
Reporter: sloper42(a)yahoo.com
Distribution: ---
This is followup from https://bugs.winehq.org/show_bug.cgi?id=50758
Test with postgresql-9.3 installer from [1]. It runs a script during
installation
similar to
https://github.com/three-plus-three/tpt_env_amd64/blob/master/postgresql/in…
that reports non-critical error to main install, script itself terminates.
Reduced test case for this looks like this:
---
if "0" then
end if
---
That leads to the following fixme, exactly that happens with the installer:
---
00f8:fixme:vbscript:stack_pop_bool unsupported for 000000000003C740 {VT_BSTR:
L"0"}
---
[1] https://www.enterprisedb.com/postgresql-tutorial-resources-training?cid=340
--
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=51396
Bug ID: 51396
Summary: cl.exe sometimes fails with internal compiler error
Product: Wine
Version: 6.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: rpisl(a)seznam.cz
Distribution: ---
Cl.exe from MSVC 2019 Build Tools sometimes fails with: "fatal error C1001:
Internal compiler error." A workaround is setting vcruntime140_1 to native.
This is possibly caused by unsupported flag in __CxxFrameHandler4:
0b24:fixme:seh:__CxxFrameHandler4 unsupported flags: 7a
which is unsupported FUNC_DESCR_IS_SEPARATED in
dlls/vcruntime140_1/except_x86_64.c
Not critical since the workaround exists. I'm ready to test this when the flag
is implemented.
--
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.