June 2001 - Wine-Devel - list.winehq.org

A pointer to some undoc functions

by Uwe Bonnes

Hallo, http://www.geocities.com/SiliconValley/4942/contents.html contains some explications about those undocumented functions in the win32 API mostly used bi explorer, iexplorer and friends. I took a look at the comctl32 MRU functions... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

June 24, 2001

[Problem report] X11DRV_GetDC

by Gerard Patel

This problem I see with Eudora (1.5 or 3.06 - I can't see it with Eudora 4 because it crashes before :-)). Using the option dialog box, everytime there is a checkbox or an option button, these buttons appear 2 times when switching from a page to another, one time at the correct place, one time off to the left. I think that the problem comes from the fact that the app paints outside of a WM_PAINT event. What happens is that when switching from a dialog 'page' to another, Eudora creates a hidden dialog with buttons on it, initialize the controls with the correct values from its config file, then reparent all the controls to the main dialog box. The hidden dialog box is a child of the main dialog box (but on this hidden dialog box, the controls are not at the place where they are supposed to be on the real dialog box). To be clearer, we have windows as follow (in the order parent->child) A : main dialog, style visible + clipsiblings B : work dialog, not visible + not clipsiblings C : a checkbox X11DRV_GetDC finds B as top window that is not clipsibling, then Wine use as drawable the parent of B : A. Then the checkbox is displayed somewhere on A. The following patch works around this particular problem, but I doubt that it's the best place to change. And, BTW, there are many other problems in current Cvs with my toy test suite :-/, problems that were not here a month ago, of course. To be fair the new code has removed *some* long standing problems, too. But on the balance it's still very bad. Gerard Index: dlls/x11drv/winpos.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/winpos.c,v retrieving revision 1.10 diff -u -r1.10 winpos.c --- dlls/x11drv/winpos.c 2001/06/22 03:42:27 1.10 +++ dlls/x11drv/winpos.c 2001/06/24 10:50:45 @@ -387,8 +387,11 @@ /* find the top parent in the hierarchy that isn't clipping siblings */ top = NULL; - for (ptr = win->parent; ptr && ptr->parent; ptr = ptr->parent) - if (!(ptr->dwStyle & WS_CLIPSIBLINGS)) top = ptr; + if (IsWindowVisible(win->hwndSelf)) + { + for (ptr = win->parent; ptr && ptr->parent; ptr = ptr->parent) + if (!(ptr->dwStyle & WS_CLIPSIBLINGS)) top = ptr; + } if (!top && !(flags & DCX_CLIPSIBLINGS)) top = win;

June 24, 2001

Re: PATCH: MSDOS VGA mode

by Marcus Meissner

On Fri, Jun 22, 2001 at 02:44:06PM +0200, Ove Kaaven wrote: > > On Fri, 22 Jun 2001, Marcus Meissner wrote: > > > Not really, I do see int9 delivered to monkey1.exe and monkey1.exe in turn > > doing inb(0x60) and the +io debugging giving back the correct scancode > > (0x1c on press and 0x9c on release). > > After reading the scancode, however, it determintes that it was not a > cursor key, so it passes it on to the DOS int9 handler for default > processing there. Then it expects the keypress to appear in the BIOS > keyboard buffer. I forgot I am also using the following additional patch (probably slightly incorrect for special keys): Index: dosvm.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/dosvm.c,v retrieving revision 1.6 diff -u -r1.6 dosvm.c --- dosvm.c 2001/05/14 20:09:38 1.6 +++ dosvm.c 2001/06/23 06:49:02 @@ -388,6 +388,7 @@ static void DOSVM_ProcessMessage(MSG *msg) { BYTE scan = 0; + BYTE xchar; TRACE_(int)("got message %04x, wparam=%08x, lparam=%08lx\n",msg->message,msg->wParam,msg->lParam); if ((msg->message>=WM_MOUSEFIRST)&& @@ -408,7 +409,8 @@ * should check for them */ INT_Int09SendScan(0xE0,0); } - INT_Int09SendScan(scan,0); + xchar = msg->wParam & 0xff; + INT_Int09SendScan(scan,xchar); break; } } This code is putting 0x0d/0x1c pairs into the keyboard buffer. > (You might have seen that if you also ran --debugmsg +int) I see those, and I see it appended to the keyboard buffer (even looking directly at the DOS image under /tmp/filexxxxx). However, monkey1.exe does not seem to read out this buffer, some keypresses later it is full. The BIOS data structures appear all ok. Trace snippet: trace:int:DOSVM_SendQueuedEvent dispatching IRQ 1 trace:int:DOSVM_SendQueuedEvent clearing Pending flag trace:int:IO_inport 1-byte value from port 0x60 trace:int:IO_inport returning ( 0x1c ) 0x60 < 1c @ 201a:1632 trace:int:DOSVM_SimulateInt builtin interrupt 09 has been branched to trace:int:INT_Int09Handler scan=1c fixme:int16:INT_Int16AddChar (0d,1c) fixme:int16:INT_Int16AddChar (0d,1c) at offset 30 trace:int:DOSVM_PIC_ioport_out received EOI for current IRQ, clearing trace:int:DOSVM_PIC_ioport_out another event pending, signalling dosmod trace:int:DOSVM_Process DOS module caught signal 12 trace:int:DOSVM_Process setting Pending flag, interrupts are currently enabled trace:int:DOSVM_SendQueuedEvent dispatching IRQ 1 trace:int:DOSVM_SendQueuedEvent clearing Pending flag trace:int:IO_inport 1-byte value from port 0x60 trace:int:IO_inport returning ( 0x9c ) 0x60 < 9c @ 201a:1632 trace:int:DOSVM_SimulateInt builtin interrupt 09 has been branched to trace:int:INT_Int09Handler scan=9c trace:int:DOSVM_PIC_ioport_out received EOI for current IRQ, clearing Very puzzling. > I think we managed to get monkey island to start by fixing that keyboard > code. However, because of that annoying wineserver assertion failure, no > DOS apps like this run with my code anymore, so I can't check. Unless you > want to fix the wineserver assertion at server/console.c line 194, so > CONSOLE_make_complex can run in one thread while another winedos thread > keeps waiting for input? I do not get that assertion? I get keyboard input directly from the DirectDraw window with above message loop. Ciao, Marcus

