Blizzard Updater Problem

[Erich Hoover]

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.

[Robert Shearman]

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

[Saulius Krasuckas]

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

[Robert Shearman]

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

[Erich Hoover]

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(a)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 );

[Mike Hearn]

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

[Saulius Krasuckas]

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.

[Erich Hoover]

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.