February 2012 - Wine-Bugs - list.winehq.org

[Bug 26673] New: wine start foo.url does not open the url
by wine-bugs＠winehq.org March 29, 2025

March 29, 2025

http://bugs.winehq.org/show_bug.cgi?id=26673 Summary: wine start foo.url does not open the url Product: Wine Version: 1.3.17 Platform: x86 OS/Version: Linux Status: NEW Keywords: download, testcase Severity: minor Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com An application I installed provides a nice little .url file: ----------- [InternetShortcut] URL=http://www.winehq.org/ ----------- on windows, double clicking that opens up my default browser and gives me the webpage. Running 'cygstart foo.url' in windows does the same (wrapper around windows start.exe). On wine, however, I get: fixme:exec:SHELL_execute flags ignored: 0x00000100 Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: Success and I don't get a nice wine gecko window :(. perhaps it only needs to be added to tools/wine.inf? -- 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.

2 9

[Bug 14218] New: OleLoadPictureEx is not fully implemented (ole32)
by wine-bugs＠winehq.org March 21, 2025

March 21, 2025

http://bugs.winehq.org/show_bug.cgi?id=14218 Summary: OleLoadPictureEx is not fully implemented (ole32) Product: Wine Version: 1.1.0 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: mehlers(a)adata.de Created an attachment (id=14504) --> (http://bugs.winehq.org/attachment.cgi?id=14504) Wine Output for OleLoadPictureEx The Main Window of our Software under Windows shows a Picture. If we use the builtin-Version of ole32 the Picture is not displayed. It seems that "OleLoadPictureEx" ist not fully implemented. See attachment "output.txt" for more information. adata Software GmbH Michael Ehlers -- 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.

2 26

[Bug 22846] New: wine's internet explorer can't download firefox
by wine-bugs＠winehq.org March 12, 2025

March 12, 2025

http://bugs.winehq.org/show_bug.cgi?id=22846 Summary: wine's internet explorer can't download firefox Product: Wine Version: 1.2-rc1 Platform: x86 URL: http://www.getfirefox.com OS/Version: Linux Status: NEW Keywords: download Severity: minor Priority: P2 Component: mshtml AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com As everyone who's installed Windows (and isn't in the EU) knows, the main use of Internet Explorer is to download firefox. Unfortunately, wine's IE can't download firefox: $ wine iexplore.exe http://www.getfirefox.com Click download, choose windows, and...nothing. Relevant terminal output: fixme:mshtml:nsChannel_IsNoStoreResponse (0x2a06a38)->(0x32ee7c) fixme:mshtml:nsChannel_IsNoCacheResponse (0x2a06a38)->(0x32ee78) fixme:mshtml:nsChannel_Cancel (0x2a06a38)->(804b0002) fixme:mshtml:nsHttpChannelInternal_SetDocumentURI (0x2affaf8)->() fixme:mshtml:nsChannel_SetReferrer (0x2affaf8)->(0x2bf3b38) fixme:shdocvw:ClOleCommandTarget_Exec Unimplemented group {000214d1-0000-0000-c000-000000000046} fixme:urlmon:Binding_Abort (0x2b46008) fixme:shdocvw:ClOleCommandTarget_Exec Unimplemented group {000214d1-0000-0000-c000-000000000046} fixme:mshtml:HttpNegotiate_GetRootSecurityId (0x2b162b0)->(0x32f108 0x32f34c 0) fixme:wininet:InternetLockRequestFile STUB err:mshtml:read_stream_data buffer is full -- 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.

2 11

[Bug 25532] New: iTunes under Wine doesn't find shared libraries
by wine-bugs＠winehq.org March 12, 2025

March 12, 2025

http://bugs.winehq.org/show_bug.cgi?id=25532 Summary: iTunes under Wine doesn't find shared libraries Product: Wine Version: 1.3.9 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: computers57(a)hotmail.com It seems that iTunes 10.1 under Wine cannot find shared libraries. I think this has something to do with mdnsresponder not able to talk on the required port. Steps to reproduce: 1. Go to preferences in iTunes running either on Mac or natively on Windows. 2. click on Sharing. 3. Enable Music Sharing. 4. Go to a wine directory which has iTunes installed. 5. Start up iTunes under Wine. 6. Wait about a minute. 7. Look under Sharing on the sidebar. Expected result: You should see the shared library. Actual result: The share doesn't show up at all. -- 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.

