- Wine-Devel - list.winehq.org

DLL separation and PROFILE functions
by Ian Pilcher May 16, 2001

May 16, 2001

DLL separation has been mentioned quite a few times on this list (usually as the ultimate solution to a problem), but I don't think I've ever seen it actually defined. Based on my own misadventures in this area, however, I would hazard a guess that is essentially the conversion of all inter-DLL function calls from OS-based dynamic linking to the Wine DLL loading mechanism. Under this assumption, adding 'IMPORTS = ntdll' to a DLL's Makefile.in file (in order to use one of the PROFILE functions) seems like a definite step backwards. I think that the proper approach is to add the function in question to dlls/ntdll/ntdll.spec and make sure that the importing DLL lists ntdll.dll as an import in its own SPEC file. All of which is wonderful until you consider the following in ntdll.spec: ################## # Wine extensions # # All functions must be prefixed with '__wine_' (for internal functions) # or 'wine_' (for user-visible functions) to avoid namespace conflicts. This would seem to indicate that the PROFILE functions (in files/profile.c) need to have their names changed before they are exported. Is this an appropriate time to go crazy with grep and sed? (For example, PROFILE_EnumWineIniString would become __wine_EnumIniString.) -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

2 1

Re: Crash in MSG_PeekHardwareMsg
by Alexandre Julliard May 14, 2001

May 14, 2001

Rein Klazes <rklazes(a)xs4all.nl> writes: > Dutch tax 2000 declaration setup program crashes at exactly the same > point. Cause of this seems to be some memory allocation/corruption > problem. At some point the memory used by the sysMsgQueue, is > allocated again by some HeapAlloc() and happily used by its requester. Does this help? Index: windows/queue.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/queue.c,v retrieving revision 1.70 diff -u -r1.70 queue.c --- windows/queue.c 2001/04/04 00:19:55 1.70 +++ windows/queue.c 2001/05/14 18:55:22 @@ -598,7 +598,7 @@ /* Note: We dont need perQ data for the system message queue */ if (!(hmemSysMsgQueue = QUEUE_CreateMsgQueue( FALSE ))) return FALSE; - + FarSetOwner16( hmemSysMsgQueue, 0 ); sysMsgQueue = (MESSAGEQUEUE *) GlobalLock16( hmemSysMsgQueue ); return TRUE; } -- Alexandre Julliard julliard(a)winehq.com

3 2

CalcChildScroll
by Bill Medland May 14, 2001

May 14, 2001

Does anyone have a problem with the following fix to windows/mdi.c/CalcChildScroll? It fixes a problem for one product but I am not in a position to test it thoroughly. When measuring the union of the children rectangles only the visible children should be included: .. } else if( pWnd->dwStyle & WS_VISIBLE) UnionRect( &childRect, &pWnd->rectWindow, &childRect ); This stops scrollbars appearing and disappearing while resizing apparently empty mdi clients etc. Bill Medland

1 0

Crash in MSG_PeekHardwareMsg
by Uwe Bonnes May 14, 2001

May 14, 2001

Hallo, the archive viewer "start.exe" for the CDROM archive of german magazine CT crashes since some time: 085a8b90:Ret USER.114: DISPATCHMESSAGE() retval=0x00000000 ret=02ef:005c ds=033f 085a8b90:Call USER.108: GETMESSAGE(0x033fd1be,0x0000,0x0000,0x0000) ret=02ef:4055 ds=033f fixme:pthread_kill_other_threads_np ... Unhandled exception: page fault on read access to 0xffff0203 in 32-bit code (0x40a1718f). In 32-bit mode. 0x40a1718f (MSG_PeekHardwareMsg+0x4f [message.c:595] in libkeyboard.so): repe movsl (%esi),% es:(%edi) 597 nextqmsg = qmsg->nextMsg; Wine-dbg>bt Backtrace: =>0 0x40a1718f (MSG_PeekHardwareMsg+0x4f(msg=0x40d26d28, hwnd=0x0, first=0x0, last=0x0, remove=0x1) [message.c:595] in libkeyboard.so) (ebp=40d26cbc) 1 0x40a17faf (MSG_PeekMessage+0x30f(type=0x0, msg_out=0x40d26d84, hwnd=0x0, first=0x0, last=0x0, flags=0x1, peek=0x0) [message.c:1187] in libkeyboard.so) (ebp=40d26d44) 2 0x40a185d7 (GetMessage32_16+0x67(msg16_32=0x33fd1be, hWnd=0x0, first=0x0, last=0x0, wHaveParamHigh=0x0) [message.c:1468] in libkeyboard.so) (ebp=40d26da0) 3 0x40a186b0 (GetMessage16+0x30(msg=0x33fd1be, hwnd=0x0, first=0x0, last=0x0) [message.c:1491] in libkeyboard.so) (ebp=40d26dc0) 4 0x409c6e20 (USER_CallFrom16_p_word_lwww+0x30(proc=0x40a18680, args=0x404690a4) [user.spec.c:213] in libkeyboard.so) (ebp=40d26ddc) 5 0x4008d7ae (__wine_call_from_16_word+0x8e [asmrelay.s] in libntdll.so) (ebp=40d26e0c) 6 0x02ef:0x4055 (bp=d1ec) 7 0x02ef:0x4240 (bp=d200) 8 0x02e7:0x5a11 (bp=d26a) 9 0x02e7:0x0063 (bp=0000) Any ideas? Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

