https://bugs.winehq.org/show_bug.cgi?id=51538
Bug ID: 51538
Summary: Control can no longer launch from an ntfs partition
Product: Wine-staging
Version: 6.13
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ritalat(a)fastmail.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Created attachment 70377
--> https://bugs.winehq.org/attachment.cgi?id=70377
control console output
I have a shared NTFS partition that I have used between Arch Linux and Windows
10 for a few years now. I have been able to play games such as Control in the
past from it. Now multiple games fail to launch from that partition with
similar "err:module:import_dll Library X not found" errors. Copying the entire
game to a ext4 partition fixes the issue.
--
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=50526
Bug ID: 50526
Summary: ConEmu wineconsole Ctrl+m has different behavior
Product: Wine
Version: 6.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: inseng
Assignee: wine-bugs(a)winehq.org
Reporter: adrianekaleksander(a)gmail.com
Distribution: ---
Cmd on Windows:
Ctrl+M moves the cursor to the next line (ENTER key)
On wine:
Ctrl+M shows ^M
1.Open wineconsole
2.Press ctrl+m
--
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=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=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=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.
https://bugs.winehq.org/show_bug.cgi?id=51195
Bug ID: 51195
Summary: Lara Croft and the Temple of Osiris doesn't launch
Product: Wine
Version: 6.9
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
Distribution: ---
Created attachment 70069
--> https://bugs.winehq.org/attachment.cgi?id=70069
log
d3dcompiler_43 - native,builtin
d3dx11_43 - native,builtin
(Otherwise the game fails after hitting 'Play' with "Failed to initialize
Direct3D with current settings")
msvcr110 - native,builtin (for launcher) Bug 49541
Assertion failed: iface->lpVtbl == &d3d11_rendertarget_view_vtbl, file
../wine/dlls/d3d11/view.c, line 1794
04d4:warn:d3d11:d3d_rendertarget_view_init Failed to create a wined3d
rendertarget view, hr 0x80070057.
04d4:warn:d3d11:d3d_rendertarget_view_create Failed to initialize rendertarget
view, hr 0x80070057.
wine-6.9-148-gce151dd681f
--
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=50714
Bug ID: 50714
Summary: CMS client stopped working after latest wine update
Product: Wine
Version: 6.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: denis.salmanovich(a)gmail.com
Distribution: ---
Created attachment 69460
--> https://bugs.winehq.org/attachment.cgi?id=69460
errors backtrace
Hello,
I am using version 5.9 of wine and CMS client
(https://camerayoosee.com/yoosee-cap-nhat-phien-ban-phan-mem-cms-client-moi-…)
version 1.0.0.53 and it works fine.
But if I want to update wine version to latest/newer (5.12 or 6.1) - I get
error after login screen. Tried on two different machines with different
kernels (both stack traces attached).
--
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.