Subject: Wine-941017 _still_ doesn't work for me. How about you?
To: None <katsura@prc.tsukuba.ac.jp, port-i386@netbsd.org,>
From: John Kohl <jtk@kolvir.blrc.ma.us>
List: port-i386
Date: 10/25/1994 23:42:10
Hi folks,
wine-941017 still doesn't work for me.
Katsuragawa Naoki san, you said in a posting to
comp.emulators.ms-windows.wine that you had it working just fine under
NetBSD-1.0 and XFree86-3.1 by #define'ing sc_efl to sc_eflags and
whacking the #include statements in dos_fs.c. I have at NetBSD-1.0
(supped yesterday), but wine-941017 doesn't work for me. Are you
running the final 1.0 bits? (it sounds like you are, but I want to be
sure). My kernel says:
# uname -a
NetBSD kolvir 1.0 NetBSD 1.0 (KOLVIR) #53: Tue Oct 25 00:18:50 EDT 1994 jtk@kolvir:/u1/NetBSD-1.0/src/sys/arch/i386/compile/KOLVIR i386
What type of processor do you have? Genuine Intel, or a clone? 386,
486, P5? what speed? [I don't think any of these should make a
difference, but there must be *something* different between our machines
that's relevant]. I have a real Intel 486/33.
I've built with 'gmake MAKE=gmake', as the README sort-of suggests.
[Otherwise I get problems with WINESTAT being defined or not defined--I
don't understand yet why the BSD pmake builds are broken but GNU make
works OK?] I tried building as 'gmake CDEBUGFLAGS= MAKE=gmake', but
that didn't alter the brokenness.
The lossage for sol.exe is:
...
InitializeLoadedDLLs 00126AC0
InitializeLoadedDLLs 00000000
Initializing DLLs
Initializing sysres, cs:ip 00c7:0000, ds 00cf
rv = 1
Segmentation fault in Wine program (1f:1016c541). Please debug
In win_fault 1f:1016c541
In 16 bit mode.
Reading symbols from file wine.sym
Removing BPs
0xffffff82(_end+0xffee2332): Address 0xffffff82 is out of bounds.
Wine-dbg>x/i $pc
0x009fff82(_end+0x8e2332): orw (%bx,%si),%ax
Wine-dbg>info reg
Register dump:
CS:ffffffff SS:0000 DS:320000 ES:6f5a4 GS:0027 FS:0027
EIP:0000ff82 ESP:00000027 EBP:00000027 EFLAGS:f7bfd85e
EAX:000018e0 EBX:00000246 ECX:00000027 EDX:0000d832
EDI:0000c541 ESI:0000001f
If I run it under gdb, I get the same old "strlen" bug:
(gdb) handle 10 nostop
(gdb) handle 10 noprint
Signal Stop Print Pass to program Description
SIGBUS (10) No No Yes Bus error
(gdb) run
Starting program: /u1/src/wine941017/wine -relaydbg /msdos/windows/sol.exe
...
Program received signal SIGSEGV (11), Segmentation fault
0x1016c541 in strlen ()
(gdb) where
#0 0x1016c541 in strlen ()
#1 0xd706b8 in end ()
#2 0xccf5 in DLLRelay ()
#3 0xbf79 in CallTo32 ()
#4 0x3b327 in StartNEprogram ()
#5 0x3a063 in _WinMain ()
#6 0x4c5b1 in main ()
#7 0x100b0060 in end ()
#8 0xf7bfdcc5 in end ()
#9 0x2f6c6961 in end ()
Error accessing memory address 0x6d2f7261: Operation not permitted.
(gdb) x/i $pc
0x1016c541 <strlen+13>: repnz scasb %ds:(%esi),%al
When I put in the 940912 patch from Christos Zoulas to adjust the stack
offsets for certain calls in relay.c, sol.exe works enough to start
spewing infinite loop garbage:
...
InitializeLoadedDLLs 00000000
Initializing DLLs
Initializing sysres, cs:ip 00c7:0000, ds 00cf
rv = 1
MessageBox(0714, 009FFEA4='Not enough memory to display card faces when cards move. Outline dragging has been enabled.', 009F04DA='Solitaire', 0030)
MessageBox // before RegisterClass, 'Not enough memory to display card faces when cards move. Outline dragging has been enabled.' 'Solitaire' !
MessageBox WM_CREATE hWnd=0E64 !
MessageBox WM_CREATE title='Solitaire' str='Not enough memory to display card faces when cards move. Outline dragging has been enabled.' !
MsgBox LoadIcon Exclamation !
MessageBox WM_SHOWWINDOW hWnd=0E64 !
MessageBox // before Msg Loop !
MessageBox WM_PAINT hWnd=0E64 !
MessageBox WM_PAINT // BeginPaint returned BAD hDC !
BeginPaint not called on WM_PAINT for hwnd 3684!
MessageBox WM_PAINT hWnd=0E64 !
MessageBox WM_PAINT // BeginPaint returned BAD hDC !
BeginPaint not called on WM_PAINT for hwnd 3684!
... and on and on ...
With that patch, winmine.exe works enough to paint its initial window, and
it then croaks im memcpy().
I can't ever get a backtrace from the built-in debugger (it seems to
loop forever just after printing "0 " for the first frame).
So, how did you get things working?
==John