June 23, 2001

Re: wrc error

by Francois Gouget

On Sat, 23 Jun 2001, Bang Jun-Young wrote: [...] > I added a line to parser.y (r1.26) as follows: > > --- parser.y 2001/06/06 21:04:08 1.26 > +++ parser.y 2001/06/23 04:28:52 > @@ -423,6 +423,7 @@ > want_id = 1; > dont_want_id = 0; > } > + | resources tNL > ; > > After doing that, I could build Wine successfully again. I'll > send a complete patch including above comment to wine-patches > soon. Great. I must admit I did not have time to look into this. I tested your patch on my machine and Wine still compiles fine with bison, so you can probably post it to wine-patches. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

June 23, 2001

Re: Word97 problems

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 23 June 2001 12:46, Heiko Nardmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > I am still trying to get Word97 up and running. > > Now I found out that Word tries to LoadLibrary() some MSO7DEU.DLL which > seems to be the language DLL. I saw that after failing to find it it tries > to find MSO7ENU.DLL. When failing with that, too, some kind of exception is > happening according to the log files and the message box described in > former mails appears. > > So I took this DLL from my Windows/Word installation and copied it into the > same folder as Word. Now I have the following Word files in one directory: > > - - winword.exe > - - wwintl32.dll > - - mso97.dll > - - mso7deu.dll > > No other Windows files are on my Linux machine except on the NT partition > which is NOT used during this tests. > > After starting it again I now get a different message box saying that my > registry is corrupt and I should rerun Word setup. I will further analyze > the logfiles to see which registry entries are needed ... > > This analyze has been done with todays CVS ... > Hmm ... the new message box has a Ok button but I can't click on it. Nothing happens. No visual feedback. Okay then I tried to close it using the KDE close button. The message box disappears and Word appears after a few seconds. The first time seeing the message box I interrupted the whole thing with Ctrl-C. Some debug messages appear on the screen although I did not specify anything (see below). I was able to type a few characters. Selecting items in the menus worked fine, too. Trying to open a file results in some message box saying that I have not enough memory. Hmm ... Where is this L"HP2200" stuff coming from? Is wine somehow parsing the printcap? fixme:dc:GetDeviceCaps (0088,94): DeviceCaps param CAPS1 is UNIMPLEMENTED, will yield 0! fixme:dc:GetDeviceCaps (0088,94): unsupported DeviceCaps capability, will yield 0! fixme:dialog:MSGBOX_OnInit system modal msgbox ! Not modal yet. err:psdrv:PSDRV_AFMGetCharMetrics missing ;, failed. [C 0 ; WX 600 ; N null] err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 87 err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 87 err:psdrv:PSDRV_DeviceCapabilities16 no printerinfo for HP2200, return 0! err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 87 err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 87 err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 87 err:psdrv:PSDRV_DeviceCapabilities16 no printerinfo for HP2200, return 0! err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 87 err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL fixme:font:GetCharABCWidthsW (0a3c,00dc,00dc,0x405b54e4), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0031,0031,0x405b54f0), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,00dc,00dc,0x405b54e4), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0032,0032,0x405b54f0), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,00dc,00dc,0x405b54e4), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0033,0033,0x405b54f0), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0053,0053,0x405b54e4), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0064,0064,0x405b54f0), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0041,0041,0x405b54e4), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0074,0074,0x405b54f0), returns slightly bogus values. fixme:ole:CoRegisterMessageFilter stub fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL err:mmsys:MMDRV_InitHardcoded You didn't setup properly the config file for the Wine multimedia modules. Will use the hard-coded setup, but this will disapear soon. Please add a WinMM section to your Wine config file. fixme:string:EnumDateFormatsW (0x3013e860, 1031, 2): stub fixme:string:EnumDateFormatsW (0x3013e860, 7, 2): stub fixme:string:EnumDateFormatsW (0x3013e860, 1031, 2): stub fixme:string:EnumDateFormatsW (0x3013e8ab, 1031, 1): stub fixme:string:EnumDateFormatsW (0x3013e8ab, 7, 1): stub fixme:string:EnumDateFormatsW (0x3013e8ab, 1031, 1): stub fixme:string:EnumTimeFormatsW (0x3013e8c7,1031,0): stub fixme:string:EnumTimeFormatsW (0x3013e8c7,7,0): stub fixme:string:EnumTimeFormatsW (0x3013e8c7,1031,0): stub Created not existing system directory 'C:\My Documents' fixme:listview:LISTVIEW_Create ANSI notify format is NOT used fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL fixme:listview:LISTVIEW_Create ANSI notify format is NOT used server:truncated to 512 server:truncated to 1536 server:truncated to 2048 server:truncated to 2560 server:truncated to 3072 server:truncated to 3584 server:truncated to 4096 server:truncated to 4608 server:truncated to 5120 server:truncated to 5632 server:truncated to 6144 server:truncated to 6656 server:truncated to 10752 server:truncated to 11264 server:truncated to 15360 fixme:storage:StorageImpl_Commit (4): stub! fixme:storage:StorageImpl_Commit (4): stub! fixme:ole:WriteFmtUserTypeStg (0x403be1c0,c00e,L"Microsoft Word-Dokument") stub! fixme:storage:StorageImpl_SetElementTimes not implemented! fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7NI8vpm53PRScYygRAqEZAJ9sR0w1caE5M1Tk0TB2vLGWxdvGcgCg5pnZ z1iSvwUEGrsVFkP24F4ioYU= =Y5ao -----END PGP SIGNATURE-----

