August 2010 - wine-bugs

[Bug 23480] New: AD-muncher does not install
by wine-bugs＠winehq.org 21 Oct '11

21 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=23480 Summary: AD-muncher does not install Product: Wine Version: 1.1.38 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: andygibbs1(a)compuserve.com I wanted to try this program that I've used for years on win 2kpro it is an advert eater that works better than anything I tried on linux, you just do not get ads coming up: quite a shock when I have to use a system with out it! Down loaded the program (http://www.admuncher.com/download.shtml) clicked on the file selected to run in wine (1.1.38 with fedora 13). The program's installer runs but gets nowhere. It would be good to have this running. Thanks -- 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.

1 6

[Bug 10910] New: winealsa and PulseAudio
by wine-bugs＠winehq.org 21 Oct '11

21 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=10910 Summary: winealsa and PulseAudio Product: Wine Version: 0.9.51. Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-binary AssignedTo: wine-bugs(a)winehq.org ReportedBy: atari(a)gabo.pl winealsa is unable to work with PulseAudio. This is my /etc/asound.conf: pcm.pulse { type pulse } ctl.pulse { type pulse } pcm.!default { type pulse } ctl.!default { type pulse } This is registry entries for Alsa configurations: REGEDIT4 [HKEY_CURRENT_USER\Software\Wine\Alsa Driver] "AutoScanCards"="N" "AutoScanDevices"="N" "DeviceCount"="1" "DeviceCTL1"="pulse" "DevicePCM1"="pulse" "UseDirectHW"="N" And I get this error in wine log: err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element I tracked it in wine source code to file dlls/winealsa.drv/alsa.c With following comment: /* Setup and find an element id that exactly matches the characteristic we want ** FIXME: It is probably short sighted to hard code and fixate on PCM Playback Volume */ Unfortunetly I know to little about Alsa to fix it. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 60

[Bug 19558] New: Bad mask in David Fotland's Many Faces of Go version 12
by wine-bugs＠winehq.org 21 Oct '11

21 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=19558 Summary: Bad mask in David Fotland's Many Faces of Go version 12 Product: Wine Version: unspecified Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: grikdog(a)pobox.com Sorry for newbie post, but this has to come to somebody's attention. Fotland's Many Faces of Go is a go player/analysis/IGS client tool for Windows XP or Vista. When you place Go stones on the board in Wine emulation, the mask is wrong. Stones have a black square behind them. This was FIXED (almost) in Wine 1.0.1, but in Wine 1.1.26 the issue has reappeared. Also the round stone shape part of the mask was fixed, but the color of the stone shadows on the board was white and not gray -- this has not been fixed in ANY version of Wine. There may be a prior bug referring to Igowin on this same issue, but I doubt that is a duplicate. You could ask fotland(a)smart-games.com (the author) if the bug is a duplicate. -- 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.

1 6

[Bug 19037] New: CTRL key automatically released?
by wine-bugs＠winehq.org 21 Oct '11

21 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=19037 Summary: CTRL key automatically released? Product: Wine Version: 1.1.24 Platform: PC OS/Version: Linux Status: NEW Keywords: download, source Severity: minor Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Fire up notepad, type some gibberish, then use "CTRL+A, CTRL+C, CTRL+F". This brings up the find menu. Now, while still holding CTRL, press CTRL+V. Instead of pasting, you'll just get 'v'. Let go of CTRL and press CTRL+V. You'll get your gibberish pasted. Very annoying, now that I'm using Notepad++ as my regular (dogfood) text editor. -- 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.

1 7

[Bug 11728] New: Picasa / Facebook Uploader does not work
by wine-bugs＠winehq.org 19 Oct '11

19 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=11728 Summary: Picasa / Facebook Uploader does not work Product: Wine Version: 0.9.56. Platform: PC URL: http://apps.facebook.com/picasauploader/ OS/Version: Linux Status: NEW Keywords: download Severity: minor Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: thestig(a)google.com Prerequisite: a facebook account Steps to reproduce: 1. Install Picasa from http://picasa.google.com/ 2. Install wine gecko 3. Install the facebook uploader from http://apps.facebook.com/picasauploader/ as follows: wine 'c:\Program Files\Picasa2\Picasa2.exe' picasa://importbutton/?url=http://www.webkinesis.com/fbpicasa/facebook.pbf 4. Start Picasa, select some pictures and try to upload using the facebook button Expected Results: Picasa creates an album, uploads the pictures to facebook. (tested on WinXP) Actual Results: Picasa creates an album, but nothing gets uploaded. -- 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.

1 8

[Bug 23771] New: Fallout 2 fails to start in 16 bit depth
by wine-bugs＠winehq.org 19 Oct '11

19 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=23771 Summary: Fallout 2 fails to start in 16 bit depth Product: Wine Version: 1.1.44 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: b.brachaczek(a)gmail.com CC: julliard(a)winehq.org Fallout 2 (and maybe other games too, haven't tried) fails to start when X Server is run in 16 bpp mode (24 bpp works fine). Only the following message is displayed: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 386 Current serial number in output stream: 390 The first bad commit is between 1.1.43 and 1.1.44: commit df6cd82ccf5dd03b0362a7ea571e14d66bbc5d72 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Thu May 6 14:57:44 2010 +0200 winex11: Create a window of the appropriate visual to initialize GL info. Stable 1.2 as well as current git have the same issue. Current git with reverted the above commit works fine. System: kernel 2.6.34.1 x86 X.Org Server 1.8.2 xf86-video-openchrome svn rev. 856 (latest) Mesa 7.8.2 (using classic mesa software driver, no hardware 3D support for my VIA Chrome9 chipset) GCC 4.5.0 -- 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.

1 9

[Bug 20985] New: Crash in CryptMsgUpdate under valgrind
by wine-bugs＠winehq.org 19 Oct '11

19 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=20985 Summary: Crash in CryptMsgUpdate under valgrind Product: Wine Version: 1.1.34 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: crypt32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com http://kegel.com/wine/valgrind/logs/2009-12-10-03.53/vg-crypt32_msg.txt shows a crash. Adding +relay,+seh,+crypt shows a bit more: 001e:Call crypt32.CryptMsgUpdate(7f044948,07783e13,00000004,00000000) ret=0774e9b4 trace:crypt:CryptMsgUpdate (0x7f044948, 0x7783e13, 4, 0) 001e:Call KERNEL32.LocalAlloc(00000000,00000011) ret=07be6df0 001e:Ret KERNEL32.LocalAlloc() retval=7f044988 ret=07be6df0 err:seh:segv_handler Got unexpected trap 0 ... 001e:Call KERNEL32.UnhandledExceptionFilter(7f21f5cc) ret=074b5deb ... Unhandled exception: illegal instruction in 32-bit code (0x00000000). Backtrace: =>0 0x00000000 (0x7f21fc48) 1 0x0d3fced4 CryptMsgUpdate+0xa0(hCryptMsg=0x7f0bd740, pbData="", cbData=4, fFinal=0) [dlls/crypt32/msg.c:2786] in crypt32 (0x7f21fc88) 2 0x0cf429b4 test_data_msg_update+0x5b1() [dlls/crypt32/tests/msg.c:445] in crypt32_test (0x7f21fd08) (two logs are smashed together there, so pointers don't match exactly) When run not under valgrind, the same crash happens, but is handled: 001c:Call crypt32.CryptMsgUpdate(00154948,7ec0ce13,00000004,00000000) ret=7ebd79b4 trace:crypt:CryptMsgUpdate (0x154948, 0x7ec0ce13, 4, 0) 001c:Call KERNEL32.LocalAlloc(00000000,00000011) ret=7eb29df0 001c:Ret KERNEL32.LocalAlloc() retval=00154988 ret=7eb29df0 trace:seh:raise_exception code=c0000005 flags=0 addr=(nil) ip=00000000 tid=001c trace:seh:raise_exception info[0]=00000000 trace:seh:raise_exception info[1]=00000000 trace:seh:raise_exception eax=00000000 ebx=7eb68ff4 ecx=00154988 edx=00000011 esi=00000000 edi=0032fc20 trace:seh:raise_exception ebp=0032fbc8 esp=0032facc cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010202 trace:seh:call_vectored_handlers calling handler at 0x7ed88f41 code=c0000005 flags=0 trace:seh:call_vectored_handlers handler at 0x7ed88f41 returned 0 trace:seh:call_stack_handlers calling handler at 0x7eb39d84 code=c0000005 flags=0 001c:Call ntdll.RtlUnwind(0032faf0,7eb39e1a,0032fa74,00000000) ret=7eb39e9f 001c: eax=7eb00b15 ebx=7eb68ff4 ecx=0032fa74 edx=0032faf0 esi=0032faf0 edi=7eb39e1a ebp=0032f588 esp=0032f558 ds=002b es=002b fs=0063 gs=006b flags=00000212 trace:seh:__regs_RtlUnwind code=c0000005 flags=2 trace:seh:__regs_RtlUnwind calling handler at 0x7efb47d4 code=c0000005 flags=2 trace:seh:__regs_RtlUnwind handler at 0x7efb47d4 returned 1 001c:Ret ntdll.RtlUnwind() retval=00000000 ret=7eb39e9f 001c: eax=00000000 ebx=7eb68ff4 ecx=0032fa74 edx=0032faf0 esi=0032faf0 edi=7eb39e1a ebp=0032f588 esp=0032f558 ds=002b es=002b fs=0063 gs=006b flags=00000212 001c:Call KERNEL32.SetLastError(c0000005) ret=7eb39ca6 001c:Ret KERNEL32.SetLastError() retval=c0000005 ret=7eb39ca6 001c:Ret crypt32.CryptMsgUpdate() retval=00000000 ret=7ebd79b4 This is kind of mysterious. I can't find the __TRY that applies to that fault... this could well be a valgrind bug, but I need to understand how it works normally under wine. -- 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.

1 4

[Bug 17718] New: Fatal error 'Cannot allocate red zone for initial thread' on FreeBSD
by wine-bugs＠winehq.org 17 Oct '11

17 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=17718 Summary: Fatal error 'Cannot allocate red zone for initial thread' on FreeBSD Product: Wine Version: 1.1.17 Platform: PC OS/Version: FreeBSD Status: NEW Severity: critical Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: gerald(a)pfeifer.com CC: tijl(a)ulyssis.org, austinenglish(a)gmail.com Wine 1.1.17 causes the following on FreeBSD 7.2 when starting almost any application (this is for an old version of calc.exe): Fatal error 'Cannot allocate red zone for initial thread' at line 384 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 2) err:module:attach_process_dlls "ntdll.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\wineboot.exe" failed, status 80000101 err:process:__wine_kernel_init boot event wait timed out Fatal error 'Cannot allocate red zone for initial thread' at line 384 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 2) err:module:attach_process_dlls "ntdll.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"Z:\\home\\pfeifer\\_\\wcalc.exe" failed, status 80000101 Segmentation fault (core dumped) -- 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.

1 10

[Bug 23641] New: Need for speed Most wanted controls error
by wine-bugs＠winehq.org 17 Oct '11

17 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=23641 Summary: Need for speed Most wanted controls error Product: Wine Version: 1.2-rc7 Platform: x86 OS/Version: other Status: UNCONFIRMED Severity: critical Priority: P1 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: s_paul1408(a)yahoo.com My OS is ubuntu 10.04. With wine rc2 nfs most wanted+patch 1.3+crack wouldn't start, but when i tested rc7 it worked almost perfect except a control bug: it's as if the "left arrow" is pressed. It keeps turning left, even after i changed the controls. The same problem is with gta vice city and gta san andreas, except it's the "down arrow". -- 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.

