wine-bugs April 2013

wine-bugs@winehq.org

1 participants
9368 discussions

[Bug 27431] New: GetModuleFileNameW behaves unexpectedly when applications use a hardcoded hmodule=0x10000000
by wine-bugs＠winehq.org 22 Nov '14

22 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=27431 Summary: GetModuleFileNameW behaves unexpectedly when applications use a hardcoded hmodule=0x10000000 Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: rswarbrick(a)gmail.com Created an attachment (id=35079) --> (http://bugs.winehq.org/attachment.cgi?id=35079) Log file as described in the report SUMMARY: ======== Some code stupidly assumes that the hModule parameter describing the current exe is always 0x10000000. On my system, at least, this isn't true. The software then fails to work properly when it calls GetModuleFileName. WHAT I FOUND / TO REPRODUCE: ============================ I'm trying to get the Onzo energy meter software [1] working and was confused by messages like: 12:55:57: Debug: src/helpers.cpp(140): 'CreateActCtx' failed with error 0x0000007b (no more data available). appearing on the stderr. It turns out that this is a wxPython message from a failing call to CreateActCtx. The Onzo software is closed-source, but the code in helpers.cpp that's calling CreateActCtx is probably what you get from downloading something at [2]. In particular, it might well be the following: static ULONG_PTR wxPySetActivationContext() { OSVERSIONINFO info; wxZeroMemory(info); info.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); GetVersionEx(&info); if (info.dwMajorVersion < 5) return 0; ULONG_PTR cookie = 0; HANDLE h; ACTCTX actctx; TCHAR modulename[MAX_PATH]; GetModuleFileName(wxGetInstance(), modulename, MAX_PATH); wxZeroMemory(actctx); actctx.cbSize = sizeof(actctx); actctx.lpSource = modulename; actctx.lpResourceName = MAKEINTRESOURCE(2); actctx.hModule = wxGetInstance(); actctx.dwFlags = ACTCTX_FLAG_HMODULE_VALID | ACTCTX_FLAG_RESOURCE_NAME_VALID; h = CreateActCtx(&actctx); if (h == INVALID_HANDLE_VALUE) { wxLogLastError(wxT("CreateActCtx")); return 0; } if (! ActivateActCtx(h, &cookie)) wxLogLastError(wxT("ActivateActCtx")); return cookie; } After staring at debug logs for a bit, I realised that GetModuleFileName was storing "" into modulename and returning 0. Note the bullet-proof code in wxPython checking whether this happens... Anyway, I then instrumented GetModuleFileName to find out what was going on (in a rather low-tech way) adding a line fprintf (stderr, "hmodule = %p; lpFN = %p; size = %d\n", hModule, lpFileName, size); near the start of the function and, once I'd realised that it was LdrFindEntryForAddress that failed, also printing out a line of the form fprintf (stderr, "nts = %x\n", nts); just after it was called. The resulting debug log included lines looking like this: hmodule = 0x10000000; lpFN = 0x32daa0; size = 260 and it seems that wxGetInstance() is stupidly returning 0x10000000, which I recognise from my 1990's Windows-using days and think is what you always used to get, so maybe it's hardcoded somewhere. This is presumably either in wxPython or in Onzo's code (the wxGetInstance() basically just returns the value of a global variable that can be changed by wxSetInstance(), I think). I'm going to attach a log that I created using this slightly-instrumented wine build with the command WINEDEBUG=+actctx,+file,+module /opt/wine/bin/wine onzo_uploader.exe 2>~/LOG The lines I'm talking about are just above line 13630. The extra "Address ranges searched" lines come from slightly instrumenting LdrFindEntryForAddress: NTSTATUS WINAPI LdrFindEntryForAddress(const void* addr, PLDR_MODULE* pmod) { PLIST_ENTRY mark, entry; PLDR_MODULE mod; fprintf (stderr, "Address ranges searched:\n"); mark = &NtCurrentTeb()->Peb->LdrData->InMemoryOrderModuleList; for (entry = mark->Flink; entry != mark; entry = entry->Flink) { mod = CONTAINING_RECORD(entry, LDR_MODULE, InMemoryOrderModuleList); fprintf (stderr, " %p -> %p\n", mod->BaseAddress, mod->BaseAddress + mod->SizeOfImage); ...}} which I did to check my guess was right about the base address being nonsense. IDEAS FOR FIXING ================ I'm not sure what the correct way to go about fixing this is. I suppose one thing is to check that this really is due to Onzo/wxPython doing something stupid rather than Wine telling their software an incorrect base address somewhere else. I'm not quite sure how to go about doing that. If it is just a hard-coding that actually works on Windows (I presume that Windows's ASLR doesn't mess it up?), maybe LdrFindEntryForAddress needs to hardcode its answer for 0x10000000? But that's really really horrible... Ideas?? Rupert [1] http://download.sse.co.uk/OnzoDownloader/onzo_uploader_latest.msi [2] http://www.wxpython.org/download.php -- 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 24675] New: Civilization V shows terrain and units in grey when using low overlay quality
by wine-bugs＠winehq.org 22 Nov '14

22 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=24675 Summary: Civilization V shows terrain and units in grey when using low overlay quality Product: Wine Version: 1.3.4 Platform: x86-64 OS/Version: Mac OS X 10.6 Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: mikko.ronkko(a)iki.fi Created an attachment (id=31190) --> (http://bugs.winehq.org/attachment.cgi?id=31190) Output to console The game video options has a setting "overlay quality". This has three options: high, medium, and low. If low is chosen, all units and terrain are grey making the game completely unplayable. -- 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 18227] New: HL2 Ep2 / Portal: Massive slowdown in some areas
by wine-bugs＠winehq.org 22 Nov '14

22 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=18227 Summary: HL2 Ep2 / Portal: Massive slowdown in some areas Product: Wine Version: 1.1.20 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: liquid.acid(a)gmx.net Entering certain areas in Portal or HL2 Ep2 lets the game slow down big time. The slowdown is accompanied with these FIXMEs: fixme:d3d_surface:surface_load_ds_location (0x1587a8) Not supported with fixed up depth stencil fixme:d3d:fixed_get_input Unsupported input stream [usage=WINED3DDECLUSAGE_POSITION, usage_idx=1] fixme:d3d:fixed_get_input Unsupported input stream [usage=WINED3DDECLUSAGE_NORMAL, usage_idx=1] I suspect this is triggering by the game trying to use vertex tweening. -- 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 18137] New: Checkpoint installer dies when running fwkern.exe
by wine-bugs＠winehq.org 22 Nov '14

22 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=18137 Summary: Checkpoint installer dies when running fwkern.exe Product: Wine Version: 1.1.19 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: ashogunnamedmarcus(a)yahoo.com Created an attachment (id=20593) --> (http://bugs.winehq.org/attachment.cgi?id=20593) Entire checkpoint install log file Checkpoint VPN client does not successfully complete installation. I checked out the install log, things seem to be going well until the installer attempts to run 'fwkern.exe'. This results in errors like "Failed to INetCfg" and dumps. I've attached the whole damn log which includes a few install attempts. Thanks and let me know if I can be any help. -- 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 10382] New: Tribes 2: must double-tap for in game chat
by wine-bugs＠winehq.org 22 Nov '14

22 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=10382 Summary: Tribes 2: must double-tap for in game chat Product: Wine Version: 0.9.48. Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: wine-directx-dinput AssignedTo: wine-bugs(a)winehq.org ReportedBy: spock128(a)gmail.com When in game, the chat keys must be pressed twice after the first use. For example, I can press 'u' (global chat) once to bring up a text entry box to say something in the global channel (correct operation). After that, I must hit 'u' twice to bring up the text entry box. In-game console shows the error: DInputDevice::syncKeyboardState - DIERR_INVALIDPARAM Switching out of the game window and back will reset the condition - it works for first use then must hit twice. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 20

[Bug 33237] New: Sony Acid Xpress 7.0a: Fails to install
by wine-bugs＠winehq.org 22 Nov '14

22 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=33237 Bug #: 33237 Summary: Sony Acid Xpress 7.0a: Fails to install Product: Wine Version: 1.5.26 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: gaming4jc2(a)yahoo.com Classification: Unclassified Created attachment 43957 --> http://bugs.winehq.org/attachment.cgi?id=43957 BackTrace When attempting to install the latest version of the free Sony Acid Xpress 7.0a it starts directly to the debugger. Backtrace 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 5

[Bug 24480] New: File handles keep open after PowerPoint 2007 is closed
by wine-bugs＠winehq.org 22 Nov '14

22 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=24480 Summary: File handles keep open after PowerPoint 2007 is closed Product: Wine Version: 1.3.1 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: m.duelli(a)web.de When working with PowerPoint 2007 on files which are stored on a USB stick, you cannot cleanly unmount the USB stick after closing PowerPoint since it complains about open file handles. Workaround: You have to kill the wineserver such that all file handles are closed. -- 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 14764] New: MissionForce Cyberstorm demo crashes on startup
by wine-bugs＠winehq.org 22 Nov '14

22 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=14764 Summary: MissionForce Cyberstorm demo crashes on startup Product: Wine Version: CVS/GIT Platform: PC URL: http://www.fileplanet.com/11494/10000/fileinfo/MissionFo rce:-CyberStorm OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Created an attachment (id=15274) --> (http://bugs.winehq.org/attachment.cgi?id=15274) +relay,+seh,+tid Crashes on startup. +relay,+seh,+tid 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 12

[Bug 11727] New: Mouse button events generated by a window' s app are not propagated to X server
by wine-bugs＠winehq.org 22 Nov '14

22 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=11727 Summary: Mouse button events generated by a window's app are not propagated to X server Product: Wine Version: 0.9.56. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: gideon.wine(a)gmail.com Created an attachment (id=10969) --> (http://bugs.winehq.org/attachment.cgi?id=10969) Patch to send mouse button events to the X server winex11.drv uses XWarpPointer to send mouse movements to the X server. Mouse button events are not sent. If a pointing device device communicates directly with a windows app running in wine, the user will be able to move the mouse pointer, but button presses will only work on windows controlled by wine. The attached patch adds calls to send mouse button events generated by a windows application to the X server. The way this is done is similar to the way it is done in the Synergy client - by using XTestFakeButtonEvent (see http://synergy2.sourceforge.net/). Requires libXtst. This bug might also resolve bug 7032. -- 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 32

[Bug 28020] New: winepath -w should also look into user folders (Desktop, Music, etc), not just dosdevices
by wine-bugs＠winehq.org 22 Nov '14

22 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=28020 Summary: winepath -w should also look into user folders (Desktop, Music, etc), not just dosdevices Product: Wine Version: unspecified Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: wine(a)rodrigosilva.com Currently, winepath -w (seems to) only search for symlinks in $WINEPREFIX/dosdevices to map a given native path to a windows one. But it should also look for user folder's symlinks (like Desktop, My Music, My Pyctures, etc) This is specially helpful if a given prefix has removed the "catch all" Z: => / mapping. In that case, winepath is mapping my "~/Desktop" to "\\?\unix\...", but it could be "smarter" and map it to "C:\users\rodrigo\Desktop" instead. Last but not least, a related limitation is the lack of winepath -u to understand windows env variables, like %USERPROFILE%. That usually points to C:\users\$USER , but since that can be changed in registry, a "windows enviroment-aware winepath -u" would be truly useful. -- 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

Jump to page:

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 April 2013