June 23, 2001

Re: Problems loading mingw32 binaries (latest CVS)

by Vedran Rodic

On Sat, Jun 23, 2001 at 01:18:35PM +0200, Vedran Rodic wrote: > Hello > > It seems that some recent change (post 20010510) prevents binaries made with > mingw32 (at least with my mingw32 linux cross-compiler) to load. > > The error message is: > err:module:map_image Could not map section .text, file probably truncated > wine: can't exec 'a.exe': error=21 > > I've put one such binary and the source at: > http://quark.fsb.hr/vedran/wine > > Debian wine version 0.0.20010510-3 loads the binary fine. Found the problem: unaligned_mmap() in memory/virtual.c It seems that this is one more problem that happens when using gcc -O3. gcc -O2 produces code that loads a.exe without problems. Strangely, gcc-3.0 -O3 works just fine too. So it just might be a bug in gcc 2.95.4. But, another thing, that program should make circle shaped window, but it makes a circle shaped window with upper and left edges cut a bit. I guess more bugs to chase:) Vedran

June 23, 2001

Re: Initializing Dosvm for direct port access

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> What about checking if Dosvm.GetTimer is initialized and if it isn't >> initialized do give back the dummy value? At least the spde doesn't >> seem to care... Alexandre> How does the app behave under NT? Or with -winver nt40? With --winver nt40 the application tells about some unavailable VXDs. However I didn't bother to install the application with --winver nt40 ... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