1 25

[Bug 12267] New: winstone 32 hangs
by wine-bugs＠winehq.org 17 Oct '11

17 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=12267 Summary: winstone 32 hangs Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Here's what happens when you launch c:\zdbench\ws32\ui.exe: it puts up its window, says "examining the execution environment" (although you can't see it, since the window is too big, and falls off the bottom), and hangs. err:ntdll:RtlpWaitForCriticalSection section 0x7b922ee0 "syslevel.c: Win16Mutex" wait timed out in thread 0016, blocked by 0012, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7bc8d6e4 "loader.c: loader_section" wait timed out in thread 0012, blocked by 0016, retrying (60 sec) It hangs just like this on XP, too. But what the heck, if we could get it to not hang on wine, that'd be nice. -- 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.

1 6

[Bug 11109] New: dream of mirror online crash
by wine-bugs＠winehq.org 17 Oct '11

17 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=11109 Summary: dream of mirror online crash Product: Wine Version: 0.9.52. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: petifrancais(a)gmail.com Created an attachment (id=10143) --> (http://bugs.winehq.org/attachment.cgi?id=10143) txt contenant les erreurs en console The game game domo crash after the logo "GameTribe" -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 11

[Bug 16674] New: Battle for middle earth2: No network multiplayer possible
by wine-bugs＠winehq.org 17 Oct '11

17 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=16674 Summary: Battle for middle earth2: No network multiplayer possible Product: Wine Version: 1.1.11 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P4 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: mcflow-forum(a)gmx.net Multiplayer games with Battle for Middle Earth2 in wine are not possible. According to the information on the game package it uses TCP/IP for network multiplayer. I already tried using the native dplay dlls like it is stated in the wiki, LAN still does not work. It happens like this: I enter the network mode and the game displays myself two times in the players list. The other player sees me in the list only one time, as it should be. I can read what he writes and vice versa. If I write something I can see it two times in the chat. For the other user it appears only one time. Now, if I open a game, the other player can see it in the game list. If he wants to join he gets a "Connection Timout" error. Same happens if the other player opens a game and I want to join it. I searched the Bugzilla for quite a time now because I do not want to open a duplicate bug. I found a few things that first sounded interesting but when I tested them nothing changed. I found a note at the AppDB page of Garena 3.0 (http://appdb.winehq.org/objectManager.php?sClass=version&iId=14147&iTesting…) Patching with the patch that is linked there did not solve the problem with wine-1.1.11(well one of the hunks failed but it compiled) In Bug 9787 there also was a patch for the AcceptEX for wine-1.1.6. It did not work with wine-1.1.6. It said that wine does not include AcceptEX. I'm not sure if "The battle for middle earth" requires it. I did not find anything about it on the net except that it uses tcp/ip. -- 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.

1 27

[Bug 19083] New: Respondus LockDown Browser: outside processes should not be able to detect its window (appinstall)
by wine-bugs＠winehq.org 17 Oct '11

17 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=19083 Summary: Respondus LockDown Browser: outside processes should not be able to detect its window (appinstall) Product: Wine Version: 1.1.21 Platform: PC URL: https://hdc.tamu.edu/files/book/6/425/LockDownSetup_1. 0.3.exe 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 Not sure how to describe this exactly...but the Respondus Lockdown Browser is meant to be used by universities to make sure that students don't use other programs when taking quizzes/exams/etc. As a result, it does some really funky stuff...While writing an appinstall test for it, found a few interesting things. First up, on windows, the IfWinExist (http://www.autohotkey.com/docs/commands/IfWinExist.htm) function fails for this window (never seen that happen for any other app). On wine, however, we detect it just fine. -- 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.

1 4

[Bug 15250] New: MINITAB 14 graph editor crashes when File menu is clicked
by wine-bugs＠winehq.org 17 Oct '11

17 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=15250 Summary: MINITAB 14 graph editor crashes when File menu is clicked Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: nodisgod(a)yahoo.com Created an attachment (id=16034) --> (http://bugs.winehq.org/attachment.cgi?id=16034) rzipped relay log With current Git (wine-1.1.4-292-g4b4109a), when clicking on the File menu in the graph editor, mtb14ge.exe, the application crashes. The point at which the application crashes seems to be here: 0009:Call user32.CallWindowProcW(7edae5b0,00010030,00000229,00000000,00000000) ret=5f8487d1 0009:Call window proc 0x7edae5b0 (hwnd=0x10030,msg=WM_MDIGETACTIVE,wp=00000000,lp=00000000) 0009:Ret window proc 0x7edae5b0 (hwnd=0x10030,msg=WM_MDIGETACTIVE,wp=00000000,lp=00000000) retval=00000000 0009:Ret user32.CallWindowProcW() retval=00000000 ret=5f8487d1 0009:Ret window proc 0x5f870878 (hwnd=0x10030,msg=WM_MDIGETACTIVE,wp=00000000,lp=00000000) retval=00000000 0009:Ret user32.SendMessageW() retval=00000000 ret=5f862aa3 0009:Call KERNEL32.TlsGetValue(00000003) ret=5f870ec6 0009:Ret KERNEL32.TlsGetValue() retval=00139408 ret=5f870ec6 0009:Call KERNEL32.TlsGetValue(00000003) ret=5f870ec6 0009:Ret KERNEL32.TlsGetValue() retval=00139408 ret=5f870ec6 0009:Call KERNEL32.TlsGetValue(00000003) ret=5f870ec6 0009:Ret KERNEL32.TlsGetValue() retval=00139408 ret=5f870ec6 trace:seh:raise_exception code=c0000005 flags=0 addr=0x32eeda Compressed relay log is attached. -- 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.

1 11

[Bug 24156] New: Empire Earth: crashes when starting the game
by wine-bugs＠winehq.org 17 Oct '11

17 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=24156 Summary: Empire Earth: crashes when starting the game Product: Wine Version: 1.3.1 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: simondani91(a)gmail.com Created an attachment (id=30402) --> (http://bugs.winehq.org/attachment.cgi?id=30402) This is the debug output. After checking if game CD is in the drive, an error message appears 'Unhandled page fault' The problem is probably with Low-Level Engine.dll which is in the directory of the game. -- 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.

1 6

[Bug 22217] New: Klick & Play complains about lack of memory
by wine-bugs＠winehq.org 17 Oct '11

17 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=22217 Summary: Klick & Play complains about lack of memory Product: Wine Version: 1.1.41 Platform: x86 OS/Version: Mac OS X 10.6 Status: UNCONFIRMED Severity: normal Priority: P2 Component: dos AssignedTo: wine-bugs(a)winehq.org ReportedBy: computers57(a)hotmail.com CC: computers57(a)hotmail.com Created an attachment (id=27110) --> (http://bugs.winehq.org/attachment.cgi?id=27110) Klick & Play crash log When I start up Klick & Play, it complains that there isn't enough memory. This is most likely related to the following log message that I get at about the same time: err:dc:CreateDCW no driver found for L"DIB" Since the program gives me the option to retry, I get the same error almost each time. I am using a virtual desktop if that helps any. When I click on "Create a game" it just up and crashes (crash log attached). -- 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.

1 7

[Bug 11077] New: does not find a serial port while running this application under wine
by wine-bugs＠winehq.org 17 Oct '11

17 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=11077 Summary: does not find a serial port while running this application under wine Product: Wine Version: unspecified Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: only4john(a)gmail.com Environment: wine under Ubuntu 7.10 Hardware Device: IRISYS 1001 thermal imager (http://www.entherm.com/Irisys/IRISYS%20Thermal%20Imager.htm) Driving Application: http://only4john.googlepages.com/Imager3309.exe The Driving Application can not find serial port while running the application under wine, while the PC has a serial port. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 13

[Bug 14847] New: UFO Extraterrestials: Problems with mouse cursor and textures.
by wine-bugs＠winehq.org 15 Oct '11

15 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=14847 Summary: UFO Extraterrestials: Problems with mouse cursor and textures. Product: Wine Version: 1.0.0 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: RodionKarimov(a)yandex.ru Problem with mouse: cursor is shown not exactly there where it is, for exmple, when cursor is graphically shown a long away from button - the button is selected, when it is on button - button is not selected. There is some problem in inner game mouse driver, because, when i am changing mouse sensitivity in file "ufo-et.ini", that is located in "data" directory from 255 to 100, image of mouse cursor starts to be much closer to there, where it actually is. But not exactly. And some times image of cursor again starts to go far from exact cursor location, for example: sometimes when rotating the globe or in tactical mode, when shooting. Problem with textures: when in "ufo-et.ini" "scissortesting=true", that default is, there is not seen in global mode: images of soldiers; research tasks; rifles, pistols, grenades and ammunition of soldiers; and name of the save game that is being enter when saving game. When "scissortesting=false" all of that is shown, but name of the saving game is very little, project names is also very little, images of soldioers and weapons is also very little. And everything of this is not on its place, for example images of weapons is right and down from its location; images of soldiers are placed down from its locations; names of projects are right and down from its location, but they are selecting and activating by mouse at that position where they must be. -- 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.

1 27

[Bug 17536] New: Atari Scrabble Online fails to install (regression)
by wine-bugs＠winehq.org 15 Oct '11

15 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=17536 Summary: Atari Scrabble Online fails to install (regression) Product: Wine Version: 1.1.11 Platform: PC URL: http://appdb.winehq.org/objectManager.php?sClass=version &iId=12955 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk Created an attachment (id=19670) --> (http://bugs.winehq.org/attachment.cgi?id=19670) Wine 1.1.15 +msi Atari Scrabble Online fails to install. The culprit seems to be: err:msi:ITERATE_Actions Execution halted, action L"DX9_Launcher.A545835B_7768_4D96_A5BC_930949616C2D" returned 1603 At this point the installer attempts to start the DirectX9 installer, whether it is already installed or not. There therefore is no workaround. Tested in Wine 1.1.11 and 1.1.15 and bug exists. Tested in Wine 1.0 and bug does not exist. Result of bisect: 731306bf78f2b8a6a92448e1977268b4396eb449 is first bad commit commit 731306bf78f2b8a6a92448e1977268b4396eb449 Author: James Hawkins <jhawkins(a)codeweavers.com> Date: Tue Sep 2 01:01:59 2008 -0500 kernel32: Fix two tests that fail in win2k3 and modify LoadLibraryEx to match this behavior. :040000 040000 64ed6c6c7ae8c6e131079052e9113f07a467d58b 64a781d6056ae364ba95c128901381cc6343c06a M dlls which doesn't make much sense to me. -- 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.

1 22

[Bug 11419] New: Installation of Intel Indeo Video freezes
by wine-bugs＠winehq.org 15 Oct '11

15 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=11419 Summary: Installation of Intel Indeo Video freezes Product: Wine Version: 0.9.54. Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: elicoten(a)live.co.uk Installation gets upto "searching for components: Netscape", and about 9% on the progress bar then freezes. Cannot be installed. -- 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.

1 9

[Bug 20281] New: Adobe Photoshop CS4 installer unusable
by wine-bugs＠winehq.org 14 Oct '11

14 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=20281 Summary: Adobe Photoshop CS4 installer unusable Product: Wine Version: 1.1.30 Platform: PC URL: http://trials.adobe.com/Applications/Photoshop/CS4/Win /ADBEPHSPCS4_LS1.7z OS/Version: Linux Status: NEW Keywords: download, Installer, regression Severity: normal Priority: P2 Component: mshtml AssignedTo: wine-bugs(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk CC: jacek(a)codeweavers.com Created an attachment (id=23956) --> (http://bugs.winehq.org/attachment.cgi?id=23956) Screenshot The Adobe Photoshop CS4 installer is currently unusable, see screenshots for details. Probably affects other CS4 installers too, but I have not tested them. df90f665bb11e2d01ff3e061d6f989ce2589cadb is first bad commit commit df90f665bb11e2d01ff3e061d6f989ce2589cadb Author: Jacek Caban <jacek(a)codeweavers.com> Date: Fri Oct 2 13:51:19 2009 +0200 mshtml: Added HTMLAnchorElement dispex data. :040000 040000 1e962f09f4793df3ac56a123fd68e7d8dc07d33e 07fbe0ed134096e9e663b4722f97f57140bc431a M dlls To get this far, have to work around Bug 18070. It appears that all the possible fields are shown at once, and none of them are accessible. -- 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.

1 9

[Bug 23334] New: SimCity 3000: after install regedit shows
by wine-bugs＠winehq.org 13 Oct '11

13 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=23334 Summary: SimCity 3000: after install regedit shows Product: Wine Version: 1.2-rc4 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: felipemoraesbr(a)gmail.com This is the single game I tested where it happens -- 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.

1 6

[Bug 11239] New: Steam Games No Longer Start - bisected the cause to ntdll
by wine-bugs＠winehq.org 13 Oct '11

13 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=11239 Summary: Steam Games No Longer Start - bisected the cause to ntdll Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: philcostin(a)hotmail.com The following patch, introduced on Jan 15th 2008 has resulted in Steam games being unable to start. bd352bcd1c98ed91bdb337e73cddfd8ceac095d6 err:seh:setup_exception nested exception on signal stack in thread 004f eip 7efc20b3 esp 7ffdb770 stack 0x241000-0x350000 -- 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.

1 20

[Bug 14390] New: Gmax 1.2: Fatal Error on Install - Ended Prematurely.
by wine-bugs＠winehq.org 13 Oct '11

13 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=14390 Summary: Gmax 1.2: Fatal Error on Install - Ended Prematurely. Product: Wine Version: 1.1.0 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P1 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: gaming4jc2(a)yahoo.com Created an attachment (id=14701) --> (http://bugs.winehq.org/attachment.cgi?id=14701) Fatal Error on install. When installing GMAX 1.2 on WINE 1.1.0 I receive the following errors which are attached. -- 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.

1 15

[Bug 23675] New: Portable Apps Platform (beta 5) works under Vista, Win7,=?UTF-8?Q?=20but=20not=20Wine=E2=80=99s=20emulation?=
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=23675 Summary: Portable Apps Platform (beta 5) works under Vista, Win7, but not Wine’s emulation Product: Wine Version: 1.2-rc7 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: joelcsalomon(a)gmail.com Portable Apps Platform (beta 5, see <http://portableapps.com/node/24258>) gives me the error “The program PortableAppsPlatform.exe has encountered a serious problem and needs to close. We are sorry for the inconvenience.” Telling Wine to mimic Windows XP for this program avoids the crash, but the Platform runs fine under (real) Windows Vista & 7. -- 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.

1 7

[Bug 18777] New: Wine 1.1.22+ resets customized FontLink when switching locales
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=18777 Summary: Wine 1.1.22+ resets customized FontLink when switching locales Product: Wine Version: 1.1.22 Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: gdi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: matthewsage(a)live.com CC: Paul.Hampson(a)Pobox.com Created an attachment (id=21546) --> (http://bugs.winehq.org/attachment.cgi?id=21546) Regression test that shows the patch that broke the desired functionality Whenever you switch locales (using the latest Wine dev. version -1.1.22-), whatever custom Font Linking you have made in the FontLink/SystemLink register key will be wiped out. This was tested on Wine 1.1.22, after wiping out ~/.wine I tested it with the Ubuntu x86_64 binary package from the budgetdedicated servers, AND after building from source. Steps to reproduce: 1) Run "regedit" 2) Set some System Font Linking replacements in the HKLM/Software/Microsoft/Windows NT/CurrentVersion/FontLink/SystemLink register key (in my case: Tahoma -> VL Gothic, Microsoft Sans Serif -> VLGothic, MS Sans Serif -> VL Gothic) 3) Run any Win32 application with LANG set to a different locale (in my case, LANG=ja_JP.UTF-8) Expected results: The application is executed, whatever Font Linking you made is visible (which means that the custom Font Linking I made is respected by Wine). Actual Results: The application is executed, whatever Font Linking you made is not visible. If you run "regedit" again, you'll see that the FontLink/SystemLink key is now empty. Workaround: Always run Wine apps with the same locale (LANG=ja_JP.UTF-8 in my case) - That would include regedit itself, so that the Font Linking you set up is not wiped as soon as you run another app with a different locale. -- 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.

1 11

[Bug 10273] New: satisfy SafeDisc 2.x heuristic API analyzer by "adjusting" API exports/entry statistics of wine builtins
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=10273 Summary: satisfy SafeDisc 2.x heuristic API analyzer by "adjusting" API exports/entry statistics of wine builtins Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-kernel AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=8924) --> (http://bugs.winehq.org/attachment.cgi?id=8924) Patch which should fix SafeDisc 2.x copy protection api analyzer issue Hello, if not interested in technical details goto (2) ;-) I made this a separate bug report like http://bugs.winehq.org/show_bug.cgi?id=9925 (SafeDisc 1.x stopper) because SafeDisc has many flavors that differ in various technical ways and can't be discussed/handled in a single SafeDisc "metabug" like http://bugs.winehq.org/show_bug.cgi?id=219 SafeDisc Major version based separation allows better tracking of "completion" state (1.x/2.x/3.x/4.x). ----------- (1) It took me a couple of days to get an idea what SafeDisc 2.x really does with the API exports and to find a way to cope with it... Various anti-debugging techniques and nasty runtime code obfuscation made this journey somewhat challenging. Parts of SafeDisc 2.x analyze the API code of the following system libraries: kernel32.dll (wine builtin) user32.dll (wine builtin) gdi32.dll (wine builtin) cdasdtst.dll (developer backdoor?) The latter one is probably a "developer backdoor", used to verify their code/algorithms (not needed to be present). For each of these libraries all named exports are taken into account. A number of API entry opcode sequences are read and used for statistical analysis (number depends on type of encountered opcodes). >From what I've seen there is some kind of "behavioural probability" of each API entry calculated, with typical opcode sequences having a "weighting". Just think of advanced heuristic detection methods of antivirus scanners and you get the idea ;-). Anyway, wine's builtin libraries differ in their signatures from windows entry code and to make things worse, wine's +relay/+snoop feature heavily interferes with the analyzer results. :-( First I made some experiments with additional (dummy) function exports, small __asm__ wrappers with opcode sequences to see how the distribution of opcodes influences the analyzer results. The result was rather disappointing. I needed a large number of exports to gain some results but not significantly enough to get below the "bad" threshold. Then I came across the magic "0" value. As soon as I used this value either as first .byte on API entry or init value for data export, the entry scan was short circuited. This value seemed to have the highest influence of all code/data sequences used. I added quite a number of data exports - aliased to initialized "0" value - safe enough to let even wine's +relay work (remember: relay code influences analyzer). If you look at the patch don't get mad ;-) You will see a crapload of named "__wine_safedisc2" data exports/aliases added to wine builtin kernel32, user32 and gdi32. For the record: http://bugs.winehq.org/show_bug.cgi?id=9926 which talks about "problematic" gdi32 data exports (pfnPalette stuff) in SafeDisc 3.x. SafeDisc 2.x code triggers SEH upon exported function pointers too but this is gracefully handled. No harm at all. I wonder if this is really a problem in SafeDisc 3.x ... I thought about other possible solutions but found no one easier to implement to prove my findings without hurting wine too much :-) Making wrappers of the whole kernel32, user32, gdi32 named exports API just to please the entry analyzer is not an option to me. Another way could be the relocation of export table upon module loading, expanding it at runtime by adding the required number of "statistics fakers" (data exports with zero init). This requires modifying the ntdll loader .. though i'm not sure if this approach breaks other applications/braindamaged PE protection stuff which expect certain conditions to be met (tables present at specific sections/memory areas). ------------------------------ (2) Well, take it as proof of concept. Play with it. I tested my patch with a few SafeDisc 2.x games I have original media. No cracks/no-cd patches were used. Only official game patches were used. Battlefield 1924 (1.6x) - SafeDisc 2.6/2.8 Road To Rome (BF1942 expansion) - SafeDisc 2.8 Battlefield Vietnam - SafeDisc 2.9 All of these work fine for me with the patch applied. Please test this patch on many SafeDisc 2.x games as possible and report your results (works or works not). Make sure you have original media mounted and drive/data is visible within wine. If it fails for first time, the media might not ready yet, try again then (I experienced this sometimes). Use this link to verify what SafeDisc Version is used: http://www.120search.net/ (alcohol software copy protection database) Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 48

[Bug 9798] New: bioshock demo needs glsl enabled
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=9798 Summary: bioshock demo needs glsl enabled Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=8240) --> (http://bugs.winehq.org/attachment.cgi?id=8240) crash log with glsl disabled Hello, Bioshock demo crashes if glsl is not enabled. Attached are relevant traces made with: WINEDEBUG=+seh,+tid,+d3d,+d3d_shader wine ./Bioshock.exe -dx9 Using following registry settings enables bioshock demo to run: --- snip --- HKEY_CURRENT_USER/Software/Wine/Direct3D UseGLSL = "enabled" --- snip --- Optional: OffscreenRenderingMode = "fbo" ================== Addendum: wine --version wine-0.9.45-406-g2ba3247 Currently uses secuROM hack (http://bugs.winehq.org/attachment.cgi?id=8235 ) to run, see http://bugs.winehq.org/show_bug.cgi?id=7065 Be sure to include "-dx9" command line to work around directx 10 issue. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 10225] New: SafeDisc 2. x triggers async device ioctl status code propagation bug in wine server
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=10225 Summary: SafeDisc 2.x triggers async device ioctl status code propagation bug in wine server Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-kernel AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=8843) --> (http://bugs.winehq.org/attachment.cgi?id=8843) relevant trace which shows ioctl status code propagation bug Hello, while testing my proof-of-concept patch which makes SafeDisc v2 (yuck!) finally work, I stumbled across a nasty ioctl status code propagation (completion) bug in wine server. Wasted several hours on it .. I was suspecting SD issue whole time, but its a wine server bug :( Attached is relevant trace (WINEDEBUG=+seh,+tid,+relay,+ntoskrnl,+server wine ./BfVietnam.exe) Before the bug is triggered, the SafeDisc security driver makes several device ioctl requests which return 0xC0000001 (unsuccessful) on purpose, e.g. reading debug Drx registers with index that does not exist. This is intended to fool reversers :-) The next operation - checking IDT entries should succeed - but does not (as seen from calling client). The kernel driver completes the operation successfully and returns irp.IoStatus.u.Status == 0 with xxxx bytes in output buffer. I verified it several times by debugging the kernel driver. Upon driver ioctl call return, get_next_device_request() is triggered again in ntoskrnl event loop which sets the return data (and status code) -> set_ioctl_result(). This queues an APC, waking up the client (alertable state). The client process device ioctl completes with 0 (FALSE) which is wrong. Further debugging showed that ioctl_completion APC (dlls/ntdll/file.c) returns the errornous status code in get_ioctl_result() when woken up by server. This error is then propagated in server_ioctl_file() to result in wrong NtDeviceIoControlFile() return code. What puzzled me is that "ioctl->status" is correctly set by set_ioctl_result() (=0) but get_ioctl_result() - called within client context - yields the previous error code (0xC0000001 of failed request). This is either a problem of global vs. thread local error status (global_error vs. current->error/thread) or the ioctl call data is the wrong one. The following patch works for me, letting SD 2.x continue - though i'm not sure if it's right: --- snip --- diff --git a/server/device.c b/server/device.c index 46b2796..8fe8f7c 100644 --- a/server/device.c +++ b/server/device.c @@ -528,7 +528,7 @@ DECL_HANDLER(get_ioctl_result) ioctl->out_data = NULL; } } - set_error( ioctl->status ); + list_remove( &ioctl->dev_entry ); release_object( ioctl ); /* no longer on the device queue */ } --- snip --- Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 8

[Bug 10293] New: sequentially running games/ apps with different SafeDisc versions fails
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=10293 Summary: sequentially running games/apps with different SafeDisc versions fails Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-kernel AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=8945) --> (http://bugs.winehq.org/attachment.cgi?id=8945) Patch which fixes various isses regarding kmode driver unload/reload Hello, currently wine's kernel mode driver cleanup/unloading facility has several issues when it comes to applications/games that unload and reload different driver versions on the fly. Example: run multiple SafeDisc 2.x, 3.x and 4.x games sequentially. Symptoms: game either hangs/crashes/exits silently Usually the SD security driver is placed in "c:\windows\system32\drivers\secdrv.sys" If a SafeDisc protected program encounters a driver version that is incompatible it does the following: - stop the current security service (should unload the driver) - unpack own security driver from resources to temp storage and move the binary to "c:\windows\system32\drivers\secdrv.sys", overwriting the previous - restart the service (loads the new driver) This currently fails for various reasons: (1) The driver binary is loaded using LoadLibrary() -> the matching FreeLibrary() is missing on service stop. This leads to sharing violation when the driver binary going to be replaced (CopyFile fails). (2) No driver unload routine called. Very problematic. Various objects (symlinks) created by driver entry are not freed. When the driver is reloaded the init routine usually fails with "object exists". (3) Driver state objects (driver_obj, driver_extension) have undefined state due to static storage. Raises all sorts of problems because the driver entry routine does not init all fields. --------- Attached is a patch which fixes these problems, allowing to sequentially run programs with different SafeDisc Versions. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 10

[Bug 10451] New: Various AutoDesk 2008 product installers fail due to unimplemented msi. MsiEnumComponentCostsW
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=10451 Summary: Various AutoDesk 2008 product installers fail due to unimplemented msi.MsiEnumComponentCostsW Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=9156) --> (http://bugs.winehq.org/attachment.cgi?id=9156) stub impl of msi.MsiEnumComponentCostsW to keep AutoDesk 2008 installers happy Hello, various AutoDesk 2008 product installers fail due to unimplemented msi.MsiEnumComponentCostsW API (mentioned in bug 9809). --- snip --- wine: Call from 0x7b841460 to unimplemented function msi.dll.MsiEnumComponentCostsW, aborting wine: Unimplemented function msi.dll.MsiEnumComponentCostsW called at address 0x7b841460 (thread 000e), starting debugger... Unhandled exception: unimplemented function msi.dll.MsiEnumComponentCostsW called in 32-bit code (0x7b8414d8). --- snip --- Attached patch makes installer happy. Though that API (A/W) should be fleshed out some day ... this is left as exercise for msi maintainers :-) If you test this on AutoDesk 2008 installers, you need my shell32/shlfileop patch from bug 9809 too. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 10478] New: wine server get/set thread context doesn' t work correctly if simultaneously used by debugger and debuggee
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=10478 Summary: wine server get/set thread context doesn't work correctly if simultaneously used by debugger and debuggee Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-debug AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=9209) --> (http://bugs.winehq.org/attachment.cgi?id=9209) WINEDEBUG=+tid,+server,+win trace of debugging session Hello, while debugging a target with some debugger I experienced severe problems with wine server get/set thread context implementation. It doesn't work correctly if the get/set thread context API is simultaneously used by both, the debugger and the debuggee to manage exception events/control execution transfer. Attached is WINEDEBUG=+tid,+seh,+win trace (don't bother with +win channel output, was for my own purpose). pid=0008, tid=0009 debugger main thread pid=0008, tid=000d debugger debug event loop thread pid=000e, tid=000f debuggee main thread pid=000e, tid=0010 debuggee child thread pid=000e, tid=0011 debuggee child thread pid=000e, tid=0012 debuggee child thread Search for "000d: get_thread_context() = ACCESS_DENIED { self=0, context={} }" in attached log and walk your way back... --- snip --- 000f: queue_exception_event( first=1, record={context={flags=00010007,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=00004000,esi=00004000,edi=00197430,ebp=0034e5d4,eip=7b841378,esp=0034e570,eflags=00200216,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=a3f67070,dr1=0012e150,dr2=0034eec0,dr3=00000000,dr6=00000006,dr7=00000200,float={00000003,0034e234,33746e49,00000032,00000000,000000f8,0034e280,0034e268,00087510,00198af0,00110014,00000001,00000318,00000000,4d430002,4d430000,00198e18,00000010,00000000,00000000,00000000,4d430003,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=e06d7363,flags=1,rec=(nil),addr=0x7b841300,params={19930520,34e670,79f9acc4}} ) 000d: *wakeup* signaled=0 cookie=0x616e24c0 0010: *sent signal* signal=10 0011: *sent signal* signal=10 0012: *sent signal* signal=10 000f: queue_exception_event() = 0 { handle=0x244 } --- snip --- Debuggee main thread throws first chance C++ exception (queues event). Ok. --- snip --- 0010: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=0000001f,ecx=613516a4,edx=00000008,esi=613516a4,edi=7ffd4000,ebp=613516b8,eip=600007f0,esp=61351670,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff4000,ffffffff,604b434d,035f0073,0034dc34,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffe,00000000,40038000,00004000}} ) 0010: set_thread_context() = 0 { self=1 } 0011: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=00000023,ecx=614624a0,edx=00000008,esi=614624a0,edi=7ffd0000,ebp=614624b4,eip=600007f0,esp=6146246c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0100,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffd,80000000,40078662,00000100}} ) 0011: set_thread_context() = 0 { self=1 } 0012: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=0000003a,ecx=6c101d70,edx=00000008,esi=6c101d70,edi=7ffcc000,ebp=6c101d84,eip=600007f0,esp=6c101d3c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0120,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,00000000,00000000,80000000,00003ffd,60000000,400785bc,00000120}} ) 0012: set_thread_context() = 0 { self=1 } --- snip --- The debuggee child threads get SIGUSR1, suspend themselves (on purpose!). Ok. --- snip --- 000d: wait_debug_event( get_handle=1 ) 000d: wait_debug_event() = 0 { pid=000e, tid=000f, wait=(nil), event={exception,{code=e06d7363,flags=1,rec=(nil),addr=0x7b841300,params={19930520,34e670,79f9acc4},first=1} } .. 000d: continue_debug_event( pid=000e, tid=000f, status=-2147418111 ) 000f: *wakeup* signaled=0 cookie=0x34dfd4 0010: *wakeup* signaled=258 cookie=0x7ffd77b4 0011: *wakeup* signaled=258 cookie=0x7ffd37b4 000d: continue_debug_event() = 0 .. --- snip --- Debugger wakes up and sees first chance C++ exception, decides to pass it to debuggee (resumes execution of threads). Ok. --- snip --- 000f: get_exception_status( handle=0x244 ) 000f: get_exception_status() = 80010001 { context={flags=00010007,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=00004000,esi=00004000,edi=00197430,ebp=0034e5d4,eip=7b841378,esp=0034e570,eflags=00200216,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=a3f67070,dr1=0012e150,dr2=0034eec0,dr3=00000000,dr6=00000006,dr7=00000200,float={00000003,0034e234,33746e49,00000032,00000000,000000f8,0034e280,0034e268,00087510,00198af0,00110014,00000001,00000318,00000000,4d430002,4d430000,00198e18,00000010,00000000,00000000,00000000,4d430003,00000000,00000000,00000000,00000000,00000000,00000000}} } 0010: get_thread_context( handle=0xfffffffe, flags=00010007, suspend=1 ) 0010: get_thread_context() = 0 { self=1, context={flags=0001001f,eax=00000003,ebx=0000001f,ecx=613516a4,edx=00000008,esi=613516a4,edi=7ffd4000,ebp=613516b8,eip=600007f0,esp=61351670,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff4000,ffffffff,604b434d,035f0073,0034dc34,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffe,00000000,40038000,00004000}} } 0011: get_thread_context( handle=0xfffffffe, flags=00010007, suspend=1 ) 0011: get_thread_context() = 0 { self=1, context={flags=0001001f,eax=00000003,ebx=00000023,ecx=614624a0,edx=00000008,esi=614624a0,edi=7ffd0000,ebp=614624b4,eip=600007f0,esp=6146246c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0100,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffd,80000000,40078662,00000100}} } 000d: select( flags=4, cookie=0x616e24c0, signal=(nil), prev_apc=(nil), timeout=+1.0000000, result={}, handles={0xa8} ) 000d: select() = PENDING { apc_handle=(nil), timeout=1c828ffa61af642 (+1.0000000), call={APC_NONE} } 0012: get_thread_context( handle=0xfffffffe, flags=00010007, suspend=1 ) 0012: get_thread_context() = 0 { self=1, context={flags=0001001f,eax=00000003,ebx=0000003a,ecx=6c101d70,edx=00000008,esi=6c101d70,edi=7ffcc000,ebp=6c101d84,eip=600007f0,esp=6c101d3c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0120,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,00000000,00000000,80000000,00003ffd,60000000,400785bc,00000120}} } 000f: get_process_info( handle=0xffffffff ) 000f: get_process_info() = 0 { pid=000e, ppid=0008, exit_code=259, priority=2, affinity=1, peb=0x7ffdf000, start_time=1c828ff9f2037c6 (-10.7374150), end_time=0 } 000f: queue_exception_event( first=1, record={context={flags=00010007,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=0034ee58,esi=0034ee58,edi=e0434f4d,ebp=0034ee20,eip=7b841378,esp=0034edbc,eflags=00200212,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=02d410d8,dr2=a3f67060,dr3=00000000,dr6=00110000,dr7=00000002,float={0034eaa4,00001302,00198d10,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001,0034eadc,79e783ca,00110000,00000000,79e783e6,a3f67cf4,00000001,00197430,00000000,00000008,00000000,0034eb14,7a3296dc,ffffffff,79e783e6,79e7839d,00110000}},rec={code=e0434f4d,flags=1,rec=(nil),addr=0x7b841300,params={80004002}} ) --- snip --- Main debuggee thread SEH evaluates first chance exception and converts it internally to CLR exception, throwing again. --- snip --- 0010: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=0000001f,ecx=613516a4,edx=00000008,esi=613516a4,edi=7ffd4000,ebp=613516b8,eip=600007f0,esp=61351670,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff4000,ffffffff,604b434d,035f0073,0034dc34,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffe,00000000,40038000,00004000}} ) 0010: set_thread_context() = 0 { self=1 } 0011: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=00000023,ecx=614624a0,edx=00000008,esi=614624a0,edi=7ffd0000,ebp=614624b4,eip=600007f0,esp=6146246c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0100,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffd,80000000,40078662,00000100}} ) 0011: set_thread_context() = 0 { self=1 } 0012: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=0000003a,ecx=6c101d70,edx=00000008,esi=6c101d70,edi=7ffcc000,ebp=6c101d84,eip=600007f0,esp=6c101d3c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0120,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,00000000,00000000,80000000,00003ffd,60000000,400785bc,00000120}} ) 0012: set_thread_context() = 0 { self=1 } --- snip --- The debuggee child threads get SIGUSR1, suspend themselves again (on purpose!). Ok. --- snip --- 000d: suspend_thread( handle=0xd4 ) 000d: suspend_thread() = 0 { count=0 } 000d: suspend_thread( handle=0xd8 ) 000d: suspend_thread() = 0 { count=0 } 000d: suspend_thread( handle=0xf8 ) 000d: suspend_thread() = 0 { count=0 } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000f: *signal* signal=19 000d: get_thread_context() = 0 { self=0, context={flags=0001003f,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=0034ee58,esi=0034ee58,edi=e0434f4d,ebp=0034ee20,eip=7b841378,esp=0034edbc,eflags=00200212,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={0034eaa4,00001302,00198d10,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001,0034eadc,79e783ca,00110000,00000000,79e783e6,a3f67cf4,00000001,00197430,00000000,00000008,00000000,0034eb14,7a3296dc,ffffffff,79e783e6,79e7839d,00110000}} } 000d: read_process_memory( handle=0xb8, addr=0x7b841378 ) 000f: *signal* signal=19 000d: read_process_memory() = 0 { data={8b} } 000d: resume_thread( handle=0xbc ) 000d: resume_thread() = 0 { count=1 } 000d: resume_thread( handle=0xd4 ) 000d: resume_thread() = 0 { count=1 } 000d: resume_thread( handle=0xd8 ) 000d: resume_thread() = 0 { count=1 } 000d: resume_thread( handle=0xf8 ) 000d: resume_thread() = 0 { count=1 } 000d: continue_debug_event( pid=000e, tid=000f, status=-2147418111 ) 000f: *wakeup* signaled=0 cookie=0x34e824 0010: *wakeup* signaled=258 cookie=0x7ffd77b4 0011: *wakeup* signaled=258 cookie=0x7ffd37b4 0012: *wakeup* signaled=258 cookie=0x7ffcf7b4 000d: continue_debug_event() = 0 --- snip --- Debugger wakes up again, now seeing the CLR exception. Debugger suspends debuggee threads - although unnecessary due to debugging event before = already suspended. This exception type is unhandled, main debuggee thread receives SIGSTOP. Execution of debuggee threads resumed. --- snip --- 000f: get_exception_status( handle=0x244 ) 000f: get_exception_status() = 80010001 { context={flags=00010007,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=0034ee58,esi=0034ee58,edi=e0434f4d,ebp=0034ee20,eip=7b841378,esp=0034edbc,eflags=00200212,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1= .. 000f: *killed* exit_code=0 --- snip --- Debuggee main thread dies. Ok. --- snip --- 000d: wait_debug_event( get_handle=1 ) 000d: wait_debug_event() = 0 { pid=000e, tid=000f, wait=(nil), event={exit_thread,code=0} } 000d: suspend_thread( handle=0xd4 ) 000d: suspend_thread() = 0 { count=0 } 000d: suspend_thread( handle=0xd8 ) 000d: suspend_thread() = 0 { count=0 } 000d: suspend_thread( handle=0xf8 ) 000d: suspend_thread() = 0 { count=0 } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: read_process_memory( handle=0xb8, addr=(nil) ) 000d: read_process_memory() = ACCESS_DENIED { data={} } .. --- snip --- Debugger wakes up, sees debuggee (main) thread termination event. Suspends remaining debuggee threads - although unnecessary due to debugging event before = already suspended. Now the problem: the debugger can't get the thread context of any debuggee threads nor process memory anymore after this point. Basically dead end here... The reason is the way server/thread.c/get_thread_context() and server/thread.c/set_thread_context() handles thread->context and thread->suspend_context data ("self" vs. "foreign" threads) child threads "self": set_thread_context() -> suspend == 1 -> thread->suspend_context filled get_thread_context(): req->suspend == 1 && thread == current && thread->suspend_context --- snip --- if (thread->context == thread->suspend_context) thread->context = NULL; set_reply_data_ptr( thread->suspend_context, sizeof(CONTEXT) ); thread->suspend_context = NULL; --- snip --- Which resets the context and suspend context data. Next time when the debugger itself tries to query the thread context of already suspended debuggee child threads it will obviously fail: "foreign" debugger thread: get_thread_context() -> suspend == 0 --- snip --- else if (thread != current && !thread->context) { /* thread is not suspended, retry (if it's still running) */ if (thread->state != RUNNING) set_error( STATUS_ACCESS_DENIED ); else set_error( STATUS_PENDING ); } --- snip --- I guess this is an oversight, a behavior not really intended? Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5

[Bug 11789] New: Recent Fls API additions break many installers/apps
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=11789 Summary: Recent Fls API additions break many installers/apps Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, after upgrading to recent GIT (wine-0.9.56-264-g848383a) it seems the recent Fls API additions broke almost every installer i'm working on ;-( http://source.winehq.org/git/wine.git/?a=commit;h=6d6e9a42b13c827d1cc795c3b… http://source.winehq.org/git/wine.git/?a=commit;h=b2ad268a8b7d7ac65029bbdd7… I won't question if there was a specific need to introduce this ... Reason of crash in FlsAlloc() is simple. Different TEB definition in <thread.h> vs. <winternl.h> leads to incorrect TEB allocation size (ntdll -> thread.h) vs. usage (fiber/Fls -> winternl.h) Solution: use winternl.h TEB definition to ensure correct TEB allocation size in dlls/ntdll/thread.c Either change include order of both (needs <stdarg.h>) .. or sync both .. or better get rid of the thread.h one to avoid such recurring problem. Regards -- 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.

1 4

[Bug 14499] New: ImageDirectoryEntryToDataEx: section header param [out, optional], needs to be zeroed before RtlImageRvaToVa
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=14499 Summary: ImageDirectoryEntryToDataEx: section header param [out, optional], needs to be zeroed before RtlImageRvaToVa Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dbghelp AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, a quickie, as title says. Section header param passed to ImageDirectoryEntryToDataEx is [out, optional]. Crashes RtlImageRvaToVa if caller doesn't initialize the out param to zero (stack var). --- snip --- .. 0020:Call dbghelp.ImageDirectoryEntryToDataEx(00340000,00000000,00000006,0032cc34,0032cc38) ret=004048ec 0020:Call ntdll.RtlImageNtHeader(00340000) ret=6076ce7b 0020:Ret ntdll.RtlImageNtHeader() retval=003400e8 ret=6076ce7b 0020:Call ntdll.RtlImageRvaToVa(003400e8,00340000,00001270,0032cc38) ret=6076ceeb 0020:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7bc4337a --- snip --- Fix: unconditionally "if (section) *section = NULL" on ImageDirectoryEntryToDataEx entry (like size). Regards -- 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.

1 4

[Bug 14539] New: RtlIsTextUnicode regression: ideographic space should not be used in check for reversed control chars
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=14539 Summary: RtlIsTextUnicode regression: ideographic space should not be used in check for reversed control chars Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, a regression in RtlIsTextUnicode causes VS.NET 2005 Installer and probably others to fail. The setup database, a unicode .ini file is not correctly identified as such. --- snip --- 0026:Call setupapi.SetupOpenInfFileW(007eb3e8 L"E:\\vs\\setup\\setup.sdb",00000000,00000002,0033eab4) ret=5022237f 0026:Call KERNEL32.GetFullPathNameW(007eb3e8 L"E:\\vs\\setup\\setup.sdb",00000000,00000000,00000000) ret=606148a8 0026:Ret KERNEL32.GetFullPathNameW() retval=00000016 ret=606148a8 0026:Call ntdll.RtlAllocateHeap(00110000,00000000,0000002c) ret=606148e0 0026:Ret ntdll.RtlAllocateHeap() retval=00142a08 ret=606148e0 0026:Call KERNEL32.GetFullPathNameW(007eb3e8 L"E:\\vs\\setup\\setup.sdb",00000016,00142a08,00000000) ret=60614909 0026:Ret KERNEL32.GetFullPathNameW() retval=00000015 ret=60614909 0026:Call KERNEL32.CreateFileW(00142a08 L"E:\\vs\\setup\\setup.sdb",80000000,00000001,00000000,00000003,00000000,00000000) ret=60614947 0026:Ret KERNEL32.CreateFileW() retval=00000068 ret=60614947 0026:Call KERNEL32.GetFileSize(00000068,00000000) ret=60614966 0026:Ret KERNEL32.GetFileSize() retval=00012f9e ret=60614966 0026:Call KERNEL32.CreateFileMappingW(00000068,00000000,00000002,00000000,00012f9e,00000000) ret=6061499b 0026:Ret KERNEL32.CreateFileMappingW() retval=0000006c ret=6061499b 0026:Call KERNEL32.MapViewOfFile(0000006c,00000004,00000000,00000000,00012f9e) ret=60614a2f 0026:Ret KERNEL32.MapViewOfFile() retval=003b0000 ret=60614a2f 0026:Call ntdll.NtClose(0000006c) ret=60614a3d 0026:Ret ntdll.NtClose() retval=00000000 ret=60614a3d 0026:Call ntdll.RtlAllocateHeap(00110000,00000008,0000002c) ret=60614a80 0026:Ret ntdll.RtlAllocateHeap() retval=00142a40 ret=60614a80 0026:Call ntdll.RtlAllocateHeap(00110000,00000000,00025f3c) ret=60614ab3 0026:Ret ntdll.RtlAllocateHeap() retval=00147ab8 ret=60614ab3 0026:Call ntdll.RtlIsTextUnicode(003b0000,00012f9e,00000000) ret=60614ae8 0026:Ret ntdll.RtlIsTextUnicode() retval=00000000 ret=60614ae8 0026:Call ntdll.RtlAllocateHeap(00110000,00000000,00025f3c) ret=60614b2b 0026:Ret ntdll.RtlAllocateHeap() retval=0016da00 ret=60614b2b 0026:Call KERNEL32.MultiByteToWideChar(00000000,00000000,003b0000 "\xff\xfe\r",00012f9e,0016da00,00012f9e) ret=60614b6f 0026:Ret KERNEL32.MultiByteToWideChar() retval=00012f9e ret=60614b6f 0026:Call ntdll.RtlReAllocateHeap(00110000,00000010,00147ab8,00000000) ret=606145d9 0026:Ret ntdll.RtlReAllocateHeap() retval=00147ab8 ret=606145d9 0026:Call ntdll.RtlFreeHeap(00110000,00000000,0016da00) ret=60614ba9 0026:Ret ntdll.RtlFreeHeap() retval=00000001 ret=60614ba9 0026:Call KERNEL32.UnmapViewOfFile(003b0000) ret=60614bc2 0026:Ret KERNEL32.UnmapViewOfFile() retval=00000001 ret=60614bc2 0026:Call ntdll.RtlFreeHeap(00110000,00000000,00142a40) ret=60614be5 0026:Ret ntdll.RtlFreeHeap() retval=00000001 ret=60614be5 0026:Call KERNEL32.CloseHandle(00000068) ret=606149af 0026:Ret KERNEL32.CloseHandle() retval=00000001 ret=606149af 0026:Call ntdll.RtlFreeHeap(00110000,00000000,00142a08) ret=606149d2 0026:Ret ntdll.RtlFreeHeap() retval=00000001 ret=606149d2 0026:Ret setupapi.SetupOpenInfFileW() retval=ffffffff ret=5022237f .. 0026:Call KERNEL32.WritePrivateProfileStringW(501b82fc L"Error",0033ed28 L"Error1",007ebbe8 L"0:0:setup.exe:LoadSetupDatabase() : The .sdb file is either missing, corrupt, or the signiture portion is missing",0033eb14 L"C:\\windows\\temp\\msinterr.txt") ret=501fcdeb --- snip --- The input data for your pleasure: --- snip --- $ hexdump -n 256 -C setup.sdb 00000000 ff fe 0d 00 0a 00 5b 00 56 00 65 00 72 00 73 00 |......[.V.e.r.s.| 00000010 69 00 6f 00 6e 00 5d 00 0d 00 0a 00 53 00 69 00 |i.o.n.].....S.i.| 00000020 67 00 6e 00 61 00 74 00 75 00 72 00 65 00 20 00 |g.n.a.t.u.r.e. .| 00000030 3d 00 20 00 22 00 24 00 57 00 69 00 6e 00 64 00 |=. .".$.W.i.n.d.| 00000040 6f 00 77 00 73 00 20 00 4e 00 54 00 24 00 22 00 |o.w.s. .N.T.$.".| 00000050 0d 00 0a 00 50 00 72 00 6f 00 76 00 69 00 64 00 |....P.r.o.v.i.d.| 00000060 65 00 72 00 3d 00 22 00 4d 00 69 00 63 00 72 00 |e.r.=.".M.i.c.r.| 00000070 6f 00 73 00 6f 00 66 00 74 00 20 00 56 00 69 00 |o.s.o.f.t. .V.i.| 00000080 73 00 75 00 61 00 6c 00 20 00 53 00 74 00 75 00 |s.u.a.l. .S.t.u.| 00000090 64 00 69 00 6f 00 20 00 32 00 30 00 30 00 35 00 |d.i.o. .2.0.0.5.| 000000a0 20 00 50 00 72 00 6f 00 66 00 65 00 73 00 73 00 | .P.r.o.f.e.s.s.| 000000b0 69 00 6f 00 6e 00 61 00 6c 00 20 00 45 00 64 00 |i.o.n.a.l. .E.d.| 000000c0 69 00 74 00 69 00 6f 00 6e 00 20 00 2d 00 20 00 |i.t.i.o.n. .-. .| 000000d0 45 00 4e 00 55 00 22 00 0d 00 0a 00 56 00 65 00 |E.N.U.".....V.e.| 000000e0 72 00 73 00 69 00 6f 00 6e 00 3d 00 38 00 30 00 |r.s.i.o.n.=.8.0.| 000000f0 30 00 2e 00 31 00 30 00 30 00 2e 00 30 00 30 00 |0...1.0.0...0.0.| --- snip --- BOM for UTF-16 is there. The problem is the ideographic space (U+3000) in reverse control chars check (punctuation symbol or whitespace in languages like Chinese, Japanese, or Korean). --- snip --- static const WCHAR byterev_control_chars[] = {0x0d00,0x0a00,0x0900,0x2000,0x0030,0}; --- snip --- This clashes with the multibyte mapping of digit 0: 0x30 -> 0x0030 By removing the reversed ideographic space, the file is correctly recognized. Problematic commit: 8f3ae2011c39d092b0c8e2e6a9aabddbd2596748 Regards -- 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.

1 5

[Bug 14568] New: Silence FIXME from CoGetContextToken stub to prevent flooding of trace output when COM+ context is queried from .NET runtime
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=14568 Summary: Silence FIXME from CoGetContextToken stub to prevent flooding of trace output when COM+ context is queried from .NET runtime Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ole32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, ole32.CoGetContextToken being currently a stub prints out large amounts of FIXME's when .NET runtime queries COM+ context for run/debugged .NET applications. --- snip --- .. fixme:ole:CoGetContextToken stub fixme:ole:CoGetContextToken stub fixme:ole:CoGetContextToken stub fixme:ole:CoGetContextToken stub fixme:ole:CoGetContextToken stub .. <repeat this gazillion times> --- snip --- Please use a static or remove the FIXME. It's really annoying and makes console tracing/debugging of .NET apps really messy. And no, WINEDEBUG=-ole is *not* an option, it actually hides other bugs. Regards -- 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.

1 4

[Bug 16544] New: winmm: mixerOpen(): when CALLBACK_WINDOW flag given, NULL Callback is also valid
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=16544 Summary: winmm: mixerOpen(): when CALLBACK_WINDOW flag given, NULL Callback is also valid Product: Wine Version: 1.1.10 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, while revisiting a Battlefield 2 issue I came across another one... BF2 voice setup (C:\Program Files\EA GAMES\Battlefield 2\BF2VoiceSetup.exe) crashes when "Save Settings" button is clicked. This happens from BF2 sub-installer (causing no harm) or when the voice setup app is run stand alone. --- snip --- .. wine: Unhandled page fault on read access to 0x0000002c at address 0x408661 (thread 0044), starting debugger... Unhandled exception: page fault on read access to 0x0000002c in 32-bit code (0x00408661). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:00408661 ESP:0033dadc EBP:0033dbc0 EFLAGS:00010216( - 00 -RIAP1) EAX:00000000 EBX:00000111 ECX:00000000 EDX:00000002 ESI:0033dadc EDI:0033dbc0 Stack dump: 0x0033dadc: 00000001 0033f60c 00000111 cccccccc 0x0033daec: cccccccc cccccccc cccccccc cccccccc 0x0033dafc: cccccccc cccccccc cccccccc cccccccc 0x0033db0c: cccccccc cccccccc cccccccc cccccccc 0x0033db1c: cccccccc cccccccc cccccccc cccccccc 0x0033db2c: cccccccc cccccccc cccccccc cccccccc Backtrace: =>0 0x00408661 in bf2voicesetup (+0x8661) (0x0033dbc0) 1 0x00403978 in bf2voicesetup (+0x3978) (0x0033dd8c) 2 0x7c171915 in mfc71 (+0x31915) (0x0033ddbc) 3 0x7c14db36 in mfc71 (+0xdb36) (0x0033dde0) 4 0x7c175cd8 in mfc71 (+0x35cd8) (0x0033de30) 5 0x7c175cf2 in mfc71 (+0x35cf2) (0x0033dec4) .. --- snip --- The crash location is only indirectly related to the problem, hence this was a bit tricky to debug to the real cause. The real problem seems to be a Wine's winmm.mixerOpen() handling fdwOpen flags with CALLBACK_WINDOW when dwCallback is NULL. Consider the following (WINEDEBUG=+winmm): --- snip --- 0023:trace:winmm:DllMain 0x60380000 0x1 0x1 0023:trace:winmm:MMDRV_Init () .. 0023:trace:winmm:MIXER_Open (0x425f0c, 0, 00000000, 00000000, 00010000) .. --- snip --- mixerOpen() with CALLBACK_WINDOW flags and NULL dwCallback results in MMSYSERR_INVALPARAM. Corresponding Wine code: --- snip dlls/winmm/winmm.c:MIXER_Open --- UINT MIXER_Open(LPHMIXER lphMix, UINT uDeviceID, DWORD_PTR dwCallback, DWORD_PTR dwInstance, DWORD fdwOpen, BOOL bFrom32) { ... switch (fdwOpen & CALLBACK_TYPEMASK) { .. case CALLBACK_WINDOW: mod.dwInstance = dwCallback; if (!IsWindow((HWND)dwCallback)) return MMSYSERR_INVALPARAM; break; } .. } --- snip dlls/winmm/winmm.c:MIXER_Open --- MSDN: http://msdn.microsoft.com/en-us/library/ms712134.aspx It says: "The dwCallback parameter is assumed to be a window handle (HWND)." Unfortunately the app expects MMSYSERR_NOERROR but not a failure (bad app error handling anyway). Hence crucial data structures are not getting setup properly (C++ instances/member data), leading to NULL ptr dereference at much later time. A small conformance test case (fdwOpen=CALLBACK_WINDOW, dwCallback=NULL) should reveal this MSDN documentation insufficiency. Regards -- 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.

1 5

[Bug 16598] New: winuser.rh misses some standard control ids (dialog button, ...) resulting in wrc failure with windows.h include only
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=16598 Summary: winuser.rh misses some standard control ids (dialog button, ...) resulting in wrc failure with windows.h include only Product: Wine Version: 1.1.10 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, while doing some occasional end user support on #winehq (*yuck*), one user complained about wrc not compiling his .rc file. Visual C++ and mingw toolchains compiled it in Windows without problems but Wine's wrc didn't like it. --- snip --- ... resource.rc:114:31: Error: syntax error --- snip --- He sent me a link to the .rc file to have a look at. Relevant parts: Resource.rc: --- snip --- // Microsoft Visual C++ generated resource script. // #include "resource.h" #define APSTUDIO_READONLY_SYMBOLS ///////////////////////////////////////////////////////////////////////////// // // Generated from the TEXTINCLUDE 2 resource. // #include <windows.h> ///////////////////////////////////////////////////////////////////////////// #undef APSTUDIO_READONLY_SYMBOLS ... ///////////////////////////////////////////////////////////////////////////// // // Menu // IDR_MENU MENU BEGIN ... END ///////////////////////////////////////////////////////////////////////////// // // Dialog // IDD_MEMTRANSFER DIALOGEX 100, 100, 174, 90 STYLE DS_SETFONT | DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU CAPTION "Memory Transfer" FONT 8, "Courier New", 0, 0, 0x0 BEGIN DEFPUSHBUTTON "&OK",IDOK,42,72,40,14 ... --- snip --- Resource.h: --- snip --- //{{NO_DEPENDENCIES}} // Microsoft Visual C++ generated include file. // Used by resource.rc // #define IDR_MENU 100 #define IDI_ICON 101 #define IDB_BITMAP 102 #define IDR_MAIN_ACCEL 103 #define IDD_MEMTRANSFER 104 ... --- snip --- The resource include chain is as follows: resource.h windows.h (due to RC_INVOKED defined by wrc) -> winresrc.h -> winuser.rh and commctrl.rh The problem is that winuser.rh defines only a subset of winuser.h control ids This breaks resource scripts which for example reference standard dialog button IDs. Telling the user to explicitly include <winuser.h> solved his problems. You might want to extend winuser.rh a bit to include often used standard control ids (ex: dialog button). Regards -- 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.

1 4

[Bug 13399] New: Appdb doesn't remember logins
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=13399 Summary: Appdb doesn't remember logins Product: WineHQ Apps Database Version: unspecified Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: appdb-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: tehblunderbuss(a)gmail.com The appdb doesn't remember logins, like how the bugzilla or wiki do. -- 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.

1 7

[Bug 12939] New: >=wine-0.9.59: Selection using control key and mouse button does not work.
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=12939 Summary: >=wine-0.9.59: Selection using control key and mouse button does not work. Product: WineHQ Bugzilla Version: unspecified Platform: PC URL: http://www.foobar2000.org OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: bugzilla-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: h.judt(a)gmx.at In Foobar2000, <Control>-<Mouse1> should select or deselect a single entry in the playlist. Instead, it just selects a new entry and deselects all others as if the control key has not been pressed. This worked in <wine-0.9.59 but does not in >=wine-0.9.59 (last version tested was 0.9.61). Similar problem with <Shift>-<Mouse1> existed in =wine-0.9.59, but was solved in >=0.9.60 and works fine now. Occurs with: Foobar2000-0.9.4.4, Exact Audio Copy-0.99prebeta4, file selector dialogs, but might effect other software / versions / dialogs as well. When I launch Foobar2000 and try to add files, I get the following messages on the terminal, maybe this is of some help: fixme:menu:TrackPopupMenuEx not fully implemented fixme:commdlg:GetFileName95 Flags 0x00800000 not yet implemented fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000041 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000041 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010 -- 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.

1 29

[Bug 21777] New: CreateMutexExA(): use heap for A to W conversion to work around transbase db engine app bug (affects multiple apps, TecDoc CATALOG ...)
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=21777 Summary: CreateMutexExA(): use heap for A to W conversion to work around transbase db engine app bug (affects multiple apps, TecDoc CATALOG ...) Product: Wine Version: 1.1.39 Platform: x86 URL: http://www.tecdoc.de OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, at the end of TecDoc CATALOG 1/2010 DVD install a crash dialog is displayed while starting a service (the msi part of install is finished anyway). The database engine service has auto-start type set hence on every program start (wine notepad) the infamous crash dialog is displayed. This turns out to be an app bug but due to differences in Wine vs. Windows API design/usage this bug has no consequences in Windows and goes on unnoticed. Unfortunately the part of software that crashes comes from another software supplier "Transaction Software" (http://www1.transaction.de/transaction/). Many automotive spare parts catalogue software (BMW, VW, Audi, GM, Fiat ...) internally use the Transbase SQL database engine for years. In case of Wine/Linux this means many broken apps/versions in the wild due to this bug and even if the original software supplier fixes the bug, it will take years until spare parts catalogue software vendors using the engine to pick up and release new versions of their own products. Despite being an app bug I suggest to modify Wine to work around this developer stupidity. Here it goes, first the crash itself: --- snip --- wine: Unhandled page fault on read access to 0x012f0000 at address 0x681ee546 (thread 001d), starting debugger... Unhandled exception: page fault on read access to 0x012f0000 in 32-bit code (0x681ee546). ... Threads: process tid prio (all id:s are in hex) ... 00000019 (D) C:\TECDOC_CD\1_2010\db\tbmux32.exe 0000001d 0 <== 0000001b 0 0000001a 0 ... Backtrace: =>0 0x681ee546 (0x012eddd4) 1 0x7bc79ac0 NtCreateMutant+0xae(MutantHandle=0x12eded4, access=0x1f0001, attr=0x12edeb4, InitialOwner=0) [/opt/wine/wine-git/dlls/ntdll/sync.c:429] in ntdll (0x012ede94) 2 0x7b869dc8 CreateMutexExW+0xb2(sa=0x12ee16c, name="Global\TBSEM ( TECDOC_C ) = (Key=32769, Ind=0)", flags=0, access=0x1f0001) [/opt/wine/wine-git/dlls/kernel32/sync.c:653] in kernel32 (0x012edee4) 3 0x7b869d0c CreateMutexExA+0xb6(sa=0x12ee16c, name="Global\TBSEM ( TECDOC_C ) = (Key=32769, Ind=0)", flags=0, access=0x1f0001) [/opt/wine/wine-git/dlls/kernel32/sync.c:626] in kernel32 (0x012ee124) 4 0x7b869c08 CreateMutexA+0x3a(sa=0x12ee16c, owner=0, name="Global\TBSEM ( TECDOC_C ) = (Key=32769, Ind=0)") [/opt/wine/wine-git/dlls/kernel32/sync.c:599] in kernel32 (0x012ee144) 5 0x0041a2a3 in tbmux32 (+0x1a2a3) (0x74fd9c13) 6 0x458d28ec (0x83e58955) --- snip --- Starting the whole thing (db service) with +relay exhibits a different behaviour: the service doesn't crash but it doesn't really work, indicating a stack usage problem. Have a close look at security descriptor dump, DACL part: --- snip --- 001e:Call advapi32.InitializeSecurityDescriptor(012ee2bc,00000001) ret=00419b06 001e:Ret advapi32.InitializeSecurityDescriptor() retval=00000001 ret=00419b06 001e:Call advapi32.InitializeAcl(012ede8c,00000400,00000002) ret=00419b28 001e:Ret advapi32.InitializeAcl() retval=00000001 ret=00419b28 001e:Call advapi32.InitializeSid(012eda8c,012eda84,00000001) ret=00419b47 001e:Ret advapi32.InitializeSid() retval=00000001 ret=00419b47 001e:Call advapi32.GetSidSubAuthority(012eda8c,00000000) ret=00419b60 001e:Ret advapi32.GetSidSubAuthority() retval=012eda94 ret=00419b60 001e:Call advapi32.AddAccessAllowedAce(012ede8c,00000002,10000000,012eda8c) ret=00419b7c 001e:Ret advapi32.AddAccessAllowedAce() retval=00000001 ret=00419b7c 001e:Call advapi32.SetSecurityDescriptorDacl(012ee2bc,00000001,012ede8c,00000000) ret=00419b9e 001e:Ret advapi32.SetSecurityDescriptorDacl() retval=00000001 ret=00419b9e 001e:Call KERNEL32.CreateMutexA(012ee2b0,00000000,012ee2d0 "Global\\TBSEM ( TECDOC_C ) = (Key=808607544, Ind=0)") ret=0041a2a3 001e: create_mutex( access=001f0001, attributes=00000080, owned=0, objattr={rootdir=0018,sd={control=00000004,owner=<not present>,group=<not present>,sacl={},dacl={{AceType=unknown<156>,AceFlags=e2},{AceType=unknown<46>,AceFlags=1}}},name=L"Global\\TBSEM ( TECDOC_C ) = (Key=808607544, Ind=0)"} ) 001e: create_mutex() = INVALID_SECURITY_DESCR { handle=0000 } 001e:Ret KERNEL32.CreateMutexA() retval=00000000 ret=0041a2a3 --- snip --- Pretty much messed up. To keep the story short, I translated debugger disassembly snippets and annotated stack dumps into a snippet of C code so you won't get annoyed with too much detail ;-) This is most likely what the app does (might not be 100% accurate, just to illustrate the problem): --- stupid app code start --- static int prepare_sd( SECURITY_ATTRIBUTES *sa) { SID_IDENTIFIER_AUTHORITY sia_world = SECURITY_WORLD_SID_AUTHORITY; BYTE user_sid[0x400]; BYTE acl_buffer[0x400]; int res = InitializeSecurityDescriptor( sa->lpSecurityDescriptor, SECURITY_DESCRIPTOR_REVISION); if( !retval) return res; res = InitializeAcl( (PACL) acl_buffer, sizeof(acl_buffer), ACL_REVISION); if( !retval) return res; res = InitializeSid( (PSID) user_sid, &sia_world, 1); if( !retval) return res; *GetSidSubAuthority( (PSID) user_sid, 0) = SECURITY_WORLD_RID; res = AddAccessAllowedAce( (PACL) acl_buffer, ACL_REVISION, 0x10000000, (PSID) user_sid); if( !retval) return res; return SetSecurityDescriptorDacl( sa->lpSecurityDescriptor, TRUE, (PACL)acl_buffer, FALSE); } static int open_app_mutex( ...) { SECURITY_DESCRIPTOR sd; SECURITY_ATTRIBUTES sa = {0}; char name[0x80]; wsprintfA( name, "xxx", ...); sa.nLength= sizeof(SECURITY_ATTRIBUTES); sa.lpSecurityDescriptor = &sd; sa.bInheritHandle = FALSE; prepare_sd( &sa); CreateMutexA( &sa, FALSE, name); ... } --- stupid app code end --- You can probably spot the biggest mistake of all pretty soon: some "genius" decided to put everything on stack in prepare_sd(). Upon return of prepare_sd() helper function, the stack locals used within prepare_sd() are still *intact* When the app calls CreateMutexA(), the call sequence is as follows: CreateMutexA -> CreateMutexExA -> CreateMutexExW -> NtCreateMutant --- snip dlls/kernel32/sync.c --- HANDLE WINAPI CreateMutexA( SECURITY_ATTRIBUTES *sa, BOOL owner, LPCSTR name ) { return CreateMutexExA( sa, name, owner ? CREATE_MUTEX_INITIAL_OWNER : 0, MUTEX_ALL_ACCESS ); } ... HANDLE WINAPI CreateMutexExA( SECURITY_ATTRIBUTES *sa, LPCSTR name, DWORD flags, DWORD access ) { WCHAR buffer[MAX_PATH]; if (!name) return CreateMutexExW( sa, NULL, flags, access ); if (!MultiByteToWideChar( CP_ACP, 0, name, -1, buffer, MAX_PATH )) { SetLastError( ERROR_FILENAME_EXCED_RANGE ); return 0; } return CreateMutexExW( sa, buffer, flags, access ); } --- snip dlls/kernel32/sync.c --- The problem is buried within CreateMutexExA(): the A to W conversion uses a stack based buffer of MAX_PATH len. This eats stack, partly overwriting the ACL buffer (DACL) from previous prepare_sd() which used to be a stack local too. The reason that this doesn't happen on Windows is most likely conversions are heap based or the call path to kernel mode is very short, not consuming that much stack as Wine does. I verified with a patch to use heap based buffer in CreateMutexExA() for A to W conversion (similar what's being done in CreateMailslotA()) and it lets the app succeed despite that nasty stack bug. I'll leave it to Alexandre to judge this (change or leave Wine as it is). If you decide for WONTFIX (that app bug would really deserve such treatment), I will attach a patch to give users a chance work around various broken transbase versions. Regards -- 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.

1 4

[Bug 24213] New: WMI: provide "WMIC" stub executable to silence various "file not found" messages (Java SE JRE/JDK installers)
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=24213 Summary: WMI: provide "WMIC" stub executable to silence various "file not found" messages (Java SE JRE/JDK installers) Product: Wine Version: 1.3.1 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: wmi&wbemprox AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, when installing Java SE JRE/JDK, the installer calls the WMIC executable (using "cmd"), cluttering console with messages: --- snip --- wine: cannot find L"C:\\windows\\system32\\WMIC.exe" --- snip --- This is a tool to access Windows Management Instrumentation (WMI) from the command line, part of WMI core. See: http://msdn.microsoft.com/en-us/library/aa394531.aspx Trace log: --- snip --- 0047:Call KERNEL32.CreateProcessA(00000000,005dead0 "cmd /C WMIC computersystem get model",00000000,00000000,00000001,08000400,00000000,00000000,0074e3f8,0074e43c) ret=6d337ea3 ... 0047:Ret KERNEL32.CreateProcessA() retval=00000001 ret=6d337ea3 ... 0023:Call KERNEL32.CreateProcessW(00000000,0013a9c8 L"WMIC computersystem get model",00000000,00000000,00000001,00000000,00000000,00000000,0033eff0,0033f034) ret=68198ea3 ... wine: cannot find L"C:\\windows\\system32\\WMIC.exe" 0023:Ret KERNEL32.CreateProcessW() retval=00000000 ret=68198ea3 ... 0047:Call KERNEL32.CreateProcessA(00000000,005ef958 "cmd /C WMIC computersystem get manufacturer",00000000,00000000,00000001,08000400,00000000,00000000,0074e3e8,0074e42c) ret=6d337ea3 ... 0047:Call KERNEL32.CreateProcessA(00000000,005ef958 "cmd /C WMIC bios get serialnumber",00000000,00000000,00000001,08000400,00000000,00000000,0074e3e8,0074e42c) ret=6d337ea3 ... 0047:Call KERNEL32.CreateProcessA(00000000,005ef958 "cmd /C WMIC cpu get manufacturer",00000000,00000000,00000001,08000400,00000000,00000000,0074e3f8,0074e43c) ret=6d337ea3 ... --- snip --- Would be fine if Wine could provide a stub executable to silence this until real work on WMI starts one day ... (like Wine's "lodctr" for .NET stuff) Ideally the WMIC stub should print the command line passed to it using own debug channel ;-) Regards -- 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.

1 6

[Bug 13958] New: Services: handle null display names properly when populating SCM db entries
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=13958 Summary: Services: handle null display names properly when populating SCM db entries Product: Wine Version: 1.0-rc5 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P3 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, there is a bug in services code when one or more services have no display name set (null). If CreateServiceW() is called, it checks for existing services using scmdatabase_find_service_by_displayname(). Unfortunately this internal helper doesn't handle the "null" service name properly while iterating, resulting in exception and messy side effects (although mapped to rpc exception it isn't propagated properly). Following is service db dump with such cases: --- snip --- 000d:trace:service:scmdatabase_load_services Loading service L"BITS" 000d:trace:service:load_service_config Image path = L"svchost.exe -k netsvcs" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"BITS" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"MountMgr" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\drivers\\mountmgr.sys" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"Mount Manager" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"MSIServer" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\msiexec.exe /V" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"MSIServer" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"PnkBstrA" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\PnkBstrA.exe" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"PnkBstrA" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"PnkBstrB" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\PnkBstrB.exe" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"PnkBstrB" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"PnkBstrK" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\drivers\\PnkBstrK.sys" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"PnkBstrK" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"PROCMON13" 000d:trace:service:load_service_config Image path = L"\\??\\C:\\windows\\system32\\Drivers\\PROCMON13.SYS" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = (null) 000d:trace:service:load_service_config Display name = (null) 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"SecDrv" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\drivers\\\\SECDRV.SYS" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"SecDrv" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"Spooler" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\spoolsv.exe" 000d:trace:service:load_service_config Group = L"SpoolerGroup" 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"Print Spooler" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"VxD" 000d:trace:service:load_service_config Image path = (null) 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = (null) 000d:trace:service:load_service_config Display name = (null) 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) --- snip --- Quick fix: --- snip --- diff --git a/programs/services/services.c b/programs/services/services.c index 806fbb6..d48c985 100644 --- a/programs/services/services.c +++ b/programs/services/services.c @@ -341,7 +341,7 @@ struct service_entry *scmdatabase_find_service_by_displayname(struct scmdatabase LIST_FOR_EACH_ENTRY(service, &db->services, struct service_entry, entry) { - if (strcmpiW(name, service->config.lpDisplayName) == 0) + if (service->config.lpDisplayName && strcmpiW(name, service->config.lpDisplayName) == 0) return service; } --- snip --- Hopefully it's not too late for 1.0 ;-| Regards -- 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.

1 10

[Bug 18122] New: Add ability to force specific order of notes/howtos
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=18122 Summary: Add ability to force specific order of notes/howtos Product: WineHQ Apps Database Version: unspecified Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: appdb-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, I would like to see the ability to force the order of NOTES/HOWTOS. I experimented with deleting and re-adding notes or adding some number "prefix" in headline to force ordering but they still appear in some random order. This feature would improve readability as there are several appdb entries which contain a large number of notes/howtos and the most important ones should be displayed first. Regards -- 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.

1 9

[Bug 17076] New: Embedded .NET installer hangs in installation of SnelStart
by wine-bugs＠winehq.org 10 Oct '11

10 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=17076 Summary: Embedded .NET installer hangs in installation of SnelStart Product: Wine Version: 1.1.13 Platform: PC-x86-64 URL: http://www.snelstart.nl/Proberen/Proberen.aspx OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P3 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: Paul.Vriens.Wine(a)gmail.com (SnelStart is a Dutch Accounting Application) I'm running up-to-date GIT. When running 'wine SetupDemoSnelStart.exe' one sees that it downloads dotnetfx.exe (http://www.installengine.com/cert05/dotnetfx/dotnetfx.exe). After that there will be a 'InstallShield Wizard' window that keeps busy stating that it's configuring the .NET framework. 'ps -ef' shows: C:\windows\temp\{A4D5D16A-A0C9-4F8A-8929-F0B61C32EDEB}\dotnetfx.exe /q:a /ver:v1.1.4322 /redistui:S /c:/q:a /c:install /q /coreui:1033 I have no idea what logs to attach so please advise. -- 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.

1 10

[Bug 15258] New: It dosen't let me run the progamm
by wine-bugs＠winehq.org 10 Oct '11

10 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=15258 Summary: It dosen't let me run the progamm Product: Wine Version: unspecified Platform: All URL: http://www.g4hfq.co.uk OS/Version: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: wb0zur(a)arrl.net Hi I have a bug I think. This is for programming a Ham radio the program is FTB7800. The bug is Run-time error '451' Property let procedure not defined and property get procedure did not return an object. I am just fooling with Ubuntu 8.04 Any questions please ask. Denton Larson -- 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.

1 20

[Bug 21710] New: [regression] MotorM4X menu background image is not shown anymore
by wine-bugs＠winehq.org 10 Oct '11

10 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=21710 Summary: [regression] MotorM4X menu background image is not shown anymore Product: Wine Version: unspecified Platform: x86 URL: http://appdb.winehq.org/objectManager.php?sClass=versi on&iId=15060 OS/Version: Solaris Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: christian.thalinger(a)gmail.com CC: julliard(a)winehq.org Simply start the game and the menu background image is not there anymore. The failing changeset seems to be: $ git bisect bad 1aa749d9e7ee54f221373ccb2b47bcb31ef6533f is first bad commit commit 1aa749d9e7ee54f221373ccb2b47bcb31ef6533f Author: Alexandre Julliard <julliard(a)winehq.org> Date: Tue Oct 27 19:06:48 2009 +0100 libwine: Reserve some low memory space even without a preloader. :040000 040000 c6cbdf6fa3f40c287da32a6a3906d4d0ad7c5909 9fee74fb30f8b9bb7ccc3905c65607d13aabdf8b M libs -- 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.

1 13

[Bug 21144] New: cmd missing newline in output?
by wine-bugs＠winehq.org 10 Oct '11

10 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=21144 Summary: cmd missing newline in output? Product: Wine Version: 1.1.35 Platform: x86 URL: http://kegel.com/wine/cmdtest.tar.gz OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Even with Austin's recent patch http://www.winehq.org/pipermail/wine-patches/2009-December/083144.html applied, doing wget http://kegel.com/wine/cmdtest.tar.gz tar -xzvf cmdtest.tar.gz cd cmdtest sh cmdtest.sh shows that our cmd is missing a newline in its output: @@ -1,35 +1,22 @@ - -C:\fake>rem Easy cmd tests - ... +C:\fake>rem Easy cmd tests Looks like it needs to output another CRLF after the end of output of any command? -- 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.

1 8

[Bug 23113] New: winrar 3.93 installer displays garbage instead of licensing agreement
by wine-bugs＠winehq.org 10 Oct '11

10 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=23113 Summary: winrar 3.93 installer displays garbage instead of licensing agreement Product: Wine Version: 1.2-rc2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: shiningarcanine(a)gmail.com Created an attachment (id=28727) --> (http://bugs.winehq.org/attachment.cgi?id=28727) Console output from running winrar installer and copying license agreement. When I tried installing winrar 3.93 on my system, I saw a bunch of garbage where the license agreement should be. Copy and pasting the text to kwrite results in a readable license agreement appearing in kwrite. I am running KDE on Gentoo Linux. Here is console output from a command used on Gentoo Linux to describe how my system has been configured; I hope it is helpful: $ emerge wine --info Portage 2.1.8.3 (default/linux/x86/10.0, gcc-4.4.4, glibc-2.11.2-r0, 2.6.33.5 i686) ================================================================= System Settings ================================================================= System uname: Linux-2.6.33.5-i686-Genuine_Intel-R-_CPU_T2400_(a)_1.83GHz-with-gentoo-2.0.1 Timestamp of tree: Fri, 11 Jun 2010 02:30:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r2, 3.1.2-r3 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 virtual/os-headers: 2.6.34 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=prescott --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -march=prescott --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests buildpkg ccache distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -march=prescott --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -pipe -fomit-frame-pointer" GENTOO_MIRRORS="http://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ http://gentoo.netnitco.net http://distro.ibiblio.org/pub/linux/distributions/gentoo/" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/sunrise /var/lib/layman/vmware /var/lib/layman/java-overlay /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi alsa apm berkdb bzip2 cdr cleartype cli consolekit corefonts cracklib crypt cups cxx dbus dri dvd dvdr fftw fortran gd gdbm gif gnutls gpm hal iconv java java6 jpeg kde lzma midi mmap mmx mng modules mp3 mudflap ncurses networkmanager nls nptl nptlonly nsplugin opengl openmp pam pcre perl png pppd python qt3 qt3support qt4 readline reflection samba session spl sqlite sse sse2 sse3 ssl svg sysfs tcpd threads tiff truetype type1 unicode vorbis x264 x86 xml xorg xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" NETBEANS_MODULES="*" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= app-emulation/wine-1.2_rc2 was built with the following: USE="X alsa cups dbus fontconfig gecko gnutls hal jpeg lcms mp3 ncurses opengl perl png samba ssl threads truetype xml -capi -custom-cflags -esd -gphoto2 -gsm -jack -ldap -nas -openal -oss -pulseaudio -scanner -test -win64 -xcomposite -xinerama" CFLAGS="-O2 -march=prescott -pipe" CXXFLAGS="-O2 -march=prescott -pipe" -- 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.

1 21

[Bug 20364] New: The Dig (from STEAM) doesn't run on Arch Linux x86_64
by wine-bugs＠winehq.org 10 Oct '11

10 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=20364 Summary: The Dig (from STEAM) doesn't run on Arch Linux x86_64 Product: Wine Version: 1.1.31 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P3 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: A.Fettouhi(a)gmail.com Created an attachment (id=24125) --> (http://bugs.winehq.org/attachment.cgi?id=24125) Output from starting The Dig I'm trying to get The Dig working on wine. I'm talking about the version from STEAM. Until a few days ago I was running 32 bit Arch Linux and The Dig was working fine there in wine. I decided to switch to 64 bit finally and I've set up wine like I did on my 32 bit installation and The Dig won't start. The output is attached below. -- 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.

1 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs August 2010