2 14

[Bug 29579] New: winhelp: winhlp32.exe doesn't support making its window non-resizeable or without menu strip
by wine-bugs＠winehq.org March 8, 2025

March 8, 2025

http://bugs.winehq.org/show_bug.cgi?id=29579 Bug #: 29579 Summary: winhelp: winhlp32.exe doesn't support making its window non-resizeable or without menu strip Product: Wine Version: 1.3.36 Platform: x86-64 URL: http://download.microsoft.com/download/aoe/Trial/1.0/W IN98/EN-US/MSAoE.exe OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: markk(a)clara.co.uk Classification: Unclassified In Windows, help files can cause the winhlp32 window to open with fixed (non-resizeable) dimensions, and/or with no menu strip. Wine winhlp32 does not support that feature. For example, download the Age of Empires trial version from http://www.microsoft.com/games/empires/downloads.htm direct download URL is http://download.microsoft.com/download/aoe/Trial/1.0/WIN98/EN-US/MSAoE.exe Either run MSAoE.exe to install the demo, or use cabextract to unpack the files inside. Run winhlp32.exe from Windows under Wine and load Empires.hlp. Notice the window has no menu strip and cannot be resized. (I tested winhlp32.exe from Windows 98 and XP.) Run Wine winhlp32.exe and load Empires.hlp. (The window contents are completely messed up and unusable, but that's not what this bug covers.) Notice the winhlp32 window is resizeable and has a menu strip. -- 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.

2 5

[Bug 25682] New: Super Crate Box runs slowly
by wine-bugs＠winehq.org March 5, 2025

March 5, 2025

http://bugs.winehq.org/show_bug.cgi?id=25682 Summary: Super Crate Box runs slowly Product: Wine Version: 1.3.10 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: madewokherd(a)gmail.com On Wine, Super Crate Box runs slowly enough to actually be playable. While this is arguably an improvement, we should match the Windows behavior which is to run unplayably fast. -- 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.

2 13

[Bug 25381] New: Trackmania Nation Forever crashes on OS X when sound is enabled
by wine-bugs＠winehq.org Feb. 26, 2025

Feb. 26, 2025

http://bugs.winehq.org/show_bug.cgi?id=25381 Summary: Trackmania Nation Forever crashes on OS X when sound is enabled Product: Wine Version: 1.3.8 Platform: x86 URL: http://www.trackmaniaunited.com OS/Version: Mac OS X 10.6 Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: qparis(a)playonlinux.com Created an attachment (id=32283) --> (http://bugs.winehq.org/attachment.cgi?id=32283) Screenshot + Terminal content Application : Track Mania Nation forever (http://www.trackmaniaunited.com) System information : - Tested both with XQuartz 2.6.0 beta (for Randr support) and stable version - Mac OS 10.6.5 Step to reproduce : - I downloaded the latest version of Trackmania Nation Forever (free) (http://www.trackmaniaunited.com) - The game installation run fine - I started a single player game, it will crash at the end of the loading process - I runned wineserver -k in a terminal to kill wine - I went to settings menu -> Advanced -> Audio - I unchecked the box "Enable sound" - I retried to start a single player race, and it worked perfectly (I retried several time and the problem seems to be linked to the sound) Other details - The menu works fine with - The problem does not exist on Linux -- 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.

2 13

[Bug 18959] New: MetaTrader 4 installer hangs at the very end of file extraction
by wine-bugs＠winehq.org Feb. 25, 2025

Feb. 25, 2025

http://bugs.winehq.org/show_bug.cgi?id=18959 Summary: MetaTrader 4 installer hangs at the very end of file extraction Product: Wine Version: 1.1.23 Platform: PC URL: http://www.metatrader4.com/files/mt4setup.exe OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt AssignedTo: wine-bugs(a)winehq.org ReportedBy: arethusa26(a)gmail.com CC: julliard(a)winehq.org With today's Git (wine-1.1.23-221-gafce86b), the MetaTrader installer hangs at the very end of file extraction at "C:\Program Files\MetaTrader 4\mailbox\1190736044.english" with sufficient responsiveness to handle the Cancel button being pressed, which merely hides the installer window until a Ctrl+C interrupt is sent to the installer. The installer worked properly in 1.0.1, and the regression test revealed: 1c91d54503f9b2afa513dc4dd79bf19bc9bad51a is first bad commit commit 1c91d54503f9b2afa513dc4dd79bf19bc9bad51a Author: Alexandre Julliard <julliard(a)winehq.org> Date: Wed Feb 18 14:44:17 2009 +0100 msvcrt: Don't try to duplicate invalid handles. Don't reset std handles if we didn't set them. :040000 040000 2abf5f9a82de1d29b1fccadc658fc3a956388ac4 86464380dfe4aca4c5c11ea2a539a1fc5def03b8 M dlls Reverting the commit in HEAD allows the installer to start. -- 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.

