May 2010 - Wine-bugs - list.winehq.org

[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 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 15945] New: WinSnap can't capture screen.
by wine-bugs＠winehq.org 10 Oct '11

10 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=15945 Summary: WinSnap can't capture screen. Product: Wine Version: 1.1.7 Platform: PC URL: http://www.ntwind.com/software/winsnap.html OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: vladimiroski(a)gmail.com WinSnap start without critical errors but it seems that it can't capture the screen. Option to "edit in paint" ("Tools" menu or "Alt+2") does not work too, complains about it can't write to disk. Btw, I saw this line in console while executing /WinSnap/WinSnap.exe: err:toolbar:TOOLBAR_GetImageListForDrawing bitmap for ID 0, index 0 is not valid, number of bitmaps in imagelist: 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 10

[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