https://bugs.winehq.org/show_bug.cgi?id=49074
Bug ID: 49074
Summary: Nintendulator 0.980 - AVI capture fails due to error
in AVIStreamWrite
Product: Wine
Version: 5.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: avifil32
Assignee: wine-bugs(a)winehq.org
Reporter: quietust(a)gmail.com
Distribution: Ubuntu
In Nintendulator 0.980 (a Nintendo Entertainment System emulator), attempting
to record to an AVI file fails with AVIERR_UNSUPPORTED from
AddAudio::AVIStreamWrite when running in Wine Staging 5.7 on Ubuntu 16.04.6
LTS. The same thing happens in Wine-Devel 5.7.
Given that I am the author of this application, I've been able to track down
exactly what's going wrong.
On Windows, the AVIStreamWrite function treats the "lStart" parameter
differently depending on the stream type - for a Video stream it expects it to
be a frame number (increasing by 1 each time), but for an Audio stream it
expects it to be a *sample* number (increasing by "lSamples" each time). In
Wine, however, Audio streams expect "lStart" to increase by 1 each time, just
like Video streams.
I've built two test versions of my application: one that only works on Windows,
and one that only works in Wine. They can be downloaded from the following URL:
https://www.qmtpro.com/~nes/misc/nintendulator_winebug.zip
(sha1 4eca2a261db3fdaa03cbc92cbee307c56ffffac2)
See
https://github.com/quietust/nintendulator/blob/fc91a2abcbe3ad37a1a6e52f12d8…
for relevant source code - these test versions have lines 273-280 commented out
and have "WineHack" hardcoded (to "false" for the Windows version and "true"
for the Wine version) for the check on line 287.
Steps to reproduce:
1. Download and extract the archive linked above
2. Run "nintendulator_windows.exe stars.nes" in Wine
3. Open the "Misc" menu and select "Start AVI Capture"
4. Enter a filename and press Save
5. Set the Compressor to "Full Frames (Uncompressed)" and press OK
6. Press F2 to start emulation and observe that it fails.
7. Repeat steps 2-6 with "nintendulator_wine.exe" and observe that it now works
correctly.
8. Repeat steps 2-7 on Windows and observe that the results are the other way
around.
--
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=49186
Bug ID: 49186
Summary: DXBC compiler generates incorrect spir-v code
Product: vkd3d
Version: 1.1
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: vkd3d
Assignee: wine-bugs(a)winehq.org
Reporter: alex.fishman(a)gmail.com
Distribution: ---
Created attachment 67204
--> https://bugs.winehq.org/attachment.cgi?id=67204
dxbc tessellaton control shader
I'm having issues with tessellation shaders.
Seems that the generated spir-v code is incorrect. After converting the spir-v
to GLSL (spirv-dis) and validating it (glslangValidator) there are errors in
the the following section:
#version 450
layout(vertices = 5) out;
out float gl_ClipDistance[5];
layout(location = 0) out vec2 o0[5];
layout(location = 1) out vec4 o1[5];
vec4 opc[4];
vec4 v1[5];
void control0()
{
v1[1u] = vec4(gl_ClipDistance[0u]);
v1[2u] = vec4(gl_ClipDistance[1u]);
v1[3u] = vec4(gl_ClipDistance[2u]);
v1[4u] = vec4(gl_ClipDistance[3u]);
v1[5u] = vec4(gl_ClipDistance[4u]);
vec4 r0;
r0.x = intBitsToFloat(gl_InvocationID);
o0[gl_InvocationID] = gl_in[floatBitsToInt(r0.x)].gl_Position.xy;
o1[gl_InvocationID] = v1[floatBitsToInt(r0.x)];
}
...
glslangValidator outputs the following error:
ERROR: 0:4: 'gl_ClipDistance' : identifiers starting with "gl_" are reserved
ERROR: 1 compilation errors. No code generated.
Sample DXBC binary is 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.
https://bugs.winehq.org/show_bug.cgi?id=49301
Bug ID: 49301
Summary: pthread_exit hangs on unwind through
call_thread_exit_func on arm64
Product: Wine
Version: unspecified
Hardware: aarch64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: stefan(a)codeweavers.com
Distribution: ---
Created attachment 67309
--> https://bugs.winehq.org/attachment.cgi?id=67309
Workaround
My arm64 Wine build spins in services.exe after starting up anything. The
backtrace points into pthread_exit() - see attached file backtrace.txt.
I placed pthread_exit calls throughout the thread creation / shutdown code and
it works up to the point where signal_exit_thread() calls
call_thread_exit_func(). After call_thread_exit_func() passes control to the C
function exit_thread() pthread_exit() will hang.
I previously had this problem only in a gcc wine build (with 8fb8cc03
reverted), but recently, presumably after an update to clang-10, the problem
also happens when building Wine with clang. The attached backtrace is from a
build with clang 10.
Calling exit_thread() directly from signal_exit_thread() without going through
call_thread_exit_func works around the problem. See attached file noasm.diff
--
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=49378
Bug ID: 49378
Summary: kernel32.WriteFile with multi byte characters reports
incorrect number of written bytes
Product: Wine
Version: 5.10
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: suokkos(a)gmail.com
Distribution: ---
Created attachment 67438
--> https://bugs.winehq.org/attachment.cgi?id=67438
Wine test case to trigger the bug
Writing utf-8 multibyte characters to stdout using stdio led to uncovering this
bug. Attached test case is a simple way to trigger the underlying issue.
Minimal steps leading to issue:
1. Set console output to CP_UTF8
2. Use WriteFile with multibyte characters
Expect outcome:
WriteFile reports number of bytes written.
Actual outcome:
WriteFile reports number of characters written.
Other observations while writing test case:
I first run same test case using kernelbase.WriteFile. Base version seems to
behavior differently because my test case passed. I only then noticed the
important detail that there is multiple WriteFile entry points.
--
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=45110
Bug ID: 45110
Summary: Crash when running courselab 2.4
Product: Wine
Version: 1.6.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: cjrw42(a)gmail.com
Distribution: ---
Created attachment 61295
--> https://bugs.winehq.org/attachment.cgi?id=61295
courselab 2.4 backtrace
I have installed courselab 2.4 (educational resource dev package which creates
HTML based sites), using the MSI, and all appears to have gone OK. Courselab
runs, grabs credentials, generates the licence key which is emailed and entered
fine, but as soon as you begin to create a new project it crashes out.
backtrace included.
--
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=40223
Bug ID: 40223
Summary: Mesa: User error: GL_INVALID_OPERATION in
glTexImage3D(bad target for depth texture)
Product: Wine
Version: 1.9.4
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ovariegata(a)yahoo.com
Distribution: Slackware
When starting the GOG version of Deus Ex with wine-staging 1.9.4 and a debug
version of mesa this error is printed several times.
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Here is the full output:
$ deusex
preloader: Warning: failed to reserve range 00010000-00110000
preloader: Warning: failed to reserve range 00010000-00110000
fixme:winediag:start_process Wine Staging 1.9.4 is a testing version containing
experimental patches.
fixme:winediag:start_process Please mention your exact version when filing bug
reports on winehq.org.
preloader: Warning: failed to reserve range 00010000-00110000
preloader: Warning: failed to reserve range 00010000-00110000
preloader: Warning: failed to reserve range 00010000-00110000
preloader: Warning: failed to reserve range 00010000-00110000
preloader: Warning: failed to reserve range 00010000-00110000
fixme:module:load_dll Loader redirect from L"uxtheme.dll" to L"uxtheme-gtk.dll"
fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet
fixme:process:GetProcessWorkingSetSize (0xffffffff,0x32f314,0x32f30c): stub
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
Mesa: User error: GL_INVALID_OPERATION in glTexImage3D(bad target for depth
texture)
err:ole:CoGetClassObject class {92fa2c24-253c-11d2-90fb-006008a1f441} not
registered
err:ole:CoGetClassObject no class object {92fa2c24-253c-11d2-90fb-006008a1f441}
could be created for context 0x1
err:ole:CoGetClassObject class {d8f1eee0-f634-11cf-8700-00a0245d918b} not
registered
err:ole:CoGetClassObject no class object {d8f1eee0-f634-11cf-8700-00a0245d918b}
could be created for context 0x1
fixme:winediag:IKsPropertySetImpl_QuerySupport EAX sound effects are enabled -
try to disable it if your app crashes unexpectedly
fixme:ddraw:ddraw7_FlipToGDISurface iface 0x16e2a8 stub!
OS: Slackware-current
Relevant packages:
wine-staging-1.9.4-x86_64-1_SBo
mesa-compat32-847f1cc_2015.12.16_master-x86_64-1_gitcompat32
libdrm-compat32-4274539_2016.02.26_master-x86_64-1_gitcompat32
--
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=43433
Bug ID: 43433
Summary: Sony Vegas Pro 8
Product: Wine
Version: 2.13
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: bameylan(a)bluewin.ch
Distribution: ---
Created attachment 58799
--> https://bugs.winehq.org/attachment.cgi?id=58799
Backtrace genered at the crash
This are the problems I encountered
I am using Linux Mint 18.2 x64.
I installed Sony Vegas Pro 8.0 on wine 2.13. Installation without problem.
But when I tried to run it, it stop at the moment that he "Adding GStreamer
AudioConvert filter"
--
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=49583
Bug ID: 49583
Summary: Assassin's Creed Odyssey displays black bars on top
and bottom.
Product: Wine
Version: 5.13
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: GloriousEggroll(a)gmail.com
Distribution: ---
Created attachment 67739
--> https://bugs.winehq.org/attachment.cgi?id=67739
AC Odyssey black bar fix
It's been a long known issue that AC: Odyssey renders with black bars on the
top and bottom of the screen (see screenshot 1).
Derek Lesho came up with a stub patch that both fixed this -and- allowed STEEP
to run (it would not display previously). That patch can be found here:
https://github.com/GloriousEggroll/proton-ge-custom/blob/5.12-GE-1/patches/…
Recently, the relevant function QueryDisplayConfig was implemented, however it
did not contain some of the changes Derek's patch adds. This allowed steep to
work, however AC: Odyssey still retained the black bar issue.
I modified Derek's patch by adding the relevant parts to QueryDisplayConfig,
and removing the relevant flag checks (Derek's patch did this previously), and
this allowed AC: Odyssey to render properly without the black bars. (see
screenshot 2). The patch is hacky but may provide more information towards
fixing this properly.
--
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=49748
Bug ID: 49748
Summary: Multisim 14.2 installer fails with "Directory name
invalid"
Product: Wine
Version: 5.15
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
When running the installer, it terminates with a MessageBox showing "Directory
name 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.
https://bugs.winehq.org/show_bug.cgi?id=49788
Bug ID: 49788
Summary: mountmgr is no longer detecting SCSI devices
Product: Wine
Version: 5.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: mountmgr.sys
Assignee: wine-bugs(a)winehq.org
Reporter: winebugzilla(a)tasossah.com
Regression SHA1: 19549d11a72f63efe0d689374446a56a68264a1f
Distribution: ---
Created attachment 68104
--> https://bugs.winehq.org/attachment.cgi?id=68104
regedit screenshot
Commit 19549d11a72f63efe0d689374446a56a68264a1f switched to using udisks2 to
detect devices, however this no longer detects SCSI devices.
This results in ASPI_GetNumControllers always returning 0, and ASPI
applications not detecting any optical drives.
Compiling wine one commit before the one mentioned above
(8388ea840fedbb9b646213a26cd59ceb3a48680b) restores the ability to detect and
use SCSI devices.
Tested on two different Ubuntu 20.04 installations, both with fully functional
udisks2.
Steps to reproduce:
Start up wine regedit
Navigate to HKLM\Hardware\DEVICEMAP\Scsi
Observe that it is empty
When functioning correctly, it should report all SCSI devices, including hard
disks and optical drives. In general, all devices that exist in /proc/scsi/scsi
should show up in the registry.
https://bugs.winehq.org/show_bug.cgi?id=31592 was opened presumably to move
away from /proc/scsi, however it is now a regression.
--
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=49825
Bug ID: 49825
Summary: GetNamedSecurityInfoA with LABEL_SECURITY_INFORMATION
returns ERROR_ACCESS_DENIED
Product: Wine
Version: 5.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: advapi32
Assignee: wine-bugs(a)winehq.org
Reporter: vladimir.kokovic(a)gmail.com
Distribution: ---
Created attachment 68159
--> https://bugs.winehq.org/attachment.cgi?id=68159
wine log file
Hi,
I don't understand at all what this is all about even though I have a complete
WINEDEBUG log, when it comes to GetNamedSecurityInfoA with
LABEL_SECURITY_INFORMATION where ERROR_ACCESS_DENIED returns.
Although at first glance everything is normal, it is obvious that I do not know
enough wine and that is why I need help to resolve this situation and if
possible remove this bug for the sake of others and not just me.
Attached are 2 files:
1. TestGetNamedSecurityInfoA.cpp - test program
2. WINEDEBUG.log - part of a very large log file
--
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=50002
Bug ID: 50002
Summary: BlackBerry (Research in Motion) USB and Modem Drivers
installs files in the wrong place and fails to install
kernel drivers
Product: Wine
Version: 5.19
Hardware: x86-64
URL: https://swdownloads.blackberry.com/Downloads/contactFo
rmPreload.do?code=A8BAA56554F96369AB93E4F3BB068C22&dl=
F5937D3FABCEC4C05D26AB6F3FEEC891
OS: Linux
Status: NEW
Keywords: download, Installer
Severity: normal
Priority: P2
Component: msi
Assignee: wine-bugs(a)winehq.org
Reporter: z.figura12(a)gmail.com
Distribution: ---
Created attachment 68409
--> https://bugs.winehq.org/attachment.cgi?id=68409
hack: set CommonFiles64Folder to the 32-bit common files dir
The installer is more than a bit of a mess. It seems to be trying to install
64-bit files into the 64-bit "Common Files" folder, and 32-bit files into the
32-bit folder. It has this <trimmed> in its Directory table:
Directory Directory_Parent DefaultDir
----------------------------------------------------------
TARGETDIR SourceDir
RESEARCH_IN_MOTION ProgramFilesFolder RESEAR~1|Research In Motion
BLACKBERRY RESEARCH_IN_MOTION BLACKB~1|BlackBerry
INSTALLDIR BLACKBERRY .
CommonFiles64Folder TARGETDIR .:Common64
CommonFilesFolder TARGETDIR .:Common
CommonFilesRIM.191... CommonFilesFolder RESEAR~1|Research In Motion
CommonFilesRIM.07D... CommonFiles64Folder RESEAR~1|Research In Motion
On Wine this behaves essentially as expected, and files get installed into
64-bit "Common Files". On Windows, however, for some reason, everything gets
installed into the 32-bit "Common Files" directory. This problem is compounded
when the program subsequently tries to install PnP drivers (from a 64-bit
custom action) using files from the 32-bit "Common Files" folder—working around
their own bug, I guess—and on Wine nothing gets installed.
I'm more than a little baffled as to how this could possibly break on Windows.
It'll probably take some more involved debugging.
Anyway, the attached patch works around the bug. The installer successfully
creates a couple of root PnP devices, but the driver subsequently fails to load
due to missing WDF. (In fact it needs quite a substantial chunk of WDF, which I
have partially implemented in my local tree).
--
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=50299
Bug ID: 50299
Summary: Application tried to create a window, but no driver
could be loaded.
Product: Wine
Version: 5.22
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: bernhardu(a)mailbox.org
Distribution: ---
0050:err:winediag:nodrv_CreateWindow Application tried to create a window, but
no driver could be loaded.
Running e.g. "wine notepad" in a quite slow environment for example within
rr-debugger inside a VM leads to the above message.
As far as I could follow in above line 0050 is "explorer.exe".
Unfotunately winemenubuilder.exe was a little bit earlier with requesting
the first window in WIN_CreateWindowEx
before explorer.exe reached manage_desktop.
Therefore explorer.exe never SetPropW("__wine_display_device_guid")
in DesktopWndProc.
This race might not show up under normal conditions, but I thought to
document it here to be findable.
Making winemenubuilder.exe sleep some time in wWinMain before CoInitialize
works around it.
--
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=50109
Bug ID: 50109
Summary: 0414:fixme:conhost:write_console beep
Product: Wine
Version: 5.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: azraeladdy(a)gmail.com
Distribution: ---
Created attachment 68600
--> https://bugs.winehq.org/attachment.cgi?id=68600
Output from a simple C program. Along with its code.
Occurs when outputting the BEL ASCII character. Nothing huge, but a worthy
thing to keep track of? Not much else to say, possibly other ASCII characters
that wine has a fix me statement for?
--
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=50187
Bug ID: 50187
Summary: programs/conhost/window.c:2310 - Unhandled exception:
divide by zero in 64-bit code
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: vladimir.kokovic(a)gmail.com
Distribution: ---
Created attachment 68703
--> https://bugs.winehq.org/attachment.cgi?id=68703
backtrace.log
When my console application starts, wine reports an exception for which I don't
see any real reason.
Attached is the backtrace.log of the moment this exception occurs.
--
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=40099
Bug ID: 40099
Summary: IFileOpenDialog with FOS_PICKFOLDERS option
Product: Wine
Version: 1.9.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: nozomimasao(a)gmail.com
Distribution: ---
IFileOpenDialog sometimes returns a bad path if FOS_PICKFOLDERS option is
specified.
for example, if you selected C:\Windows folder *inside* Windows folder,
GetResult method returns C:\Windows\Windows.
Steps of the user:
1. Go inside C:\Windows by double-clicking Windows folder.
2. Click select button.
Then the path will be C:\Windows\Windows.
*The user can avoid this issue by below steps.
1. Select C:\Windows by clicking Windows folder *without* going inside it.
2. Click select button.
Then the path will be C:\Windows.
For your information, the code is like this;
IFileOpenDialog *fo = nullptr;
CoCreateInstance(CLSID_FileOpenDialog, NULL, CLSCTX_INPROC_SERVER,
IID_PPV_ARGS(&fo));
DWORD opt = 0;
fo->GetOptions(&opt);
fo->SetOptions(opt | FOS_PICKFOLDERS);
fo->Show(hWnd);
IShellItem *si = nullptr;
fo->GetResult(&si);
LPWSTR path = nullptr;
si->GetDisplayName(SIGDN_FILESYSPATH, &path);
--
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=44094
Bug ID: 44094
Summary: need for speed carbon game is working but only audio
is coming , no display comes and looks like evry thing
hangs
Product: Wine
Version: 1.6.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winelib
Assignee: wine-bugs(a)winehq.org
Reporter: srivastava.avichal(a)gmail.com
Distribution: ---
Created attachment 59816
--> https://bugs.winehq.org/attachment.cgi?id=59816
need for speed carbon game is working but only audio is coming , no display
comes and looks like evry thing hangs
my wine never work properly,
it never installs an application, nor updates nor unstalls
--
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=17277
Summary: Remote virtual memory allocation error
Product: Wine
Version: 1.1.13
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: loader
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: gabmoa(a)yahoo.it
ZFlash is a win32 application used to simulate and edit part programs
for a cnc. The simulator part is achieved running a reduced version
of numerical control into a fixed memory map from 1 to 8 MB (the current
version is from 1-16 MB but it's the same principle). The numerical control
need to be mapped in this way because it uses fixed addresses.
The application runs in NT 4 SP6, 2000, XP and Vista MS OS but in wine
it doesn't work.
I have seen there is a problem in the memory mapping when I try to run the
application into wine so I've created a reduced example with the only
"incriminated" part. In the attached zip file there are 3 projects:
ZLoader, Z32Sim and Test.
The steps involved are the same of the complete win32 application.
ZLoader.exe create the process 'Test', suspended, and try to reserve memory
of 'Test' from 1 to 8 MB, then it resumes the process.
Test.exe is compiled with the linker flags
/base:"0x800000" /stack:0x800000,0x1000
so the big stack can not be inserted into the first 8MB and the
base of exe is changed from the default 4MB assigned by Visual Studio.
Z32Sim.dll is loaded into 'Test' and it have to map the memory (1-8MB).
To test it in the Debug directory we can execute ZLoader Test.exe
In wine Test fail when ZLoader try to resume it (I've seen that with winedbg)
with the following error:
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr
0x7ef9e617
Unfortunately it seems a not so easy task because with winedbg I can't
attach to Test process when it's suspended.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=20439
Summary: TroopMaster hangs on startup
Product: Wine
Version: 1.1.31
Platform: PC-x86-64
URL: http://www.troopmaster.com
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: al_turner(a)comcast.net
TroopMaster installs, but hangs on startup. Main window will not activate
(animation works, but no response to keyboard or mouse). Does not even get to
the DotNet download hangup as mentioned in bug 8997. More like 18801 but I
don't even get the popup window showing the attempt to connect to FTP.
As far as I can tell, the FTP attempt only happens if you activate the DOTNET
function (after installing the software). I have not been able to get to the
point of activating the DOTNET since I can't get it that far yet.
I followed the HOWTO from the AppDB that describes the install/kill/restart
process.
--
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=47150
Bug ID: 47150
Summary: [Overwatch] Game freezes when new menu music starts
playing
Product: Wine
Version: 4.7
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: hewanci(a)gmail.com
Distribution: ---
Few days ago the new Lucio and Mercy League skins were introduced, and the menu
got a new music, and a showcase of aforementioned new skins.
Since then the game freezes as soon as the menu music starts playing. The music
(and later the regular menu ambient music) still plays, but the GUI is frozen
and unresponsive.
The only workaround I could find was to very quickly open one of the sub-pages
(eg. Play, Hero gallery, etc.) before the music starts. This way the music will
never play, and then I can go back to the menu and everything works fine,
including the showcase of the new skins playing in the background.
Arch Linux, fully updated
Wine Staging 4.7
--
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=48054
Bug ID: 48054
Summary: gdi32:bitmap fails on Windows XP and 2003
Product: Wine
Version: unspecified
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: gdi32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
gdi32:bitmap started failing on Windows XP and 2003 right after the winehq.org
upgrade:
bitmap.c:1015: Test failed: StretchDIBits failed for 32/62/0/0
bitmap.c:1023: Test failed: GetDIBits failed for 32/62/0/0
bitmap.c:1052: Test failed: StretchDIBits failed for 32/62/0/0
(repeated 12 times)
See http://winetest.dolphin/data/tests/gdi32:bitmap.html
See also the attached screenshot showing the failures did start on Sept 09.
And this wine-devel thread:
https://www.winehq.org/pipermail/wine-devel/2019-October/152082.html
The failures are systematic and happen on all machines running one of these two
Windows versions. What's strange is that the TestBot's wxppro and w2003std VMs
have not been modified in this timeframe and neither has the gdi32:bitmap test.
In fact this appears related to the compiler which would explain why the
failure started when winehq.org (which builds the official WineTest binaries)
was upgraded to Debian 10.
Specifically, letting wtbbuild, which still runs Debian 9.9
(i686-w64-mingw32-gcc 6.3.0 20170516), compile the test binaries results in no
failure:
https://testbot.winehq.org/JobDetails.pl?Key=59354
But using a binary compiled with i686-w64-mingw32-gcc 8.3-win32 20190406 (in
this case on my development machine) produces the 36 failures:
https://testbot.winehq.org/JobDetails.pl?Key=59355
Either that or it's quite possibly a result of the new everything-as-PE vs. the
old cross-compilation approach still used by wtbbuild.
--
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=28083
Summary: Agenda Circling Forth GPU particle demo:bunch of fixme
and errors
Product: Wine
Version: 1.3.26
Platform: x86
URL: http://downloads.guru3d.com/Agenda-Circling-Forth-GPU-
particle-demo-download-2591.html
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: 810d4rk(a)gmail.com
Created an attachment (id=35956)
--> (http://bugs.winehq.org/attachment.cgi?id=35956)
terminal
It is not possible to see the techdemo as intended due to bugs.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=24631
Summary: listview NM_HOVER tests sometimes fail
Product: Wine
Version: 1.3.4
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: comctl32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austin.lund(a)gmail.com
The NM_HOVER tests sometimes give:
listview.c:468: listview: 0063016A, 02a1, 00000000, 00000000
listview.c:4433: Test failed: NM_HOVER allow test: the msg sequence is not
complete: expected 0087 - actual 0000
listview.c:468: listview: 0063016A, 02a1, 00000000, 00000000
listview.c:4438: Test failed: NM_HOVER block test: the msg sequence is not
complete: expected 0087 - actual 0000
For example:
http://test.winehq.org/data/79ed8429319509db1ca7723661af5fb4a8017320/win7_w…
Whereas a non-failing situation gives:
listview.c:468: listview: 000000000063016A, 02a1, 00000000, 00000000
listview.c:327: parent: 0000000000230172, 0087, 00000000, 00000000
listview.c:327: parent: 0000000000230172, 004e, 00000000, 0022f4e0
listview.c:4433: expected 0087 - actual 0087
listview.c:4433: expected 004e - actual 004e
listview.c:468: listview: 000000000063016A, 02a1, 00000000, 00000000
listview.c:327: parent: 0000000000230172, 0087, 00000000, 00000000
listview.c:327: parent: 0000000000230172, 004e, 00000000, 0022f4e0
listview.c:4438: expected 0087 - actual 0087
listview.c:4438: expected 004e - actual 004e
--
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=48061
Bug ID: 48061
Summary: WineTest: get_subtests() fails randomly
Product: Wine
Version: unspecified
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: testcases
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Sometimes the DLL version section contains lines like:
mfplat=load error 1359
shell32=load error 1359
user32=load error 1359
See
https://test.winehq.org/data/6f2ef158b78f7d0a950c9398c26278d6523c112e/win10…
This happens on all VMs. 1359 is ERROR_INTERNAL_ERROR which get_subtests()
returns when it fails to parse the test list. But it could also come from
GetLastError() though that seems somewhat unlikely.
In some cases this may make sense. For instance I assume that mfplat.dll is not
available on Windows XP so it could make sense to have this error there, though
one would rather expect a 'missing' error.
But this error happened to shell32 and user32 on Windows 10 as in the example
above!!!
This impacts the WineTest results which then impacts the ability of the TestBot
to detect new failures. So this needs to be investigated.
--
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=43377
Bug ID: 43377
Summary: valgrind shows an invalid read in
dlls/msxml3/tests/domdoc.c
Product: Wine
Version: 2.12
Hardware: x86
OS: Linux
Status: NEW
Keywords: download, source, testcase, valgrind
Severity: normal
Priority: P2
Component: msxml3
Assignee: wine-bugs(a)winehq.org
Reporter: austinenglish(a)gmail.com
Distribution: Debian
../../../tools/runtest -q -P wine -T ../../.. -M msxml3.dll -p
msxml3_test.exe.so domdoc && touch domdoc.ok
==30037== Invalid free() / delete / delete[] / realloc()
==30037== at 0x7BC510DB: notify_free (heap.c:262)
==30037== by 0x7BC556AC: RtlFreeHeap (heap.c:1762)
==30037== by 0x5F97B28: heap_free (msxml_private.h:189)
==30037== by 0x5F9837F: free_properties (domdoc.c:360)
==30037== by 0x5F98CA3: xmldoc_release_refs (domdoc.c:624)
==30037== by 0x5F98CEA: xmldoc_release (domdoc.c:635)
==30037== by 0x5FC36D8: destroy_xmlnode (node.c:1481)
==30037== by 0x5F99C3C: domdoc_Release (domdoc.c:966)
==30037== by 0x4A525C0: IXMLDOMDocument2_Release (msxml2.h:4413)
==30037== by 0x4A525C0: test_get_ownerDocument (???:0)
==30037== by 0x4A76882: func_domdoc (domdoc.c:12609)
==30037== by 0x4AB1624: run_test (test.h:603)
==30037== by 0x4AB1A83: main (test.h:687)
==30037== Address 0x48e0820 is 18 bytes after a recently re-allocated block of
size 46 alloc'd
==30037== at 0x7BC51061: notify_alloc (heap.c:254)
==30037== by 0x7BC5554F: RtlAllocateHeap (heap.c:1716)
==30037== by 0x5608BD0: strdupW (freetype.c:1098)
==30037== by 0x560A0ED: load_face (freetype.c:1650)
==30037== by 0x560A862: load_font_list_from_cache (freetype.c:1778)
==30037== by 0x56132B5: WineEngInit (freetype.c:4402)
==30037== by 0x5622222: DllMain (gdiobj.c:677)
==30037== by 0x5641491: __wine_spec_dll_entry (dll_entry.c:40)
==30037== by 0x7BC57861: ??? (loader.c:150)
==30037== by 0x7BC5A291: MODULE_InitDLL (loader.c:1121)
==30037== by 0x7BC5A7E1: process_attach (loader.c:1222)
==30037== by 0x7BC5A728: process_attach (loader.c:1210)
==30037== by 0x7BC5A728: process_attach (loader.c:1210)
==30037== by 0x7BC5A728: process_attach (loader.c:1210)
==30037== by 0x7BC5A728: process_attach (loader.c:1210)
==30037== by 0x7BC5FB42: attach_process_dlls (loader.c:3011)
==30037== by 0x40413EC: ??? (port.c:78)
==30037==
==30037== Invalid free() / delete / delete[] / realloc()
==30037== at 0x7BC510DB: notify_free (heap.c:262)
==30037== by 0x7BC556AC: RtlFreeHeap (heap.c:1762)
==30037== by 0x5F97B28: heap_free (msxml_private.h:189)
==30037== by 0x5F9839F: free_properties (domdoc.c:362)
==30037== by 0x5F98CA3: xmldoc_release_refs (domdoc.c:624)
==30037== by 0x5F98CEA: xmldoc_release (domdoc.c:635)
==30037== by 0x5FC36D8: destroy_xmlnode (node.c:1481)
==30037== by 0x5F99C3C: domdoc_Release (domdoc.c:966)
==30037== by 0x4A525C0: IXMLDOMDocument2_Release (msxml2.h:4413)
==30037== by 0x4A525C0: test_get_ownerDocument (???:0)
==30037== by 0x4A76882: func_domdoc (domdoc.c:12609)
==30037== by 0x4AB1624: run_test (test.h:603)
==30037== by 0x4AB1A83: main (test.h:687)
==30037== Address 0x49065a0 is 4 bytes after a block of size 92 free'd
==30037== at 0x7BC510DB: notify_free (heap.c:262)
==30037== by 0x7BC556AC: RtlFreeHeap (heap.c:1762)
==30037== by 0x55FF13A: FONT_DeleteObject (font.c:814)
==30037== by 0x5622F04: DeleteObject (gdiobj.c:982)
==30037== by 0x532BDF5: get_text_metr_size (sysparams.c:482)
==30037== by 0x532C66E: normalize_nonclientmetrics (sysparams.c:653)
==30037== by 0x532F087: SystemParametersInfoW (sysparams.c:1610)
==30037== by 0x53321D2: GetSystemMetrics (sysparams.c:2459)
==30037== by 0x5331F4F: GetSystemMetrics (sysparams.c:2394)
==30037== by 0x53183B5: NC_AdjustRectOuter (nonclient.c:115)
==30037== by 0x53190E0: NC_HandleNCCalcSize (nonclient.c:414)
==30037== by 0x52CCDB6: DEFWND_DefWinProc (defwnd.c:262)
==30037== by 0x52CEB60: DefWindowProcW (defwnd.c:1023)
==30037== by 0x6DFA03C: notif_wnd_proc (bindprot.c:83)
==30037== by 0x53502FD: ??? (winproc.c:174)
==30037== by 0x535044C: call_window_proc (winproc.c:245)
==30037== by 0x5352800: WINPROC_call_window (winproc.c:901)
==30037== by 0x530DC60: call_window_proc (message.c:2224)
==30037== by 0x5310C82: send_message (message.c:3269)
==30037== by 0x5311413: SendMessageW (message.c:3469)
==30037== Block was alloc'd at
==30037== at 0x7BC51061: notify_alloc (heap.c:254)
==30037== by 0x7BC5554F: RtlAllocateHeap (heap.c:1716)
==30037== by 0x55FE62B: CreateFontIndirectExW (font.c:509)
==30037== by 0x55FE908: CreateFontIndirectW (font.c:559)
==30037== by 0x532BD42: get_text_metr_size (sysparams.c:470)
==30037== by 0x532C66E: normalize_nonclientmetrics (sysparams.c:653)
==30037== by 0x532F087: SystemParametersInfoW (sysparams.c:1610)
==30037== by 0x53321D2: GetSystemMetrics (sysparams.c:2459)
==30037== by 0x5331F4F: GetSystemMetrics (sysparams.c:2394)
==30037== by 0x53183B5: NC_AdjustRectOuter (nonclient.c:115)
==30037== by 0x53190E0: NC_HandleNCCalcSize (nonclient.c:414)
==30037== by 0x52CCDB6: DEFWND_DefWinProc (defwnd.c:262)
==30037== by 0x52CEB60: DefWindowProcW (defwnd.c:1023)
==30037== by 0x6DFA03C: notif_wnd_proc (bindprot.c:83)
==30037== by 0x53502FD: ??? (winproc.c:174)
==30037== by 0x535044C: call_window_proc (winproc.c:245)
==30037== by 0x5352800: WINPROC_call_window (winproc.c:901)
==30037== by 0x530DC60: call_window_proc (message.c:2224)
==30037== by 0x5310C82: send_message (message.c:3269)
==30037== by 0x5311413: SendMessageW (message.c:3469)
==30037==
--
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.