I haven't been able to get the blizzard updater to run on recent versions of wine (I've downloaded from CVS to make sure there isn't a fix). I'm not sure if this is something wrong with my setup or a bug with wine (i recently reinstalled my system with Fedora Core 2 and am no-longer running the same version of wine). I'm executing programs with "setarch i386 wine <appname>" but the blizzard updater seems hosed (though Diablo II and Warcraft III run fine). It appears that the updater doesn't launch correctly (i'm guessing because of the setarch stuff) so I run the updater manually by typing "setarch i386 wine BNupdate.exe" and I get this:
fixme:msvcrt:_XcptFilter (-1073741819,0x5584f76c)semi-stub wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x55609ec4,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x558fc91c). In 32 bit mode. 0x558fc91c: movl $0x0,0x0(%eax) Wine-dbg>quit WineDbg terminated on pid 0x8
At which point I have to type quit to close the debugger (as you can see). Any help would be greatly appreciated, if you need more information just send me a message.
Erich Hoover wrote:
I haven't been able to get the blizzard updater to run on recent versions of wine (I've downloaded from CVS to make sure there isn't a fix). I'm not sure if this is something wrong with my setup or a bug with wine (i recently reinstalled my system with Fedora Core 2 and am no-longer running the same version of wine).
More likely a change in Wine caused the app to fail.
I'm executing programs with "setarch i386 wine <appname>" but the blizzard updater seems hosed (though Diablo II and Warcraft III run fine). It appears that the updater doesn't launch correctly (i'm guessing because of the setarch stuff) so I run the updater manually by typing "setarch i386 wine BNupdate.exe" and I get this:
I assume other programs run correctly, e.g notepad?
fixme:msvcrt:_XcptFilter (-1073741819,0x5584f76c)semi-stub wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x55609ec4,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x558fc91c). In 32 bit mode. 0x558fc91c: movl $0x0,0x0(%eax) Wine-dbg>quit WineDbg terminated on pid 0x8
At which point I have to type quit to close the debugger (as you can see). Any help would be greatly appreciated, if you need more information just send me a message.
A backtrace would be useful. Instead of typing "quit" type "bt"
Rob
On Sun, 6 Jun 2004, Robert Shearman wrote:
Erich Hoover wrote:
I haven't been able to get the blizzard updater to run on recent versions of wine (I've downloaded from CVS to make sure there isn't a fix). I'm not sure if this is something wrong with my setup or a bug with wine (i recently reinstalled my system with Fedora Core 2 and am no-longer running the same version of wine).
More likely a change in Wine caused the app to fail.
AFAICS this case may be related to already known issue [1].
The bug is still present in the CVS. If it's the same bug I urge to reverse this patch [2] (if compiling by yourself) or just use Wine version prior to the date "2004/04/19 23:02:35". For me reversing [2] patch worked out fine.
[1] http://bugs.winehq.org/show_bug.cgi?id=2210 [2] http://cvs.winehq.org/patch.py?id=12071
On Sun, 2004-06-06 at 16:14, Saulius Krasuckas wrote:
On Sun, 6 Jun 2004, Robert Shearman wrote:
Erich Hoover wrote:
I haven't been able to get the blizzard updater to run on recent versions of wine (I've downloaded from CVS to make sure there isn't a fix). I'm not sure if this is something wrong with my setup or a bug with wine (i recently reinstalled my system with Fedora Core 2 and am no-longer running the same version of wine).
More likely a change in Wine caused the app to fail.
AFAICS this case may be related to already known issue [1].
The bug is still present in the CVS. If it's the same bug I urge to reverse this patch [2] (if compiling by yourself) or just use Wine version prior to the date "2004/04/19 23:02:35". For me reversing [2] patch worked out fine.
[1] http://bugs.winehq.org/show_bug.cgi?id=2210 [2] http://cvs.winehq.org/patch.py?id=12071
Does the attached patch work for you?
Rob
I've actually seen the old thread but my problem appeared to be different, I applied the patch and recompiled with no success (I believe I did it appropriately, it manually requested the filenames). Here is the requested bt output:
[ehoover@FEDORA Diablo II]$ setarch i386 wine BNupdate.exe fixme:msvcrt:_XcptFilter (-1073741819,0x5584f76c)semi-stub wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x55609ec4,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x558fc8e4). In 32 bit mode. 0x558fc8e4: movl $0x0,0x0(%eax) Wine-dbg>bt Backtrace: =>1 0x558fc8e4 (0x5584fc20) 2 0x558fcd6b (0x5584fc44) 3 0x558fcd96 (0x5584fc68) 4 0x558fccea (0x5584fc8c) 5 0x004070d6 (0x5584ff2c) 6 0x554af3e7 (0x5584fff4) 7 0x5502d525 (0x00000000) Wine-dbg>
I didn't get the message:
0x408ba2e0 (DIALOG_CreateIndirect+0x300 [dialog.c:636] in USER32.DLL):
so I assumed my problem might be different.
Robert Shearman wrote:
On Sun, 2004-06-06 at 16:14, Saulius Krasuckas wrote:
On Sun, 6 Jun 2004, Robert Shearman wrote:
Erich Hoover wrote:
I haven't been able to get the blizzard updater to run on recent versions of wine (I've downloaded from CVS to make sure there isn't a fix). I'm not sure if this is something wrong with my setup or a bug with wine (i recently reinstalled my system with Fedora Core 2 and am no-longer running the same version of wine).
More likely a change in Wine caused the app to fail.
AFAICS this case may be related to already known issue [1].
The bug is still present in the CVS. If it's the same bug I urge to reverse this patch [2] (if compiling by yourself) or just use Wine version prior to the date "2004/04/19 23:02:35". For me reversing [2] patch worked out fine.
[1] http://bugs.winehq.org/show_bug.cgi?id=2210 [2] http://cvs.winehq.org/patch.py?id=12071
Does the attached patch work for you?
Rob
Index: wine/dlls/user/controls.h
RCS file: /home/wine/wine/dlls/user/controls.h,v retrieving revision 1.15 diff -u -r1.15 controls.h --- wine/dlls/user/controls.h 4 Mar 2004 01:41:11 -0000 1.15 +++ wine/dlls/user/controls.h 6 Jun 2004 17:56:17 -0000 @@ -134,11 +134,7 @@ /* offset of DIALOGINFO ptr in dialog extra bytes */ #define DWL_WINE_DIALOGINFO (DWL_USER+sizeof(ULONG_PTR))
-inline static DIALOGINFO *DIALOG_get_info( HWND hwnd ) -{
- return (DIALOGINFO *)GetWindowLongW( hwnd, DWL_WINE_DIALOGINFO );
-}
+extern DIALOGINFO* DIALOG_get_info(HWND hwnd); extern BOOL DIALOG_GetCharSize( HDC hdc, HFONT hFont, SIZE * pSize ); extern void DIALOG_EnableOwner( HWND hOwner ); extern BOOL DIALOG_DisableOwner( HWND hOwner ); Index: wine/windows/defdlg.c =================================================================== RCS file: /home/wine/wine/windows/defdlg.c,v retrieving revision 1.31 diff -u -r1.31 defdlg.c --- wine/windows/defdlg.c 20 Apr 2004 04:02:35 -0000 1.31 +++ wine/windows/defdlg.c 6 Jun 2004 17:56:18 -0000 @@ -284,26 +284,19 @@ }
/*********************************************************************** -* DEFDLG_InitDlgInfo +* DIALOG_get_info
-* Allocate memory for DIALOGINFO structure and store in DWL_DIALOGINFO -* structure. Also flag the window as a dialog type. +* Returns the data structure associated with the dialog. +* Allocates memory for DIALOGINFO structure and stores in DWL_DIALOGINFO +* structure and flags the window as a dialog type if not already done. */ -static DIALOGINFO* DEFDLG_InitDlgInfo(HWND hwnd) +DIALOGINFO* DIALOG_get_info(HWND hwnd) { WND* wndPtr;
- DIALOGINFO* dlgInfo = DIALOG_get_info( hwnd );
- DIALOGINFO* dlgInfo = (DIALOGINFO *)GetWindowLongW( hwnd, DWL_WINE_DIALOGINFO ); if(!dlgInfo) {
if (!(dlgInfo = HeapAlloc( GetProcessHeap(), 0, sizeof(*dlgInfo) ))) return NULL;
dlgInfo->hwndFocus = 0;
dlgInfo->hUserFont = 0;
dlgInfo->hMenu = 0;
dlgInfo->xBaseUnit = 0;
dlgInfo->yBaseUnit = 0;
dlgInfo->idResult = 0;
dlgInfo->flags = 0;
dlgInfo->hDialogHeap = 0;
if (!(dlgInfo = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*dlgInfo) ))) return NULL; wndPtr = WIN_GetPtr( hwnd ); if (wndPtr && wndPtr != WND_OTHER_PROCESS) {
@@ -332,7 +325,7 @@ BOOL result = FALSE;
/* Perform DIALOGINFO intialization if not done */
- if(!(dlgInfo = DEFDLG_InitDlgInfo(hwnd32))) return -1;
if(!(dlgInfo = DIALOG_get_info(hwnd))) return -1;
SetWindowLongW( hwnd32, DWL_MSGRESULT, 0 );
@@ -389,7 +382,7 @@ BOOL result = FALSE;
/* Perform DIALOGINFO initialization if not done */
- if(!(dlgInfo = DEFDLG_InitDlgInfo(hwnd))) return -1;
if(!(dlgInfo = DIALOG_get_info(hwnd))) return -1;
SetWindowLongW( hwnd, DWL_MSGRESULT, 0 );
@@ -446,7 +439,7 @@ WNDPROC dlgproc;
/* Perform DIALOGINFO intialization if not done */
- if(!(dlgInfo = DEFDLG_InitDlgInfo(hwnd))) return -1;
if(!(dlgInfo = DIALOG_get_info(hwnd))) return -1;
SetWindowLongW( hwnd, DWL_MSGRESULT, 0 );
On Sun, 06 Jun 2004 14:49:05 -0600, Erich Hoover wrote:
Wine-dbg>bt Backtrace: =>1 0x558fc8e4 (0x5584fc20) 2 0x558fcd6b (0x5584fc44) 3 0x558fcd96 (0x5584fc68) 4 0x558fccea (0x5584fc8c) 5 0x004070d6 (0x5584ff2c) 6 0x554af3e7 (0x5584fff4) 7 0x5502d525 (0x00000000) Wine-dbg>
All this backtrace means is that somehow despite compiling from source, you have a stripped build. Try downloading CVS, applying Robs patch, and trying again.
thanks -mike
On Sun, 6 Jun 2004, Robert Shearman wrote:
On Sun, 2004-06-06 at 16:14, Saulius Krasuckas wrote:
For me reversing [2] patch worked out fine.
[1] http://bugs.winehq.org/show_bug.cgi?id=2210 [2] http://cvs.winehq.org/patch.py?id=12071
Does the attached patch work for you?
Rob
Yes, Rob, it works fine for me. Thanks.
After redownloading from CVS (I downloaded that way originally), patching, and compiling it worked great - thanks! This time I compiled it 'manually' instead of running the ./tools/wineinstall script - I'm assuming that script sets the "stripped" mode that screwed me up before. Again, thanks for the patch!
Saulius Krasuckas wrote:
On Sun, 6 Jun 2004, Robert Shearman wrote:
On Sun, 2004-06-06 at 16:14, Saulius Krasuckas wrote:
For me reversing [2] patch worked out fine.
[1] http://bugs.winehq.org/show_bug.cgi?id=2210 [2] http://cvs.winehq.org/patch.py?id=12071
Does the attached patch work for you?
Rob
Yes, Rob, it works fine for me. Thanks.