June 23, 2001

Problems loading mingw32 binaries (latest CVS)

by Vedran Rodic

Hello It seems that some recent change (post 20010510) prevents binaries made with mingw32 (at least with my mingw32 linux cross-compiler) to load. The error message is: err:module:map_image Could not map section .text, file probably truncated wine: can't exec 'a.exe': error=21 I've put one such binary and the source at: http://quark.fsb.hr/vedran/wine Debian wine version 0.0.20010510-3 loads the binary fine. Vedran Rodic

June 23, 2001

Word97 problems

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I am still trying to get Word97 up and running. Now I found out that Word tries to LoadLibrary() some MSO7DEU.DLL which seems to be the language DLL. I saw that after failing to find it it tries to find MSO7ENU.DLL. When failing with that, too, some kind of exception is happening according to the log files and the message box described in former mails appears. So I took this DLL from my Windows/Word installation and copied it into the same folder as Word. Now I have the following Word files in one directory: - - winword.exe - - wwintl32.dll - - mso97.dll - - mso7deu.dll No other Windows files are on my Linux machine except on the NT partition which is NOT used during this tests. After starting it again I now get a different message box saying that my registry is corrupt and I should rerun Word setup. I will further analyze the logfiles to see which registry entries are needed ... This analyze has been done with todays CVS ... - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7NHOhpm53PRScYygRAq7CAJ0YjojtnRdiX5OthOvPEkN4MUY1ugCbB+3e b3QaEHg3OaBl8c0yn0cRKpg= =nMdS -----END PGP SIGNATURE-----

June 23, 2001

Re: wrc error

by Bang Jun-Young

On Fri, Jun 15, 2001 at 08:09:54AM -0700, Francois Gouget wrote: > I wanted a preprocessed version of the user32.rc file. But Bang > Jun-Young sent me the files generated by flex/bison which allowed me to > reproduce the problem. I have not yet found a fix but the problem is in > the y.tab.c file. > > Bang Jun-Young is using byacc while I'm using bison so the files are > quite different and about impossible to compare. When I compile > parser.y I get: > > bison -y -d -t ./parser.y > conflicts: 2 shift/reduce I get the same warning with byacc. > Maybe that's the source of the problem: byacc resolves the conflicts > differently from bison which causes tehe parse to fail. Now I think I have found the reason. It was due to a bug in byacc. From parser.y of revision 1.25: | tNL /* * This newline rule will never get reduced because we never * get the tNL token, unless we explicitely set the 'want_nl' * flag, which we don't. * The *ONLY* reason for this to be here is because Berkeley * yacc (byacc), at least version 1.9, has a bug. * (identified in the generated parser on the second * line with: * static char yysccsid[] = "@(#)yaccpar 1.9 (Berkeley) 02/21/93"; * ) * This extra rule fixes it. * The problem is that the expression handling rule "expr: xpr" * is not reduced on non-terminal tokens, defined above in the * %token declarations. Token tNL is the only non-terminal that * can occur. The error becomes visible in the language parsing * rule below, which looks at the look-ahead token and tests it * for tNL. However, byacc already generates an error upon reading * the token instead of keeping it as a lookahead. The reason * lies in the lack of a $default transition in the "expr : xpr . " * state (currently state 25). It is probably ommitted because tNL * is a non-terminal and the state contains 2 s/r conflicts. The * state enumerates all possible transitions instead of using a * $default transition. * All in all, it is a bug in byacc. (period) */ I added a line to parser.y (r1.26) as follows: --- parser.y 2001/06/06 21:04:08 1.26 +++ parser.y 2001/06/23 04:28:52 @@ -423,6 +423,7 @@ want_id = 1; dont_want_id = 0; } + | resources tNL ; After doing that, I could build Wine successfully again. I'll send a complete patch including above comment to wine-patches soon. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

June 23, 2001