2 1

Re: GDB remote debugging
by Ove Kaaven May 14, 2001

May 14, 2001

On Mon, 14 May 2001 =?iso-8859-1?Q?G=E9rard_Patel_=3Cgerard.patel=40asi.fr=3E?=(a)s5.asi.fr wrote: > At 11:12 PM 09/05/2001 +0200, Ove Kaaven wrote: > >For any sufficiently disillusioned Wine hackers, here's my current > >experimental code for letting GDB attach to a Wine process. > <snip> > > Is there any way to debug an application from the beginning using this tool ? > (the reason I would like to try it is of course that the app crashes while starting) > If not, is it thinkable to change the code to wait for gdb to connect when > the initial Wine thread connects to the server ? I put that variable "create_suspended" in gdbremote.c for that purpose... just change it from 0 to 1... ought to be a command-line option, but that patch won't be included in wine in its current form anyway, so...

1 0

Re: Problem with tooltips
by gerard patel May 14, 2001

May 14, 2001

At 09:56 PM 13/05/2001 +0200, you wrote: <snip tooltip file dialog problem> >Does anyone know how to fix this? http://www.winehq.com/hypermail/wine-devel/2001/05/0035.html (or replace winehq by 130.225.13.222 if the Corel Dns is still down :-/) Gerard

1 0

Re: Crash in MSG_PeekHardwareMsg
by gerard patel May 14, 2001

May 14, 2001

At 08:56 PM 12/05/2001 +0200, you wrote: >085a8b90:Ret USER.114: DISPATCHMESSAGE() retval=0x00000000 ret=02ef:005c ds=033f >085a8b90:Call USER.108: GETMESSAGE(0x033fd1be,0x0000,0x0000,0x0000) ret=02ef:4055 ds=033f >fixme:pthread_kill_other_threads_np >... >Unhandled exception: page fault on read access to 0xffff0203 > in 32-bit code (0x40a1718f). >In 32-bit mode. >0x40a1718f (MSG_PeekHardwareMsg+0x4f [message.c:595] in libkeyboard.so): repe movsl (%esi),% >es:(%edi) >597 nextqmsg = qmsg->nextMsg; <snip> >Any ideas? There is not much to go on in this information. I can't see this problem with any of my 16 bits apps, but maybe none of them use this kind of GetMessage without specifying a window. I'd suggest first that you compile message.c with optimization level O0 : it seems clear that the displayed instruction is not the one responsible for the crash; the crash happens really in *msg = qmsg->msg. Maybe having no optimization could give more accurate information. When you have done that, rerun and enter info reg and info local when the crash occurs. Also a trace with +relay could be interesting but I think that you know that since you post this tip on cemw often enough :-) Gerard

1 0

Could someone check this on windoze
by Uhmmmm May 13, 2001

May 13, 2001

Could someone please doublecheck this. On windoze, does the bitmap in a SS_BITMAP style STATIC control change if you send it WM_SETTEXT or call SetWindowText() on it like it does in WINE? I don't think it does, but I'd like it if someone could check before I start changing things.

2 2

Problem with tooltips
by Marcus Meissner May 13, 2001

May 13, 2001

Hi, Start any program that uses the common dialog file open dialog (Win95 style) using -managed. Then move the mouse over any of the toolbar icons. Watch a VERY HUGE window manager window pop up displaying the tooltip text in the upper left corner. Reason for this appears to be some changed flags that lets WIN_WindowNeedsWMBorder fail on tooltips. Does anyone know how to fix this? Adding WS_EX_TOOLWINDOW to the tooltip CreateWindow is probably wrong :/ Ciao, Marcus

1 0

RE: WINEPS: Read metrics from TrueType fonts
by Nerijus Baliunas May 13, 2001

May 13, 2001

> This patch enables the PostScript driver to read font metrics directly > from TrueType font files with FreeType 2. It looks for font files in > directories listed in the [TrueType Font Directories] section of the > wine config file. For example: > > [TrueType Font Directories] > "dir0" = "/usr/X11R6/lib/X11/fonts/TrueType" > "dir1" = "/usr/share/fonts/default/TrueType" > etc. > > It does not embed the fonts into its output. Ghostscript users can > install their TrueType fonts in Ghostscript (with their Fontmap file or > the GS_FONTPATH environment variable); users printing to PostScript > printers will have to convert their fonts to Type 1 or Type 42 format > and use an external program to add them to the print jobs. Hello, Why don't you add this text to documentation/printing? Regards, Nerijus

1 0