2 32

[Bug 24308] New: Fullscreen fails for MechWarrior 4 games (Only one D3D device per DirectDraw object)
by wine-bugs＠winehq.org Feb. 21, 2025

Feb. 21, 2025

http://bugs.winehq.org/show_bug.cgi?id=24308 Summary: Fullscreen fails for MechWarrior 4 games (Only one D3D device per DirectDraw object) Product: Wine Version: 1.3.2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-ddraw AssignedTo: wine-bugs(a)winehq.org ReportedBy: georg298(a)gmx.de For all MechWarrior 4 games, fullscreen fails with message fixme:ddraw:d3d7_CreateDevice Only one Direct3D device per DirectDraw object supported. Obviously, the game falls back to window'ed mode, as static HRESULT WINAPI d3d7_CreateDevice(IDirect3D7 *iface, REFCLSID riid, IDirectDrawSurface7 *surface, IDirect3DDevice7 **device) returns DDERR_INVALIDPARAMS changing this behaviour (returning D3D_OK instead): if (ddraw->d3ddevice) { FIXME("Only one Direct3D device per DirectDraw object supported.\n"); LeaveCriticalSection(&ddraw_cs); return D3D_OK; // return DDERR_INVALIDPARAMS; } makes fullscreen work for these games. Probably it's not "legal" to return D3D_OK in this case, but maybe there is a real solution for this problem? -- 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.

2 26

[Bug 10522] New: endless WM_PAINT loop bug (update regions, queue paint count)
by wine-bugs＠winehq.org Feb. 17, 2025

Feb. 17, 2025

http://bugs.winehq.org/show_bug.cgi?id=10522 Summary: endless WM_PAINT loop bug (update regions, queue paint count) Product: Wine Version: CVS/GIT Platform: PC URL: http://www.microsoft.com/whdc/devtools/debugging/install x86.mspx OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-user AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=9265) --> (http://bugs.winehq.org/attachment.cgi?id=9265) trace with WINEDEBUG=+tid,+message,+win,+server Hello, I've seen this bug a while ago in other apps but ignored it because it was not easily to reproduce. Well until recently when I tested some stuff with windbg from "Debugging Tools for Windows" (Microsoft). I used debugging tools version 6.8.4.0 and recent GIT (wine-0.9.49-302-g58b85bb). Immediately when a child window was opened using toolbar (register, locals, .. whatever), windbg would become unresponsive, eating most CPU. Happens in both GUI modes - "floating/docking toolwindow" and "MDI emulation. Though "MDI emulation" is more obvious, it actually shows the endless refreshing (window caption). Attached is WINEDEBUG=+tid,+message,+win,+server log. Additionally I added a trace message which prints the current queue paint count (when incremented or fetched) which makes some things easier to spot. Printed as "inc_queue_paint_count: %d" and "get_message_paint_count: %d". The window hierarchy is as follows: --- snip --- *root*=0x10020 Shell_TrayWnd=0x10022 WinDbgFrameClass=0x10024 DockClass=0x10026 ToolbarWindow32=0x10028 msctls_statusbar32=0x1002a tooltips_class32=0x1002e WinBaseClass=0x10030 ToolbarWindow32=0x10032 SysListView32=0x10034 SysHeader32=0x10036 RichEdit20W=0x10038 --- snip --- After the child windows are created the queue paint count never drops to zero, resulting in endless WM_PAINT processing. Maybe some update (region) code path missed or flags problem? I played a bit with ignoring null region updates and it seemed to help a bit (preventing endless WM_PAINT loop) though other stuff wasn't drawn properly then. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 41