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

CreateWindow issue?
by Bill Medland July 12, 2001

July 12, 2001

Can anyone shed any light on this? 1. If I take Petzold's POPPAD1 project and slightly modify it so that the style is WS_CHILD | WS_BORDER | WS_VISIBLE | ES_AUTOHSCROLL and then spy on the WM_NCCREATE and WM_CREATE it tells me that the style passed in is WS_OVERLAPPEDWINDOW | WS_CHILDWINDOW | WS_VISIBLE | ES_AUTOHSCROLL which is not the same thing. Does anyone know if a. The Windows Spy++ is telling fibs b. (Win95) CreateWindow patches them up in some way. 2. (Why I was even looking at 1) In the application I am working on we open Edit controls almost as above inside dialogs and they appear with a single pixel solid frame under Windows whereas under Wine they appear with a 2-pixel sunken frame. There are several changes I can make in the controls/edit.c to get the same behaviour under Wine but so far they all "mess up" normal sunken ones. (Under windows the resulting windows end up with zero extended style and 50000088 style.) Any thoughts would be appreciated. Bill

1 1

Re: wine/ ./configure ./configure.in documentation ...
by Uwe Bonnes June 29, 2001

June 29, 2001

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> ... Alexandre> +0 -0 wine/msdos/ppdev.c ^^^^^ Hallo Alexandre, oops, this is not enough. The patch I submitted was --- /dev/null Tue Feb 20 18:39:20 2001 +++ wine/msdos/ppdev.c Thu Jun 21 14:32:14 2001 @@ -0,0 +1,283 @@ ^^^^ Did I choose wrong arguments to diff? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

rebar trouble with WinZip 8.0
by Mike McCormack June 28, 2001

June 28, 2001

Hi, WinZip 8.0 has a toolbar. It used to show all the toolbar buttons, but it seems to have a problem now, since only the LHS button is shown. Some debug output below. Mike mike(a)linux:~/c > wine Program\ Files/WinZip/WINZIP32.EXE Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file .. trace:rebar:REBAR_AdjustBands start=0, end=0, max x=550, max y=61 trace:rebar:REBAR_AdjustBands Phase 1 band 0, (0,0)-(69,61), orig x=0, xsep=0 trace:rebar:REBAR_AdjustBands Phase 2 band 0, (0,0)-(69,61), orig x=0, xsep=0 err:rebar:REBAR_AdjustBands Serious problem adjusting row 1, start band 0, end band 0 trace:rebar:REBAR_AdjustBands start=0, end=0, max x=561, max y=61 trace:rebar:REBAR_AdjustBands Phase 1 band 0, (0,0)-(69,61), orig x=0, xsep=0 trace:rebar:REBAR_AdjustBands Phase 2 band 0, (0,0)-(69,61), orig x=0, xsep=0 err:rebar:REBAR_AdjustBands Serious problem adjusting row 1, start band 0, end band 0 .. fixme:shell:SHGetFileInfoA set icon to shell size, stub fixme:listview:LISTVIEW_SetColumnOrderArray iCount 9 lpiArray 0x405a6a74 mike(a)linux:~/c ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: Support Ordinal forwarding in Dll loading
by Alexandre Julliard June 28, 2001

June 28, 2001

"Guy L. Albertelli" <galberte(a)neo.lrun.com> writes: > In attempting to use Specmaker to create a forwarding DLL to do testing of > the Rebar and ComboBoxEx controls, I ran into a problem where pe_image.c did > not support forwarding an ordinal only reference. This patch allows that > function to work. The ordinal forward is of the form: > dllname.DLLNAME_nnnn. I don't think Windows supports something like this. I would suggest instead to fix specmaker to not generate a forward in this case. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Proper detection of VM86 support
by Alexandre Julliard June 28, 2001

June 28, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > Proper detection of VM86 support > on FreeBSD, Linux and Solaris added. I don't think that's useful. Even if we someday support vm86 on other platforms, this is one of these cases where a simple platform check (#ifdef linux) is preferable to complex configure magic IMO. This is how we do the LDT check too, because there simply isn't enough similarity between platforms to justify configure tests. -- Alexandre Julliard julliard(a)winehq.com

1 0

[Problem report] Messages cooked too much ?
by Gerard Patel June 27, 2001

June 27, 2001

This is a problem of intermittents hangings, when moving the mouse or closing a window (not obvious). I finally realized that the traces in the hanging of Eudora 4 looked very similar, but Eudora 4 hangs reliably ;-) I have found this Eudora crash an infinite loop generated by a mouse move message, cooked to generate a WM_NCMOUSEMOVE, then this last message is obtained repeatedly from the server without being ever removed. It does not seem right to peek a cooked message off the server, not find anything useful to do with it, and just ignore it and asking the server again. The following patch removes the problem, and *seems* to cure the intermittent hangings of other apps. Gerard --- message.c.orig Wed Jun 27 22:14:07 2001 +++ message.c Wed Jun 27 22:13:57 2001 @@ -790,7 +790,11 @@ if (qmsg.kind == RAW_HW_MESSAGE || qmsg.kind == COOKED_HW_MESSAGE) { if (!process_hardware_message( &qmsg, hwnd, first, last, flags & PM_REMOVE )) + { + if (qmsg.kind == COOKED_HW_MESSAGE) + if (!(flags & PM_REMOVE)) QUEUE_FindMsg( hwnd, first, last, TRUE, &qmsg ); goto retry; + } } else {

1 0

Re: docu patch
by Alexandre Julliard June 26, 2001

June 26, 2001

Andreas Mohr <a.mohr(a)mailto.de> writes: > diff -u -r1.9 DEVELOPERS-HINTS > --- DEVELOPERS-HINTS 2001/01/10 23:59:25 1.9 > +++ DEVELOPERS-HINTS 2001/06/26 23:02:00 > @@ -23,6 +23,7 @@ > > GDI: > > + console/ - handling of text consoles > graphics/ - graphics drivers > x11drv/ - X11 display driver > win16drv/ -> see below > @@ -58,7 +59,7 @@ > msnet/ > msvcrt/ - C runtime library > msvideo/ - 16 bit video manager > - ole32/ - 32 bit OLE 2.0 librairies > + ole32/ - 32 bit OLE 2.0 libraries > oleaut32/ - 32 bit OLE 2.0 automation > olecli/ - 16 bit OLE client > oledlg/ - OLE 2.0 user interface support > @@ -86,12 +87,13 @@ > > Miscellaneous: > > - misc/ - shell, registry, winsock, etc. > + misc/ - misc. wine management, registry, etc. > ipc/ - SysV IPC based interprocess communication > - win32/ - misc Win32 functions > ole/ - OLE code > - nls/ - National Language Support > + nls/ - National Language Support > configuration files > + unicode/ - Unicode (character) support > + win32/ - misc Win32 functions > I have nothing against updating the doc, but I don't think adding wrong information is going to help <g>. console/ is not a GDI directory, and there is no top level nls/ directory. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: configure.in patch
by Marcus Meissner June 26, 2001

June 26, 2001

On Tue, Jun 26, 2001 at 03:34:23PM +0900, Bang Jun-Young wrote: > * configure.in: > Remove a redundant check for flex. It is not redundant! AC_PROG_LEX does more than just look for the 'lex' binary. Please do not apply. Ciao, Marcus > -AC_PROG_LEX > AC_CHECK_PROGS(XLEX,$LEX flex lex,none) > if test "$XLEX" = "none" > then

3 5

change of style in the edit control
by Bill Medland June 26, 2001

June 26, 2001

Is anyone working on the edit control's handling of WM_STYLE_CHANGED? Does anyone have any useful information? I intend adding handling of WM_STYLE_CHANGING/ED to controls/edit.c for our application (which uses SetWindowLong to modify the style after creation). 1. Does anyone know why the EDITSTATE.style is not fed back to the pWnd->dwStyle after being modified. 2. Does anyone know of any documentation of the interaction within windows when the styles are incompatible? Bill

1 0

Apps DB round 2
by Jeremy Newman June 26, 2001

June 26, 2001

The new Application DB (http://wine.codeweavers.com/appdb/) is starting to fill up. But, we still need your help before we totally unleash it on the Wine community. We need as much feedback, comments, and flames [:-)] as possible this week. We need volunteers to take responsibility for updating Apps in the DB. If you would like to help, email the appDB team at appdb(a)codeweavers.com. Areas we need help on: - Add Apps and App Versions. - Comments on Apps - Application Owners (the app db has a privilege system where you can be owner of an app.) - Screenshots (lots of 'em) --- _ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://jnewman.codeweavers.com | .` / -_) V V / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

9 12

undefined reference to main in _start
by Gilroy Billard June 25, 2001

June 25, 2001

Hi, I can't link in any version of the WINE libraries after version 20001202 without getting a linker error: undefined reference to main in function _start. I compile WINE with these options: ./configure --without-x --without-curses --disable-debug --disable-trace. Any ideas??? thanks, Gilroy Billard mailto:gilroy(a)trakonic.com Software Developer Trakonic Inc. PH: 1-902-450-0922 FX: 1-902-450-0939 1-877-419-3887 http://www.trakonic.com

5 6

Re: Win16 calls by Win32 functions
by Alexandre Julliard June 25, 2001

June 25, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > Sure Win32 calls to Win16 should be eliminated that is > without question. This is how Windows NT does it and > Alexandre has a policy that Wine should doing like > Windows NT does. I fully agree. > > However I'm not positive that replacing Win16 calls to > Win16 with Win32 calls is always good idea. See below. As a rule it is a good idea, but there are of course exceptions. Basically the rule should be that wherever you can choose between a Win16 or Win32 function to do something, you should pick the Win32 function. But in the cases where the Win16 and Win32 functions have different semantics, then of course you have to use the correct one, even if in some cases it means calling Win16 functions from Win32 (like for the GlobalAlloc stuff). -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Win16 calls by Win32 functions
by Patrik Stridvall June 25, 2001

June 25, 2001

> "Patrik Stridvall" <ps(a)leissner.se> wrote: > > > Noticing that you (Dimitry) have send in a few patch > > replacing Win16 calls by Win32 ones, I wish to > > point out that winapi_check can detect "illegal" > > calls from Win32 to Win16. > > > > Just do > > winapi_check --cross-call-win32-win16 > > Great! Why didn't you just make a patch and submit it? Well. Because I don't want to blindly do search and replace I haven't got around to do it since it will take some time to analyze each case for correctness. It is on my list of things to do but it has very low priority. But since you seems to be doing it, I might just as well tell you how to easily find many of them. > > Note that some of the fixes in your (Dimitry's) > > patches is not included in the result below > > because they are Win16 functions calling Win16 > > functions. > > > > I do not say this is nessary wrong, but are > > you (Dimitry) really sure this is how it should be? > > Well, as Alexandre already has pointed out, Win16 should be > mostly implemented by using Win32. I agree with him that use > of the 16-bit code should be eliminated as much as possible. > Moreover, until now I just have replaced only obvious places: > 16-bit functions which just thunk up to win32 without any > argument processing. Sure Win32 calls to Win16 should be eliminated that is without question. This is how Windows NT does it and Alexandre has a policy that Wine should doing like Windows NT does. I fully agree. However I'm not positive that replacing Win16 calls to Win16 with Win32 calls is always good idea. See below. > > Sure it probably runs a little faster, but then Win16 > > applications on a modern computer are likely to be > > _very_ fast, so it is really worth risking potential > > compabillity errors because of some probably irrelavant > > speed differences. > > > > Not that functions like DeleteObject are likely to > > have such problems but still... > > I'm not going to blindly replace 16-bit calls by 32-bit. > I look into the code and do think twice before submitting > a patch. Of course you are not, but there might be subtle issues that break the code in the future then the full Win32 semantics is implemented. That requires much more thinking than just casually browsing the code and reading the documentation. Actually just thinking and reading documentation is not enough either Win32 or Win16 might have undocumentation features on Windows not implement by Wine yet. Note that I'm not convinced is a large problem if any at all. I'm just worried and think we need to think this through carefully. So what should we do? Correct me if I'm wrong but because of the DLL separation Win16 to Win16 calls between different DLL:s (or rather different .so files) must not take place. I notice that, for example, user32.spec contains the following lines: ################################################################ # Wine extensions: Win16 functions that are needed by other dlls # @ stdcall CallNextHookEx16(long long long long) CallNextHookEx16 @ stdcall CallWindowProc16(long long long long long) CallWindowProc16 @ stdcall CloseDriver16(long long long) CloseDriver16 @ stdcall CreateDialogIndirectParam16(long ptr long long long) CreateDialogIndirectParam16 @ stdcall DefDriverProc16(long long long long long) DefDriverProc16 @ stdcall DialogBoxIndirectParam16(long long long long long) DialogBoxIndirectParam16 @ stdcall GetDriverModuleHandle16(long) GetDriverModuleHandle16 @ stdcall OpenDriver16(str str long) OpenDriver16 @ stdcall PostAppMessage16(long long long long) PostAppMessage16 @ stdcall SendDriverMessage16(long long long long) SendDriverMessage16 @ stdcall SetWindowsHookEx16(long long long long) SetWindowsHookEx16 @ stdcall UserYield16() UserYield16 and gdi32.spec contains these lines: ################################################################ # Wine extensions: Win16 functions that are needed by other dlls # @ stdcall CreateMetaFile16(str) CreateMetaFile16 @ stdcall CloseMetaFile16(long) CloseMetaFile16 This is what is guess Alexandre wants eliminated not calls like the call in SetDCState16 (Win16 GDI) to DeleteObject16 (Win16 GDI) that you "fixed" in one of your patches. Of course Win32 to Win16 calls should be fixed even within a DLL but that is because of possible different semantics not because of the DLL separation. In short I suggest the following policy 1. No Win32 to Win16 calls: This is because of semantic and speed reasons. 2. No Win16 to Win16 calls between different DLL:s: This is because of the DLL separation. 3. No Win16 to Win32 calls within a DLL (with the exception a function's Win32 counterpart or replacement in the case of obsolete function): This is because of semantic reasons but I'm not sure how hard we must enforce point, because if the the Win32 function generates a non Win16 message or some other non Win16 related stuff I guess we can quite easily can (and perhaps even now does) ignore or filter such things in more fundamental part of the code like in the message dispatching code.

1 0

Win16 calls by Win32 functions
by Patrik Stridvall June 25, 2001

June 25, 2001

Noticing that you (Dimitry) have send in a few patch replacing Win16 calls by Win32 ones, I wish to point out that winapi_check can detect "illegal" calls from Win32 to Win16. Just do winapi_check --cross-call-win32-win16 Unfortunately there is a bug in the CVS version of winapi_check (fixed in my tree) that makes this option output too many messages. However until it is updated just do "grep 'illegal call'" on the output. The result this is included below. Note that some of the fixes in your (Dimitry's) patches is not included in the result below because they are Win16 functions calling Win16 functions. I do not say this is nessary wrong, but are you (Dimitry) really sure this is how it should be? Sure it probably runs a little faster, but then Win16 applications on a modern computer are likely to be _very_ fast, so it is really worth risking potential compabillity errors because of some probably irrelavant speed differences. Not that functions like DeleteObject are likely to have such problems but still... ---8<--- controls/menu.c: user32: GetSystemMenu: illegal call to GetSubMenu16 (Win32 -> Win16) dlls/kernel/comm.c: kernel32: BuildCommDCBAndTimeoutsA: illegal call to BuildCommDCB16 (Win32 -> Win16) dlls/msvideo/msvideo_main.c: msvfw32: ICClose: illegal call to ICSendMessage16 (Win32 -> Win16) dlls/ole32/compobj.c: ole32: CLSIDFromProgID: illegal call to CLSIDFromProgID16 (Win32 -> Win16) dlls/ole32/compobj.c: ole32 & ole32: CLSIDFromString: illegal call to CLSIDFromString16 (Win32 -> Win16) dlls/ole32/storage.c: ole32: StgIsStorageFile: illegal call to StgIsStorageFile16 (Win32 -> Win16) dlls/shell32/shell.c: shell32: ExtractAssociatedIconA: illegal call to ExtractAssociatedIcon16 (Win32 -> Win16) dlls/winmm/mci.c: mmsystem & winmm: mciExecute: illegal call to mciSendString16 (Win32 -> Win16) dlls/winmm/mci.c: winmm: mciFreeCommandResource: illegal call to mciFreeCommandResource16 (Win32 -> Win16) dlls/winmm/mmsystem.c: winmm: mciGetErrorStringA: illegal call to mciGetErrorString16 (Win32 -> Win16) dlls/winmm/mmsystem.c: winmm: mmsystemGetVersion: illegal call to mmsystemGetVersion16 (Win32 -> Win16) files/profile.c: kernel32: GetPrivateProfileSectionNamesW: illegal call to GetPrivateProfileSectionNames16 (Win32 -> Win16) graphics/escape.c: gdi32: ExtEscape: illegal call to Escape16 (Win32 -> Win16) loader/module.c: kernel32: WIN32_GetProcAddress16: illegal call to GetProcAddress16 (Win32 -> Win16) loader/ne/module.c: kernel & kernel32: FreeLibrary16: illegal call to FreeModule16 (Win32 -> Win16) memory/global.c: kernel & kernel32: GlobalFix16: illegal call to GlobalHandleToSel16 (Win32 -> Win16) memory/global.c: kernel & kernel32: GlobalReAlloc16: illegal call to GlobalHandleToSel16 (Win32 -> Win16) memory/global.c: kernel & kernel32: GlobalWire16: illegal call to WIN16_GlobalLock16 (Win32 -> Win16) memory/global.c: kernel32: K32WOWGlobalLock16: illegal call to WIN16_GlobalLock16 (Win32 -> Win16) objects/clipping.c: gdi32: RectVisible: illegal call to RectVisible16 (Win32 -> Win16) objects/dc.c: gdi32: RestoreDC: illegal call to SetDCState16 (Win32 -> Win16) objects/metafile.c: gdi32: PlayMetaFileRecord: illegal call to PlayMetaFileRecord16 (Win32 -> Win16) objects/palette.c: gdi32: UpdateColors: illegal call to UpdateColors16 (Win32 -> Win16) windows/clipboard.c: user32: RegisterClipboardFormatA: illegal call to RegisterClipboardFormat16 (Win32 -> Win16) windows/cursoricon.c: user32: CreateCursor: illegal call to CreateCursorIconIndirect16 (Win32 -> Win16) windows/cursoricon.c: user32: CreateIcon: illegal call to CreateCursorIconIndirect16 (Win32 -> Win16) windows/cursoricon.c: user32: DestroyCursor: illegal call to CURSORICON_Destroy (Win32 -> Win16) windows/cursoricon.c: user32: DestroyIcon: illegal call to CURSORICON_Destroy (Win32 -> Win16) windows/cursoricon.c: user32: LookupIconIdFromDirectoryEx: illegal call to LookupIconIdFromDirectoryEx16 (Win32 -> Win16) windows/mdi.c: user32: DefFrameProcA: illegal call to DefFrameProc16 (Win32 -> Win16) windows/mdi.c: user32: DefFrameProcW: illegal call to DefFrameProc16 (Win32 -> Win16) windows/mdi.c: user32: DefMDIChildProcA: illegal call to DefMDIChildProc16 (Win32 -> Win16) windows/mdi.c: user32: ScrollChildren: illegal call to CalcChildScroll16 (Win32 -> Win16) windows/painting.c: user32: UserRealizePalette: illegal call to RealizePalette16 (Win32 -> Win16)

2 1

wine core dump
by Heiko Nardmann June 25, 2001

June 25, 2001

I am not sure whether this mail reached the mailing list already partly. Due to some problem with KMail here is the full mail. Using CVS version from 23.6. I was able to produce a core dump trying to use Word97. Here is the session from gdb. I might provide the core file to anyone interested. snsrv053:nardmann[Word]>gdb /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/wine core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Core was generated by `/opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-200106'. Program terminated with signal 11, Speicherzugriffsfehler. Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_unicode.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_unicode.so Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libutil.so.1...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libkernel32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libkernel32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libuser32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libuser32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libgdi32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libgdi32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libadvapi32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libadvapi32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libole32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libole32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/librpcrt4.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/librpcrt4.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshell32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshell32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshlwapi.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshlwapi.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libcomctl32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libcomctl32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwinspool.drv.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwinspool.drv.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libx11drv.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libx11drv.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_tsx11.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_tsx11.so Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Loaded symbols for /usr/X11R6/lib/libXpm.so.4 Reading symbols from /usr/X11R6/lib/libXxf86dga.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86dga.so.1 Reading symbols from /usr/X11R6/lib/libXxf86vm.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86vm.so.1 Reading symbols from /usr/lib/libGL.so.1...done. Loaded symbols for /usr/lib/libGL.so.1 Reading symbols from /usr/lib/libGLU.so.1...done. Loaded symbols for /usr/lib/libGLU.so.1 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Loaded symbols for /usr/X11R6/lib/libXmu.so.6 Reading symbols from /usr/X11R6/lib/libXi.so.6...done. Loaded symbols for /usr/X11R6/lib/libXi.so.6 Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Loaded symbols for /usr/X11R6/lib/libXt.so.6 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwineps.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwineps.so #0 thread_errno_location () at thread.c:214 214 return &NtCurrentTeb()->thread_errno; (gdb) bt #0 thread_errno_location () at thread.c:214 #1 0x40292a15 in __sigprocmask (how=0, set=0x40114340, oset=0x404a1058) at ../sysdeps/unix/sysv/linux/sigprocmask.c:48 #2 0x400c99c6 in wine_server_call (req=0x404a1158, size=20) at client.c:196 #3 0x4005af51 in send_debug_event (rec=0x404a123c, first_chance=1, context=0x404a12b0) at exception.c:124 #4 0x4005b19f in EXC_RtlRaiseException (rec=0x404a123c, context=0x404a12b0) at exception.c:177 #5 0x40062509 in do_segv (context=0x404a12b0, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #6 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078596916, sc_esi = 1074775150, sc_ebp = 1078596752, sc_esp = 1078596704, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078596704, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #7 <signal handler called> #8 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #9 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #10 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1534, context=0x404a15a8) at exception.c:195 #11 0x40062509 in do_segv (context=0x404a15a8, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #12 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078597676, sc_esi = 1074775150, sc_ebp = 1078597512, sc_esp = 1078597464, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078597464, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #13 <signal handler called> #14 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #15 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #16 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a182c, context=0x404a18a0) at exception.c:195 #17 0x40062509 in do_segv (context=0x404a18a0, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #18 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078598436, sc_esi = 1074775150, sc_ebp = 1078598272, sc_esp = 1078598224, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078598224, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #19 <signal handler called> #20 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #21 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #22 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1b24, context=0x404a1b98) at exception.c:195 #23 0x40062509 in do_segv (context=0x404a1b98, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #24 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078599196, sc_esi = 1074775150, sc_ebp = 1078599032, sc_esp = 1078598984, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078598984, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #25 <signal handler called> #26 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #27 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #28 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1e1c, context=0x404a1e90) at exception.c:195 #29 0x40062509 in do_segv (context=0x404a1e90, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #30 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078599956, sc_esi = 1074775150, sc_ebp = 1078599792, sc_esp = 1078599744, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078599744, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #31 <signal handler called> #32 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #33 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #34 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a2114, context=0x404a2188) at exception.c:195 #35 0x40062509 in do_segv (context=0x404a2188, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #36 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078600924, sc_esi = 1074775150, sc_ebp = 1078600548, sc_esp = 1078600500, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078600500, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #37 <signal handler called> #38 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #39 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #40 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a24dc, context=0x404a2410) at exception.c:195 ---Type <return> to continue, or q <return> to quit--- #41 0x400629c4 in int_handler (__signal=2, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1074113920, sc_esi = 0, sc_ebp = 1078608284, sc_esp = 1078601232, sc_ebx = 1078608268, sc_edx = 810345475, sc_ecx = 17152, sc_eax = 1078601394, sc_trapno = 14, sc_err = 4, sc_eip = 2356908743, sc_cs = 35, __csh = 0, sc_eflags = 646, esp_at_signal = 1078601232, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 1078620009}) at signal_i386.c:893 #42 <signal handler called> #43 0x8c7b92c7 in ?? () #44 0xe in ?? () Cannot access memory at address 0x1 -- 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

1 0

wine core dump
by Heiko Nardmann June 25, 2001

June 25, 2001

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Using CVS version from 23.6. I was able to produce a core dump trying to use Word97. Here is the session from gdb. I might provide the core file to anyone interested. snsrv053:nardmann[Word]>gdb /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/wine core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Core was generated by `/opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-200106'. Program terminated with signal 11, Speicherzugriffsfehler. Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_unicode.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_unicode.so Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libutil.so.1...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libkernel32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libkernel32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libuser32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libuser32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libgdi32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libgdi32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libadvapi32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libadvapi32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libole32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libole32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/librpcrt4.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/librpcrt4.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshell32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshell32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshlwapi.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshlwapi.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libcomctl32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libcomctl32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwinspool.drv.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwinspool.drv.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libx11drv.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libx11drv.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_tsx11.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_tsx11.so Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Loaded symbols for /usr/X11R6/lib/libXpm.so.4 Reading symbols from /usr/X11R6/lib/libXxf86dga.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86dga.so.1 Reading symbols from /usr/X11R6/lib/libXxf86vm.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86vm.so.1 Reading symbols from /usr/lib/libGL.so.1...done. Loaded symbols for /usr/lib/libGL.so.1 Reading symbols from /usr/lib/libGLU.so.1...done. Loaded symbols for /usr/lib/libGLU.so.1 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Loaded symbols for /usr/X11R6/lib/libXmu.so.6 Reading symbols from /usr/X11R6/lib/libXi.so.6...done. Loaded symbols for /usr/X11R6/lib/libXi.so.6 Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Loaded symbols for /usr/X11R6/lib/libXt.so.6 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwineps.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwineps.so #0 thread_errno_location () at thread.c:214 214 return &NtCurrentTeb()->thread_errno; (gdb) bt #0 thread_errno_location () at thread.c:214 #1 0x40292a15 in __sigprocmask (how=0, set=0x40114340, oset=0x404a1058) at ../sysdeps/unix/sysv/linux/sigprocmask.c:48 #2 0x400c99c6 in wine_server_call (req=0x404a1158, size=20) at client.c:196 #3 0x4005af51 in send_debug_event (rec=0x404a123c, first_chance=1, context=0x404a12b0) at exception.c:124 #4 0x4005b19f in EXC_RtlRaiseException (rec=0x404a123c, context=0x404a12b0) at exception.c:177 #5 0x40062509 in do_segv (context=0x404a12b0, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #6 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078596916, sc_esi = 1074775150, sc_ebp = 1078596752, sc_esp = 1078596704, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078596704, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #7 <signal handler called> #8 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #9 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #10 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1534, context=0x404a15a8) at exception.c:195 #11 0x40062509 in do_segv (context=0x404a15a8, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #12 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078597676, sc_esi = 1074775150, sc_ebp = 1078597512, sc_esp = 1078597464, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078597464, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #13 <signal handler called> #14 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #15 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #16 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a182c, context=0x404a18a0) at exception.c:195 #17 0x40062509 in do_segv (context=0x404a18a0, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #18 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078598436, sc_esi = 1074775150, sc_ebp = 1078598272, sc_esp = 1078598224, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078598224, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #19 <signal handler called> #20 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #21 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #22 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1b24, context=0x404a1b98) at exception.c:195 #23 0x40062509 in do_segv (context=0x404a1b98, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #24 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078599196, sc_esi = 1074775150, sc_ebp = 1078599032, sc_esp = 1078598984, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078598984, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #25 <signal handler called> #26 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #27 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #28 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1e1c, context=0x404a1e90) at exception.c:195 #29 0x40062509 in do_segv (context=0x404a1e90, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #30 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078599956, sc_esi = 1074775150, sc_ebp = 1078599792, sc_esp = 1078599744, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078599744, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #31 <signal handler called> #32 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7Nu3bpm53PRScYygRAuYLAKDR49a+j/JDCirOmLCC48N1ql1rXgCg10Ah aOiXiUWyz02czaQc4jG1i8k= =W1KY -----END PGP SIGNATURE-----

1 0

Fallout Tactics problems
by Tim Oertel June 24, 2001

June 24, 2001

Hi all, I sent this to wine-users, but got no response... so I'll assume I've hit a bug or three. I've successfully installed FT, and it sorta runs. Specifically: o It installed without problems. o It runs the intro animations and training walkthroughs, but the anims alternately play audio or video, pausing the other while one plays. o Character creation works, although the keyboard occasionally fails to work... not sure why. o Screen redraw is hosed when scrolling left or up. A ~64 pixel strip gets replicated across the screen... Clicking directly on the map redraws fine. I'm wondering if anyone knows what is going on or can suggest how to start debugging the scrolling problem. (I have plenty of debug experience and can figure things out, but I'm not familiar with wine, so am not sure where to start.) I'm using the latest CVS build as of 2001/06/20. Tim -- ////// toertel(a)rpa.net ///////////// // "Why should I be content to simply // / live in this world, when I, as a // human being, can CREATE it?" //

1 0

A pointer to some undoc functions
by Uwe Bonnes June 24, 2001

June 24, 2001

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 ----------

1 0

[Problem report] X11DRV_GetDC
by Gerard Patel June 24, 2001

June 24, 2001

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;

1 0

Re: PATCH: MSDOS VGA mode
by Ove Kaaven June 23, 2001

June 23, 2001

On Sun, 17 Jun 2001, Marcus Meissner wrote: > However, Monkey Island does not appear to get <return> presses. I see > in 60 returning scancode 0x1c (and 0x9c on release), but it never triggers > any reaction :( Yes, the relevant code in msdos/int09.c is stiff #if 0-ed out in the Wine CVS. I think I have some stuff fixing it lying around in my old Wine tree, but it was rejected in its first form, so it might need a rewrite. But the vm86 restructure is probably more important...

2 3

Re: wrc error
by Gaël de Chalendar June 23, 2001

June 23, 2001

Hi, As I wrote on comp.emulators.ms-windows.wine, I have the same problem (on 2 machines, a third one works well). What caused the problem is the last patch on wrc (I got the previous version of wrc files and it works). A preprocessed version of what do you want ? Bye Gael On Fri, 15 Jun 2001, Bang Jun-Young wrote: > Hi, > > I got the following error when I tried to compile the latest > CVS source: > > gmake[2]: Entering directory `/home/bjy/wine/dlls/user' > LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/wrc/wrc -I. -I. -I../../include -I../../include -o resources/user32.res -r resources/user32.rc > resources/user32_Ca.rc:2:1: Error: syntax error > gmake[2]: *** [resources/user32.res] Error 1 I did a cvs update five minutes ago and it compiled just fine. cvs diff shows no difference in te tools/wrc area either. Can you send me a preprocessed version? -- -- _______________________________________________ Gael de Chalendar LIMSI/CNRS, BP 133, 91 403 Orsay Cedex (France) Tel : 01 69 85 80 04, Fax : 01 69 85 80 88 E-mail : mailto:Gael.de.Chalendar(a)limsi.fr Web : http://www.limsi.fr/Individu/gael/

3 3

Word97 problems
by Heiko Nardmann June 23, 2001

June 23, 2001

-----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-----

1 1

Problems loading mingw32 binaries (latest CVS)
by Vedran Rodic June 23, 2001

June 23, 2001

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

1 1

Re: Initializing Dosvm for direct port access
by Alexandre Julliard June 23, 2001

June 23, 2001

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... How does the app behave under NT? Or with -winver nt40? -- Alexandre Julliard julliard(a)winehq.com

2 1

Readconsole, was libreadline for winedbg
by Uwe Bonnes June 22, 2001

June 22, 2001

Hallo, investigating further, I found that winedbg uses ReadConsole to get what the debug-user typed in, however ReadConsole by far doesn't behave as expected, namely to give back the VT100 codes for what the user typed in. At present arrow key presses are never delivered to winedbg and if winedbg runs on the staring console, input is only delivered to winedbg after the user entered "Enter". Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: wine/ dlls/x11drv/winpos.c windows/x11drv/event.c
by Guy L. Albertelli June 22, 2001

June 22, 2001

With the patch "Don't rely on X to expose windows covered by a sibling, do it manually. (6/21)" installed, it seems that most (possibly all) of the painting problems have been fixed. Great job!! There are two other outstanding problems remaining: 1. With ControlSpy (REBAR.EXE), WinRAR, and IE4 and native controls (commctrl, comctl32): The 01/03/15 cvs, when the mouse moves over the gripper, the cursor changes to linked left & right arrows. When the left button is pressed, the cursor is changed to a small double gripper with left & right arrows. The selected band can then be dragged. At the 01/06/01 cvs, the cursor is not changed either before the left button push or after. However the selected band can still be dragged. With the current cvs (01/06/22), the cursor is changed to the linked left & right arrows, but the area where the change occurs is much smaller. The cursor goes back to the normal arrow after the left button is pressed. The selected band can then be dragged, but is less responsive that the other two cases by about 50%. 2. This is with -managed mode and both examples involve the X-window being minimized (current cvs 6/22): With IE4 and native controls (commctrl, comctl32), when typing in the address box and "enter" is hit, the Xwindow is minimized and the data is processed. With our code, the enter is ignored. With WinRAR and native controls (commctrl, comctl32), selecting the settings dialog and replying OK results in the main window being mimimized. Selecting cancel (or other dialog boxes) do not cause mimimization. Guy

1 0

ChooseFont dialog problems.
by kenon＠go2.pl June 22, 2001

June 22, 2001

Hello, I'm trying to make choosefont dialog working. (I'm not sending this patch to wine-patches because it is incomplete ,and I rather need some ideas ) First hunk of the patch allows changing font colors in 16-bit apps , and it seems to work properly. Second and third hunk affects both 16 and 32 bit apps ,and my intention is to fix CF_INITTOLOGFONTSTRUCT style handling. It almost works ,but code in dlls/commdlg/fontdlg.c is very cryptic (was it based on original Micro$oft code ? :-) ) . Should it be wrtitten from beginning :-( ? Trying to patch this file resemble hard patchwork :-) or else I spent too little time on trying to understand the file. Maciek --- /home/mkalisz/wine/dlls/commdlg/fontdlg.c Tue Jun 19 05:34:07 2001 +++ dlls/commdlg/fontdlg.c Sat Jun 23 01:27:57 2001 @@ -220,6 +220,7 @@ } lpChFont->lpTemplateName=lpTemplateName; + lpChFont->rgbColors=cf32a.rgbColors; font16 = MapSL(lpChFont->lpLogFont); font16->lfHeight = cf32a.lpLogFont->lfHeight; @@ -782,7 +783,7 @@ j=SendDlgItemMessageA(hDlg, cmb3, CB_GETCOUNT, 0, 0); for (i=0;i<j;i++) { - if (lpxx->lfHeight==(int)SendDlgItemMessageA(hDlg,cmb3, CB_GETITEMDATA,i,0)) + if (lpxx->lfHeight==-(int)SendDlgItemMessageA(hDlg,cmb3, CB_GETITEMDATA,i,0)) SendDlgItemMessageA(hDlg,cmb3,CB_SETCURSEL,i,0); } } @@ -1000,6 +1001,7 @@ return TRUE; } } + break; case chx1: case chx2: case cmb2:

1 0

Re: PATCH: MSDOS VGA mode
by Alexandre Julliard June 22, 2001

June 22, 2001

Ove Kaaven <ovehk(a)ping.uio.no> writes: > 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? Did you try to simply remove the assert? I think the way the select is done now, it should actually work fine, and the assert should no longer be necessary. -- Alexandre Julliard julliard(a)winehq.com

1 0

word wrapping in ListViews
by Bill Medland June 22, 2001

June 22, 2001

Does anyone know where the word-wrapping occurs in CListView objects? In the MFC code or lower down? One of the issues we face with our app is that on Windows when icons are displayed in a CListView and the label is significantly wider than the icon then I note that the label is written on two lines whereas under Wine it is displayed truncated on a single line. I am trying to figure out where the fault is. Does anyone know? Bill

1 0

server:truncated to 32768
by David Hagood June 21, 2001

June 21, 2001

With a fresh build of last night's CVS pull, when I attempt to run Delorme's AAA MapNGo V4.0, I get the following error condition: server:truncated to 32768 server:truncated to 32768 At this point the main window of the application is up. However, if I try to do anything non-trivial with the app, it coughs up this error: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 1663 Current serial number in output stream: 1668 and one of the app threads dies. However, the main app window is still up, and four of its threads (plus the wineserver) are still alive. The app stops responding to the system, however. Where do I start on debugging this? What should I trace?

2 1

Initializing Dosvm for direct port access
by Uwe Bonnes June 21, 2001

June 21, 2001

Hallo Ove, is something like appended patch right to get direct port access working for a win95 program? At least my dongle protected program (spde) doesn't crash any more and recognizes the license. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- hertz:/spare/bon/wine-clean> cvs -d $CVSROOT diff -uw -7 wine/msdos/ioports.c Index: wine/msdos/ioports.c =================================================================== RCS file: /home/wine/wine/msdos/ioports.c,v retrieving revision 1.24 diff -u -w -7 -r1.24 ioports.c --- wine/msdos/ioports.c 2001/05/09 17:31:35 1.24 +++ wine/msdos/ioports.c 2001/06/21 08:23:57 @@ -227,14 +227,15 @@ static void IO_port_init(void) { char temp[1024]; do_direct_port_access = 0; /* Can we do that? */ + DPMI_LoadDosSystem(); if (!iopl(3)) { iopl(0); PROFILE_GetWineIniString( "ports", "read", "*", temp, sizeof(temp) ); do_IO_port_init_read_or_write(temp, IO_READ); PROFILE_GetWineIniString( "ports", "write", "*",

2 2

Press: OsOpinion: Putting a Bad API on a Good OS
by Francois Gouget June 20, 2001

June 20, 2001

Hi, A nice article with a provocative title. What I like about it is that it addresses the main objection of Linux hardcore users to Wine (at least as seen from Slashdot): will Wine hurt Linux? But judge for yourself :-) http://www.osopinion.com/perl/story/11297.html -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

2 1

Re: Still more clipping issues - but getting better
by r.maurizzi＠gvs.it June 20, 2001

June 20, 2001

I'm using Lotus Notes 4.6, and with the last updates wirtualy all clipping problems were solved. The problem now is that every time I type a character in the editor, the whole window gets repainted 8-) and sometimes I can't see the cursor or a text selection I make. How can I help? Ciao, Roberto.

1 0

Still more clipping issues - but getting better
by Guy L. Albertelli June 19, 2001

June 19, 2001

Hi Alexandre, The latest commits (through "Clip parent client area when using the drawable from a higher level parent." julliard(a)wine2. 01/06/19 20:22:40) have fixed the problem mentioned in the previous email. However certain problems still exist. The attached JPG shows the results with the latest commits and the native control when the second band is deleted (band # 1). Somehow it never erases the band. This did work correctly in 6/1 CVS. Recreation instructions: Select RB_DELETEBAND and change the first zero (second line) to a 1 and send it. The second band with the ComboBoxEx should disappear. There is another issue with IE4 (one of my test programs). When a string is typed into the address line (a ComboBoxEx) and "return" pressed, the entire IE window disappears. IE is still running and by selecting the item in the GNOME taskbar, the IE window reappears correctly. Thanks a lot, Guy Albertelli <<galberte(a)neo.lrun.com>>

1 0

Still clipping issues
by Guy L. Albertelli June 19, 2001

June 19, 2001

The REBAR ControlSpy (as a simple test application) still displays clipping/drawing issues since 6/1/2001 even with the native control. The enclosed JPG shows some of the problems. The method for recreation is to select the Styles menu and then select the Recreate Control button. At the end of the redraw cycle the distortion is as shown. Note the partial combobox dropdown arrow just below the word "Control_" in the center of the screen. This seems to be due to an unclipped rectangle/too large a client area during the ComboBoxEx creation. In the 6/1 CVS version, you can see the same dropdown arrow but it is within the left hand control window not beyond. Note also the badly drawn text in the two listboxes to the right. If there is anything I can supply to help fix this please let me know. Thanks, Guy Albertelli <<galberte(a)neo.lrun.com>>

1 0

Re: PATCH: wine-config
by Alexandre Julliard June 19, 2001

June 19, 2001

Malte Starostik <malte(a)kde.org> writes: > For example if the winelib app is only part of a project that for some reason > has its own Makefile management and/or merges its own rules with the ones for > wine. Yes, this refers to activexproxy where we currently have a self-written > configure check, but I could imagine other places where this might be of > interest... Well, of course you don't have to use the complete configure and makefile generated by winemaker, you can just take the subset you need and copy it into your makefiles. But I don't see how a wine-config could help you do that. Also I don't see why you'd necessarily want to use the same flags to compile your winelib app that have been used to compile wine itself; in fact you may not even be using the same compiler. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: wine-config
by Alexandre Julliard June 19, 2001

June 19, 2001

Marcus Meissner <marcus(a)jet.franken.de> writes: > to help winelib using developers, this program exports flags and directories > to /usr/bin/. > > I am not sure whether exported cflags and libs are ok. > > Hmm, we probably should also tell how to build .so libs. And specs -> .cs. > (Hmm, supply Makefile snippets?) Actually we already have winemaker that can generate a complete configure and makefile, so I'm not sure what purpose a wine-config would serve. -- Alexandre Julliard julliard(a)winehq.com

2 1

problem in create_icon_window in x11drv/window.c ?
by Adriaan Moors June 19, 2001

June 19, 2001

hi just checked out wine from cvs today (exams are finally over ;-)), and tried to run WinMX (which ran fine, and still runs fine, using the precompiled cvs i have from june 9th), now with today's cvs i get this error: (i think it happens when the window for the tray icon is created...) <snip> trace:x11drv:create_icon_window created 280000d X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 89 Current serial number in output stream: 94 <wine exits> when i comment out the TSXCreateWindow in create_icon_window, the program starts up, but the windows keep moving about... i'm sorry if this is not the right newsgroup to post to, i hope it's not something i've done wrong regards, adriaan moors -- ADDING "JUST KIDDING" DOESN'T MAKE IT OKAY TO INSULT THE PRINCIPAL Bart Simpson on chalkboard in episode 2F09

1 0

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall June 19, 2001

June 19, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Trying to claim, even though you didn't, that Winelib is > > effected is absurd since it is independent of the debugger. > > Distributing the debugger with WineLib is merly an aggregation > > nothing more. > > In theory any library that the debugger uses will also fall under the > GPL. In _theory_ yes, but hardly in pratices. No sane court would claim that, not even, would I dare say, the one of Judge Kaplan of DeCSS fame. Of course Microsoft (I can't remember the link but search on Slashdot) do claim it in their FUD campaign against the GPL but that doesn't make it true. Whether the GPL:ed is designed to be a "virus" or not is one thing that I will not argue for or against, but copyright law defintely isn't, so I will be quite hard for it to spread in the real world. > And someone shipping Wine binaries may not be aware that parts of > it need to be GPLed, and they will get flamed to death on Slashdot. That is a very convincing argument, yes. :-) > I mostly agree with you that the FSF stance on dynamic linking has no > basis in copyright law, but I'm not interested in providing the test > case. So if you want to use readline you can patch your local copy, > but I won't ship this in the main distribution. I was pretty sure that would be your answer.

1 0

Re: PATCH: Move 16-bit COMM stuff to USER, where it belongs
by Alexandre Julliard June 19, 2001

June 19, 2001

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Alexandre, you are right that that code should be revised and duplications > must be remove. But since I'm not an expert in the win32 communications code, > I can't do it without risk to break a working code. This patch was mostly > inspired by the fact, that while USER exports 16-bit comm stuff, that stuff > is not in the USER code. Instead of doing an ugly thing exporting 16-bit comm > functions from KERNEL I decided to move the code around. Please consider the > applying of the patch as it is now. Code duplication can be removed later. No, I'm afraid it won't be fixed if it is moved to a separate file. Also the split is not going to help for dll separation anyway, since the 16-bit routines use the SERVICE_* functions that aren't exported. So if you want clean dll separation the only choice is to rewrite the 16-bit routines. Any volunteer? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Use the libreadline in Winedbg, if available
by Alexandre Julliard June 19, 2001

June 19, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > Trying to claim, even though you didn't, that Winelib is > effected is absurd since it is independent of the debugger. > Distributing the debugger with WineLib is merly an aggregation > nothing more. In theory any library that the debugger uses will also fall under the GPL. And someone shipping Wine binaries may not be aware that parts of it need to be GPLed, and they will get flamed to death on Slashdot. I mostly agree with you that the FSF stance on dynamic linking has no basis in copyright law, but I'm not interested in providing the test case. So if you want to use readline you can patch your local copy, but I won't ship this in the main distribution. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall June 19, 2001

June 19, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > No, it is enough that it is GPL compatible which the Wine > license is. > > But then the code can no longer be distributed under a non GPL > compatible license, while this is allowed by the Wine license. winedbg _binaries_ compiled with --enable-readline quite possibly. As far as the source code to winedbg is concerned maybe but probably not. It might depend on whether --enable-readline or --disable-readline is the default, but that remains to be tested in court, but it is not certain it matters at all. The court might quite reasonably rule that no linking to readline has taken place yet and thus no derived work can have been created and even if they hold that some sort of linking has taken place it might not consider it a derived work. In short linking, especially potential linking, do not always imply a derived work which is all that matters as far as the law is concerned. Also note that I'm not convinced that any court will hold that the GPL is different from the LGPL in any relevant way with the possible exception of in bad faith trying to circumvent the requirements by trying to be "clever". Of course it is a little unclear that you really can do unlawful circumvention of license requirements. This is a like claiming that somebody circumvented trespassing your land by moving around it. Either you trespass or you do not. Either you violate the license or you do not. The analogy is quite good even in other areas: Even if you are on somebodies land you do not nessary trespass either because of copyright like "fair use" requirements in the law of most countries. As a sidenote: In Sweden "fair use" concerning trespass is so extensive that I never heard about _any_ case concerning it. > I think the benefit of using readline in the debugger is much too > small to justify the potential license issues this would cause. Only the debugger (winedbg) links with readline => only the debugger can be effected. Trying to claim, even though you didn't, that Winelib is effected is absurd since it is independent of the debugger. Distributing the debugger with WineLib is merly an aggregation nothing more.

1 0

Re: PATCH: Move 16-bit COMM stuff to USER, where it belongs
by Alexandre Julliard June 19, 2001

June 19, 2001

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Move 16-bit COMM stuff to USER, where it belongs. While the idea of the patch is correct, I think it would be much better to fix the huge code duplication while everything is in the same file. The 16-bit stuff should be implemented on top of the 32-bit stuff, instead of duplicating most of it. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Use the libreadline in Winedbg, if available
by Alexandre Julliard June 18, 2001

June 18, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > No, it is enough that it is GPL compatible which the Wine license is. But then the code can no longer be distributed under a non GPL compatible license, while this is allowed by the Wine license. I think the benefit of using readline in the debugger is much too small to justify the potential license issues this would cause. -- Alexandre Julliard julliard(a)winehq.com

1 0

Lost mail
by Alexandre Julliard June 18, 2001

June 18, 2001

Folks, I have been forced to change ISPs over the week-end, and it seems the old and new ISP couldn't agree on when to do the switch, so any mail sent to me during the week-end probably got forwarded to /dev/null. Also could people who submitted a patch to wine-patches please send me a private copy? I know they are on the mailing list archive, but it makes my life a lot easier to have everything in my mail box. Thanks. -- Alexandre Julliard julliard(a)winehq.com

1 0

set_file_pointer and 64 bit file access
by Bill Medland June 18, 2001

June 18, 2001

I see we are in the middle of converting set_file_pointer towards 64 bit file systems. Currently the code is confused as to when to change from unsigned to signed int for the low 32 bits. Should it happen in SetFilePointer before sending the request (which means we end up changing the request format) or should it happen within set_file_pointer (after changing the argument back to a signed int; this would also require work in SetFilePointer to get it to set up the request correctly). Any views? Bill

1 0

RE: Use the libreadline in Winedbg, if available
by Ove Kaaven June 18, 2001

June 18, 2001

On Mon, 18 Jun 2001, Patrik Stridvall wrote: > A minor notice. Readline is GPL:ed (not LGPL:ed) which is not so good. > While it is without doubt legal for us to use and distribute, > it might cause trouble for other people. Not as long as it's optional (that patch even supported ./configure --without-readline, so no trouble, such people would just disable it).

1 0

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall June 18, 2001

June 18, 2001

> On Mon, Jun 18, 2001 at 04:10:14PM +0200, Uwe Bonnes wrote: > > Hallo, > > > > at present, wine uses unconditionally a self supplied readline > > function. Appended patch tries to find out if libreadline > is available > > and uses libreadline if available. I configured with and without > > libreadline and successfully compiled winedbg on my system. > > libreadline is a static library on my system and winedbg > grew 90 kByte > > stripped and 110 kByte compiled with -g. > > You are not allowed to link readline aganst non GPL code to > my knowledge. No, it is enough that it is GPL compatible which the Wine license is. Whether we should is another matter though. Just linking it to the debugger is rather harmless IMHO though.

2 1

Re: Use the libreadline in Winedbg, if available
by Marcus Meissner June 18, 2001

June 18, 2001

On Mon, Jun 18, 2001 at 04:10:14PM +0200, Uwe Bonnes wrote: > Hallo, > > at present, wine uses unconditionally a self supplied readline > function. Appended patch tries to find out if libreadline is available > and uses libreadline if available. I configured with and without > libreadline and successfully compiled winedbg on my system. > libreadline is a static library on my system and winedbg grew 90 kByte > stripped and 110 kByte compiled with -g. You are not allowed to link readline aganst non GPL code to my knowledge. Ciao, Marcus

1 0

Dosvm not initialized for Direct port access
by Uwe Bonnes June 18, 2001

June 18, 2001

Hallo, some license manager dll (lmgr327a) manages to read IOPORT 0x40 from 32-bit code. This results in an access to Dosvm.GetTimer() in line 297 in ioports.c, and as Dosvm isn't initialized this results in a crash. =>0 0x00000000 (ebp=404e4b38) 1 0x400cd595 (IO_inport+0x205(port=0x40, size=0x1) [ioports.c:297] in libntdll.so) (ebp=404e4b38, null call assumed) 2 0x400a7405 (INSTR_inport+0x25(port=0x40, size=0x1, context=0x404e4c50) [instr.c:328] in libntdll.so) (ebp=404e4b58) 3 0x400a888c (INSTR_EmulateInstruction+0x12cc(context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50) [instr.c:745] in libntdll.so) (ebp=404e4bc4) 4 0x400733c9 (do_segv+0x109(context=0x404e4c50, trap_code=0xd, cr2=0x0, err_code=0x0) [signal_i386.c:671] in libntdll.so) (ebp=404e4c2c) 5 0x4007368d (segv_handler+0x3d(__signal=0xb, __context=0x0) [signal_i386.c:787] in libntdll.so) (ebp=404e4d1c) 6 0x4029fb58 (__restore [sigaction.c] in libc.so.6) (ebp=405f57a0) 7 0x1c0b0004 (LMGR327A.DLL..reloc+0xbfe2004) (ebp=04007242) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

16-bit and 32-bit separation
by Patrik Stridvall June 18, 2001

June 18, 2001

[Since the subject it up because of Dimitry's "Move 16-bit COMM stuff to USER, where it belongs" patch] My new tool winapi_fixup could without to much effort be extended to facillitate separation of 16-bit and 32-bit stuff by moving the 16-bit parts of a file (example: foo.c) to a new 16-bit only file (example: foo16.c). Of course because of dependecies, includes and such things it can only be partly automatic and it will in most cases require quite a lot editing afterwards, so the questions (primarily to Alexandre but other replies welcome to) are: 1. Will/Should Alexandre accept such patches at all? 2. Is it a useful effort to get the 16-bit stuff out of the way so we don't have to see it in the files when editing the 32-bit stuff? 3. Is it a useful effort to make it possible to have --disable-win16 configure option to compile out as much Win16 stuff as possible in order to save space in the binaries for say embedded stuff. 4. While this certainly it not a high or even medium priority effort, should it have low, very low or extremly low priority? PS. I have other stuff planed so I certainly do not lack things to do. However since the subject is up I might just as well ask.

1 0

SIGSEGV while trying to run Word97
by Heiko Nardmann June 17, 2001

June 17, 2001

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am continously getting a dialog "Nicht genügend Arbeitsspeicher oder unzureichender Speicherplatz, um Word auszuführen" (German version). After trying to examine this problem with debugmsg all (without real success) I added an strace call to the whole call. This resulted in a log file which tells me that a SIGSEGV occurrs. Here is a part of the strace log file which contains the SIGSEGV message. After that the appropriate 'debugmsg all' part follows. What can be done to shed more light onto this problem? strace log: write(2, "08069280:trace:win32:_LeaveSysLe"..., 112) = 112 write(2, "08069280:Ret user32.CreateWindo"..., 68) = 68 write(2, "08069280:RET mso97.486: _MsoCre"..., 84) = 84 write(2, "08069280:trace:heap:HeapFree (40"..., 74) = 74 write(2, "08069280:Call kernel32.GetVersio"..., 49) = 49 write(2, "08069280:Ret kernel32.GetVersio"..., 65) = 65 write(2, "08069280:Call kernel32.GetVersio"..., 60) = 60 write(2, "08069280:Ret kernel32.GetVersio"..., 68) = 68 write(2, "08069280:Call kernel32.GlobalMem"..., 65) = 65 time(NULL) = 992531763 time(NULL) = 992531763 open("/proc/meminfo", O_RDONLY) = 11 fstat(11, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4035c000 read(11, " total: used: free:"..., 1024) = 319 read(11, "", 1024) = 0 close(11) = 0 munmap(0x4035c000, 4096) = 0 write(2, "08069280:Ret kernel32.GlobalMem"..., 73) = 73 write(2, "08069280:CALL mso97.394: _MsoFCr"..., 147) = 147 write(2, ") ret=30011010\n", 15) = 15 write(2, "08069280:Call kernel32.VirtualAl"..., 86) = 86 write(2, "08069280:trace:virtual:VirtualAl"..., 68) = 68 mmap2(NULL, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOSYS (Function not implemented) old_mmap(NULL, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40e90000 munmap(0x40ea0000, 65536) = 0 write(2, "View: 40e90000 - 40e9ffff (vallo"..., 35) = 35 write(2, " 40e90000 - 40e9ffff -----\n", 32) = 32 write(2, "08069280:Ret kernel32.VirtualAl"..., 67) = 67 write(2, "08069280:Call kernel32.VirtualAl"..., 86) = 86 write(2, "08069280:trace:virtual:VirtualAl"..., 68) = 68 write(2, "08069280:trace:virtual:VIRTUAL_S"..., 63) = 63 mprotect(0x40e90000, 4096, PROT_READ|PROT_WRITE) = 0 write(2, "View: 40e90000 - 40e9ffff (vallo"..., 35) = 35 write(2, " 40e90000 - 40e90fff c-rW-\n", 32) = 32 write(2, " 40e91000 - 40e9ffff -----\n", 32) = 32 write(2, "08069280:Ret kernel32.VirtualAl"..., 67) = 67 - --- SIGSEGV (Speicherzugriffsfehler) --- write(2, "08069280:RET mso97.394: _MsoFCr"..., 126) = 126 rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM IO], [], 8) = 0 write(5, "F\0\0\0\0\0\34\1<\0336@\1\0\0\0\304\357\17@\0\0\0\0\0\0"..., 64) = 64 read(6, "F\0\0\0\0\0\34\1\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 write(2, "08069280:trace:seh:EXC_CallHandl"..., 87) = 87 write(2, "08069280:trace:seh:EXC_RtlUnwind"..., 55) = 55 write(2, "08069280:trace:seh:EXC_CallHandl"..., 87) = 87 write(2, "08069280:trace:seh:EXC_CallHandl"..., 54) = 54 - --- SIGSEGV (Speicherzugriffsfehler) --- write(2, "08069280:trace:seh:EXC_RtlRaiseE"..., 63) = 63 rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM IO], [], 8) = 0 write(5, "F\0\0\0\0\0\34\1<\0336@\1\0\0\0\304\357\17@\0\0\0\0\0\0"..., 64) = 64 read(6, "F\0\0\0\0\0\34\1\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 wine debug log: 08069280:trace:win32:_LeaveSysLevel (0x40753a74, level 2): thread 0x8069280 (fs 008f, pid 24063) count after 0 08069280:Ret user32.CreateWindowExW() retval=00000138 ret=306cc216 08069280:RET mso97.486: _MsoCreateMonitorWindow(a)0() retval = 00000000 ret=3000162f 08069280:trace:heap:HeapFree (40360000,00000002,403a4a80): returning TRUE 08069280:Call kernel32.GetVersion() ret=30001984 08069280:Ret kernel32.GetVersion() retval=05650004 ret=30001984 08069280:Call kernel32.GetVersionExA(405c686c) ret=300019b5 08069280:Ret kernel32.GetVersionExA() retval=00000001 ret=300019b5 08069280:Call kernel32.GlobalMemoryStatus(405c6900) ret=300019e2 08069280:Ret kernel32.GlobalMemoryStatus() retval=405c6900 ret=300019e2 08069280:CALL mso97.394: _MsoFCreateIPref(a)28(<unknown, check return>08069280:trace:heap:HeapAlloc (40360000,00000002,00000040): returning 403a4b98 ) ret=30011010 08069280:Call kernel32.VirtualAlloc(00000000,0000fffc,00002000,00000001) ret=3070b360 08069280:trace:virtual:VirtualAlloc 00000000 0000fffc 2000 00000001 View: 40e90000 - 40e9ffff (valloc) 40e90000 - 40e9ffff ----- 08069280:Ret kernel32.VirtualAlloc() retval=40e90000 ret=3070b360 08069280:Call kernel32.VirtualAlloc(40e90000,00001000,00001000,00000004) ret=3070b38b 08069280:trace:virtual:VirtualAlloc 40e90000 00001000 1000 00000004 08069280:trace:virtual:VIRTUAL_SetProt 40e90000-40e90fff c-rW- View: 40e90000 - 40e9ffff (valloc) 40e90000 - 40e90fff c-rW- 40e91000 - 40e9ffff ----- 08069280:Ret kernel32.VirtualAlloc() retval=40e90000 ret=3070b38b 08069280:RET mso97.394: _MsoFCreateIPref(a)28(30011020,00000000,08069280:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 08069280: queue_exception_event( first=1, record={context={flags=00000000,eax=00000000,ebx=400fefc4,ecx=4d535744,edx=00000000,esi=00000000,edi=00000007,ebp=405c6790,eip=400c8aca,esp=405c66cc,eflags=00010246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400c8aca,params={0,4d535744}} ) 08069280: queue_exception_event() = 0 { handle=0 } 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005b520 code=c0000005 flags=0 08069280:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005ad80 code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler handler returned 1 08069280:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 08069280: queue_exception_event( first=1, record={context={flags=00000000,eax=00000000,ebx=400fefc4,ecx=4d535744,edx=00000000,esi=00000000,edi=00000007,ebp=405c6790,eip=400c8baa,esp=405c66cc,eflags=00010246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400c8baa,params={0,4d535744}} ) 08069280: queue_exception_event() = 0 { handle=0 } 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005b520 code=c0000005 flags=0 08069280:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler calling handler at 0x4005ad80 code=c0000005 flags=2 08069280:trace:seh:EXC_CallHandler handler returned 1 - -- 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 iD8DBQE7KcuPpm53PRScYygRAlfZAJ91r/8CwDzWpu0TU0vB+FRP18w14QCg4sCK GBnoWm0xkKgHgFucJcNrsno= =8hel -----END PGP SIGNATURE-----

5 6

CS_PARENTDC problems
by Malte.Starostik＠t-online.de June 17, 2001

June 17, 2001

Hi, we had some serious painting problems with dialog from an ActiveX control. All controls were invisible and only showed up sometimes on getting or losing focus. The cause is a custom class "_BitmapClass" that draws a logo and has the CS_PARENTDC class style (and no other class styles FWIW). Its WM_ERASEBKGND handler fills the complete dialog rect with that default Win95-Desktop-Background colour. According to the Win32 docs winelib behaves correctly wrt CS_PARENTDC and clipping. In this case it'd be Macromedia's fault as to how they implemented that window. However, I just found http://msdn.microsoft.com/library/techart/msdn_classy32.htm: <classy> If you use the CS_PARENTDC style for a class, each window in that class uses its parent window's DC. CS_PARENTDC is similar to CS_CLASSDC in that multiple windows share one DC. In CS_PARENTDC, however, the windows that share the DC need not belong to the same class. </classy> This contradicts the API docu at http://msdn.microsoft.com/library/psdk/winui/winclass_3b1v.htm: <api docs> CS_PARENTDC Sets the clipping rectangle of the child window to that of the parent window so that the child can draw on the parent. A window with the CS_PARENTDC style bit receives a regular device context from the system's cache of device contexts. It does not give the child the parent's device context or device context settings. Specifying CS_PARENTDC enhances an application's performance. <api docs> a little later, this is as near as the "classy" text comes to clipping: <classy> Another outcome of the CS_PARENTDC style is that child windows can draw anywhere in their parent's client area as well as drawing in their own client area. The CTL3D library, which creates 3-D effects around edit controls and list boxes, relies on this behavior. An application should not use CS_PARENTDC if it needs to adjust the mapping modes for different child windows. This will negate much of the benefit and could cause problems ensuring that each child window has the correct mapping mode set. </classy> Then I tried on Windows (2000), created a window with a child that has CS_PARENTDC set and * The paint rect of the PAINTSTRUCT as intialized by BeginPaint() equals the window's client rect - as expected. * but - surprise - so does the DC's clip box and trying to largen it to cover some or all areas of the parent fail and of course any drawing on the parent fails. * same for the DC returned by GetDC(hWnd) * only GetDCEx(hWnd, 0, DCX_PARENTCLIP) returns a DC that allows painting on the parent (no difference to a non-CS_PARENTDC window though) So, how is this painting on the parent with that style flag supposed to work? The things above make me think that it isn't possible at all or requires some additional steps. This would at least explain why the dialog described above looks busted in wine. If anyone could confirm my observations I'd come up with a patch. Thanks for any info, -Malte -- Wars don't determine who's right, only who's left.

1 0

Re: PATCH: wine-config
by Andreas Mohr June 17, 2001

June 17, 2001

On Sun, Jun 17, 2001 at 10:26:34AM +0200, Marcus Meissner wrote: > Hi, > > to help winelib using developers, this program exports flags and directories > to /usr/bin/. > > I am not sure whether exported cflags and libs are ok. > > Hmm, we probably should also tell how to build .so libs. And specs -> .cs. > (Hmm, supply Makefile snippets?) > > Ciao, Marcus > > Changelog: > Added a 'wine-config' for winelib developers. I don't think this is a good idea. That way it'll get confused with wineconf within fractions of a second... I'd much rather use a name like wlib-config or winelib-config instead. -- Andreas Mohr

1 0

wrc error
by Bang Jun-Young June 14, 2001

June 14, 2001

Hi, I got the following error when I tried to compile the latest CVS source: gmake[2]: Entering directory `/home/bjy/wine/dlls/user' LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/wrc/wrc -I. -I. -I../../include -I../../include -o resources/user32.res -r resources/user32.rc resources/user32_Ca.rc:2:1: Error: syntax error gmake[2]: *** [resources/user32.res] Error 1 After downgrading some files in wrc to earier revisions, Wine was successfully compiled again. I suspect that Francois Gouget's commit made on 2001-06-07 causes this. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

2 1

Re: Hangs in half-life menus (design problem in new queue code)
by Alexandre Julliard June 14, 2001

June 14, 2001

Ove Kaaven <ovehk(a)ping.uio.no> writes: > The new message queue design doesn't seem to allow this to be fixed... > or does it? Working on it... -- Alexandre Julliard julliard(a)winehq.com

1 0

Hangs in half-life menus (design problem in new queue code)
by Ove Kaaven June 14, 2001

June 14, 2001

The new message queue code has caused the half-life menus to hang, since it handles timers slightly differently now. Now: - User moves mouse over a menu item - On mouseover, game starts a window timer (55ms) - On each WM_TIMER, game redraws the menu item. This takes longer than 55ms - After drawing, it checks messages. Since the 55ms timer has expired, another WM_TIMER is received, item is redrawn, any user input is ignored. Repeat Before, the hardware input queue was checked before WM_PAINT and WM_TIMER was checked, so the user could move the cursor away from the menu item (which would cancel the timer). With the new code, the hardware input queue (x11drv.MsgWaitFor...) is checked *after* timers, so the menu is now completely stuck. The new message queue design doesn't seem to allow this to be fixed... or does it?

1 0

Re: virtual memory problems with Linux 2.4.5
by Alexandre Julliard June 14, 2001

June 14, 2001

Alexandre Julliard <julliard(a)winehq.com> writes: > Another related problem is that even without this bug, mmap64 will > always refuse to do an unaligned mmap, even if the kernel might have > accepted it (with kernel 2.2.x for instance). Maybe the best solution > would be to directly call the mmap syscall instead of mmap2 when > mapping executables, this would fix both problems. OK, here we go. Could you please test this, especially people running kernel 2.4? Index: memory/virtual.c =================================================================== RCS file: /opt/cvs-commit/wine/memory/virtual.c,v retrieving revision 1.63 diff -u -r1.63 virtual.c --- memory/virtual.c 2001/06/13 20:13:20 1.63 +++ memory/virtual.c 2001/06/14 02:15:36 @@ -104,7 +104,8 @@ #define VIRTUAL_DEBUG_DUMP_VIEW(view) \ if (!TRACE_ON(virtual)); else VIRTUAL_DumpView(view) -static LPVOID VIRTUAL_mmap( int fd, LPVOID start, DWORD size, DWORD offset, int prot, int flags ); +static LPVOID VIRTUAL_mmap( int fd, LPVOID start, DWORD size, DWORD offset_low, + DWORD offset_high, int prot, int flags ); /* filter for page-fault exceptions */ static WINE_EXCEPTION_FILTER(page_fault) @@ -471,7 +472,7 @@ /* map the header */ - if (VIRTUAL_mmap( fd, ptr, header_size, 0, PROT_READ | PROT_WRITE, + if (VIRTUAL_mmap( fd, ptr, header_size, 0, 0, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_FIXED ) == (char *)-1) goto error; dos = (IMAGE_DOS_HEADER *)ptr; nt = (IMAGE_NT_HEADERS *)(ptr + dos->e_lfanew); @@ -533,7 +534,7 @@ sec->PointerToRawData, pos, sec->SizeOfRawData, size, sec->Characteristics ); if (VIRTUAL_mmap( shared_fd, (char *)ptr + sec->VirtualAddress, size, - pos, PROT_READ|PROT_WRITE|PROT_EXEC, + pos, 0, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED ) == (void *)-1) { ERR_(module)( "Could not map shared section %.8s\n", sec->Name ); @@ -555,7 +556,7 @@ * fall back to read(), so we don't need to check anything here. */ if (VIRTUAL_mmap( fd, (char *)ptr + sec->VirtualAddress, sec->SizeOfRawData, - sec->PointerToRawData, PROT_READ|PROT_WRITE|PROT_EXEC, + sec->PointerToRawData, 0, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE | MAP_FIXED ) == (void *)-1) { ERR_(module)( "Could not map section %.8s, file probably truncated\n", sec->Name ); @@ -650,6 +651,46 @@ } + +/*********************************************************************** + * unaligned_mmap + * + * Linux kernels before 2.4.x can support non page-aligned offsets, as + * long as the offset is aligned to the filesystem block size. This is + * a big performance gain so we want to take advantage of it. + * + * However, when we use 64-bit file support this doesn't work because + * glibc rejects unaligned offsets. Also glibc 2.1.3 mmap64 is broken + * in that it rounds unaligned offsets down to a page boundary. For + * these reasons we do a direct system call here. + */ +static void *unaligned_mmap( void *addr, size_t length, unsigned int prot, + unsigned int flags, int fd, unsigned int offset_low, + unsigned int offset_high ) +{ +#if defined(linux) && defined(__i386__) && defined(__GNUC__) + if (!offset_high && (offset_low & page_mask)) + { + int ret; + __asm__ __volatile__("push %%ebx\n\t" + "movl %2,%%ebx\n\t" + "int $0x80\n\t" + "popl %%ebx" + : "=a" (ret) + : "0" (90), /* SYS_mmap */ + "g" (&addr) ); + if (ret < 0 && ret > -4096) + { + errno = -ret; + ret = -1; + } + return (void *)ret; + } +#endif + return mmap( addr, length, prot, flags, fd, ((off_t)offset_high << 32) | offset_low ); +} + + /*********************************************************************** * VIRTUAL_mmap * @@ -657,15 +698,16 @@ * and falls back to read if mmap of a file fails. */ static LPVOID VIRTUAL_mmap( int fd, LPVOID start, DWORD size, - DWORD offset, int prot, int flags ) + DWORD offset_low, DWORD offset_high, int prot, int flags ) { int pos; LPVOID ret; + off_t offset; if (fd == -1) return wine_anon_mmap( start, size, prot, flags ); - if ((ret = mmap( start, size, prot, flags, fd, offset )) != (LPVOID)-1) - return ret; + if ((ret = unaligned_mmap( start, size, prot, flags, fd, + offset_low, offset_high )) != (LPVOID)-1) return ret; /* mmap() failed; if this is because the file offset is not */ /* page-aligned (EINVAL), or because the underlying filesystem */ @@ -687,6 +729,7 @@ ret = wine_anon_mmap( start, size, PROT_READ | PROT_WRITE, flags ); if (ret == (LPVOID)-1) return ret; /* Now read in the file */ + offset = ((off_t)offset_high << 32) | offset_low; if ((pos = lseek( fd, offset, SEEK_SET )) == -1) { munmap( ret, size ); @@ -1524,8 +1567,8 @@ shared_file, shared_size ); - if (size_high || offset_high) - ERR("Offsets larger than 4Gb not supported\n"); + if (size_high) + ERR("Sizes larger than 4Gb not supported\n"); if ((offset_low >= size_low) || (count > size_low - offset_low)) @@ -1570,7 +1613,7 @@ TRACE("handle=%x size=%x offset=%lx\n", handle, size, offset_low ); - ptr = (UINT)VIRTUAL_mmap( unix_handle, addr, size, offset_low, + ptr = (UINT)VIRTUAL_mmap( unix_handle, addr, size, offset_low, offset_high, VIRTUAL_GetUnixProt( prot ), flags ); if (ptr == (UINT)-1) { /* KB: Q125713, 25-SEP-1995, "Common File Mapping Problems and -- Alexandre Julliard julliard(a)winehq.com

5 5

clipped child
by lawson_whitney＠juno.com June 14, 2001

June 14, 2001

Good day! A little problem. Unhandled exception: page fault on read access to 0x00000067 in 32-bit code (0x40a25f4e). In 32-bit mode. 0x40a25f4e (clip_children+0x7e [winpos.c:83] in libx11drv.so): testb $0x10,0x67(%esi) 83 if (ptr->dwStyle & WS_VISIBLE) Lawson ---

1 0

RE: wine on Alpha (was: Help needed)
by Patrik Stridvall June 14, 2001

June 14, 2001

> > Still, you must be aware of a few thing. > > * Wine is not 100% byte order clean. > > Alpha seems to be "correct" endian ;) True. But what I meant was since the size of integer changes from 32 to 64 bits, any code that rely on the exact layout of memory might have problems becuase of this. This is not the same as the problem below where you have pointer truncation issues or because code expects that DWORD x; int y; x = y; will work correcly. But OK. I shold probably explained better what I meant. Anyway all code should be byte order clean regardless and making it so might solve some 32/64 bit byte layout problems as well. When you change to code for Alpha you might as well change it to work with big endian platforms as well. > > * Wine is not 64 bit clean. > > This is a little worse especially since > > Win32 often stores pointers in 32 bit integers > > and this problem really can't be solved in > > a good way, since extending the size of the storage > > is not possible at least not if you want to > > be able to implement a x86 emulator in the > > future. However I guess it will be possible > > to force all memory usage to be in the lower > > 32 bits of memory to be able to cope with > > truncated pointers. > > Digital has(d) a lot of very good emulation technologies - > FX!32 which let to run win32 386 apps on NT Alpha with > almost full speed, em86 which runs 386 Linux apps on Linux > Alpha (http://www.cs.rose-hulman.edu/~donaldlf/em86/index.html) > x86emu which is used in XFree86 and MILO to initialize > graphic card's 386 BIOS. True, but Wine might need something a little more than that and FX!32 doesn't have souce code available AFAIK. Of course that is perhaps not a problem for an internal Digital project. :-) Anyway, that is a later problem. Just making Winelib work might take some effort.

1 0

OT - a free windows screensaver?
by lawson_whitney＠juno.com June 14, 2001

June 14, 2001

Good day! After I got both my legs broke April 27, my computer and I have been a bit exposed to a small segment of the public, and everybody loves my screensaver. ftp://ftp.ibiblio.org/pub/Linux/utils/console/lockvc-3.9.1.tar.gz Of course, I may have a hard time to get them to install Linux just for a screensaver, so I thought I might see about porting it to windose. A sample or something to plagiarize from would be good, I think. I haven't figured out how to work mingw either, but maybe inspiration will come. Regards, Lawson ---cut here--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

interrupts
by Eugene Toichkin June 14, 2001

June 14, 2001

Hi! I have to run the add-on card with Windows controlling program on my linux box. That card generates the interrupt and requires some port addresses. Is any way to configure WINE to run that kind of application on Linux host? -- Best regards, Eugene Toichkin ugin(a)itc.mecom.ru

1 0

Re: Re: virtual memory problems with Linux 2.4.5
by Mike McCormack June 13, 2001

June 13, 2001

Seems ok to me also, after a quick test. Mike Original message from: lawson_whitney(a)juno.com > > > >On 13 Jun 2001, Alexandre Julliard wrote: > >> OK, here we go. Could you please test this, especially people running >> kernel 2.4? >> >> Index: memory/virtual.c > >Looks good to me. First problem app runs OK, and you get this by the >second one. > >gcc version 2.95.3 20010315 (release) >/lib/libc.so.6 -> libc-2.1.3.so* >Linux giftie 2.4.5 #1 Sat Jun 2 11:23:22 EDT 2001 i586 unknown > >Lawson ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Drawing problems with ControlSpy
by Guy L. Albertelli June 13, 2001

June 13, 2001

With today's CVS (last patch was "wine/ dlls/gdi/wing.c dlls/kernel/comm.c dlls/ ..."), the following problems exist in the ControSpy (REBAR) test program: Problem #1. Using native version of "commctrl,comctl32", get the following fault: /home/albertel/t1/wine/wine -managed -winver win95 -dll commctrl,comctl32=n G:\Rdhat\test-pgm\controls\rebar.exe Could not stat /mnt/winflp (No such file or directory), ignoring drive A: fixme:pthread_kill_other_threads_np Could not stat /mnt/winflp (No such file or directory), ignoring drive A: WineDbg starting... on pid 8064ef0 ...... Unhandled exception: page fault on read access to 0x00000067 in 32-bit code (0x40894f24). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x40894f24 (clip_children+0x24 [winpos.c:70] in libx11drv.so): testb $0x10,0x67(%esi) 70 if (ptr->dwStyle & WS_VISIBLE) break; Wine-dbg>bt Backtrace: =>0 0x40894f24 (clip_children+0x24(win=0x403732dc, last=0x40373370, hrgn=0xa22, whole_window=0x0) [winpos.c:70] in libx11drv.so) (ebp=40586564) 1 0x4089511e (get_visible_region+0x14e(win=0x40373370, top=0x403732dc, flags=0x1001a, mode=0x1) [winpos.c:144] in libx11drv.so) (ebp=405865a4) 2 0x408952ec (X11DRV_GetDC+0x1a8(hwnd=0x1908, hdc=0x88, hrgn=0x0, flags=0x1001a) [winpos.c:229] in libx11drv.so) (ebp=405865e8) 3 0x406874bc (GetDCEx+0x29c(hwnd=0x1908, hrgnClip=0x0, flags=0x10000) [dce.c:531] in libuser32.so) (ebp=40586620) 4 0x4068755c (GetDC+0x2c(hwnd=0x1908) [dce.c:561] in libuser32.so) (ebp=40586638) 5 0xbfb9a055 (COMCTL32.DLL.InitCommonControlsEx+0x4137 in C:\WINDOWS\SYSTEM\COMCTL32.DLL) (ebp=40586694) 6 0xbfb9a037 (COMCTL32.DLL.InitCommonControlsEx+0x4119 in C:\WINDOWS\SYSTEM\COMCTL32.DLL) (ebp=405867fc) 7 0xbfb94e38 (COMCTL32.DLL.ImageList_GetIconSize+0x558 in C:\WINDOWS\SYSTEM\COMCTL32.DLL) (ebp=40586854) 8 0x406b24a7 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=40586878) 9 0x406b2520 (WINPROC_CallWndProc+0x70(proc=0xbfb94a89, hwnd=0x1908, msg=0x81, wParam=0x0, lParam=0x40586b10) [winproc.c:171] in libuser32.so) (ebp=405868a0) The following patch bypasses the tests: --- wine/dlls/x11drv/winpos.c Wed Jun 13 20:03:34 2001 +++ mywine/dlls/x11drv/winpos.c Wed Jun 13 22:59:18 2001 @@ -65,6 +65,9 @@ HRGN rectRgn; int x, y; + /* if no children then nothing to do */ + if (!win->child) return; + /* first check if we have anything to do */ for (ptr = win->child; ptr != last; ptr = ptr->next) if (ptr->dwStyle & WS_VISIBLE) break; Problem # 2. With above patch and still using native comctl32 get the following: /home/albertel/t1/mywine/wine -managed -winver win95 -dll commctrl,comctl32=n G:\Rdhat\test-pgm\controls\rebar.exe Could not stat /mnt/winflp (No such file or directory), ignoring drive A: err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:x11drv:X11DRV_SetDeviceClipping Rgn is 0. Please report this. ##normal exit from wine## Problem # 3. Still with native comctl32. With more than 1 band in a row, when you drag a band from left to right, the band being uncovered is not fully repainted (suspect InvalidateRect too small). This is especially visible if the band being dragged is a different color. It is also sensitive to the speed of the drag. Attached is a control file to create different color bands in a row. If you need any more information, let me know what. I will be doing more work tomorrow night. Thanks, Guy

1 0

Re: wine/windows/x11drv event.c
by Guy L. Albertelli June 13, 2001

June 13, 2001

> >Log message: > Force invalidating of siblings children on expose event. > This seems to allow ControlSpy (rebar) to draw its children again, but exposes some other drawing problems. The symptom is that certain areas do not seem to be invalidated correctly. If the window is overlayed with another the everything is redrawn correctly. I will attempt to get documentation later tonight. Thanks, Guy

1 0

RE: Help needed
by Patrik Stridvall June 13, 2001

June 13, 2001

I'm sorry for not answering earlier. I saw your message but I didn't have time to answer it at the time and then a forgot about it. In truth I wasn't very eager about answering either since I have answered far to many people that just asked questions and then didn't contribute anything because I guess that they felt it was to difficult or to much work. I didn't notice that you were from Digital either, but after reading Kernel Cousin Wine #97 I was made aware of that fact. While it is possible that you are yet another of those people I talked about above, since you are from Digital I will take some time to answer your questions. Note however that I'm not at all unwilling to answer questions. It is just that it has felt like a wasted effort in the past. > We are planning to port wine onto Tru64 Unix. I have some > basic Questions. OK. Sound good. > Can you tell me how to go about it. Yes. But it is better if you ask more specific questions. > How do we start. You try to get it to compile and link. This shouldn't be to difficult. While I never used Tru64 I expect it supports all things Wine will need. > How big > is the task and Well, if you want the emulator (Wine) to work it will be a humongous task, since you will have to emulate x86 instructions on the Alpha among other things. However if you just want the porting tool (Winelib) to work it will be a little easier. Still, you must be aware of a few thing. * Wine is not 100% byte order clean. However there have been some attempts to port it to Sparc which is big endian so don't if I think it is that bad and the remaining problems can be fixed without to much effort. * Wine is not 64 bit clean. This is a little worse especially since Win32 often stores pointers in 32 bit integers and this problem really can't be solved in a good way, since extending the size of the storage is not possible at least not if you want to be able to implement a x86 emulator in the future. However I guess it will be possible to force all memory usage to be in the lower 32 bits of memory to be able to cope with truncated pointers. * Then of course you have Tru64 specific problem. However I don't expect them to be so bad. > how to start about it.. Well as I said. Try to compile and link it. Then try to get some of the simple examples in wine/programs to run.

2 1

Re: virtual memory problems with Linux 2.4.5
by Alexandre Julliard June 12, 2001

June 12, 2001

Mike McCormack <mike_mccormack(a)start.com.au> writes: > your patch produced a yes, BUT when i changed the offset value to > 0x400, and it failed ... see new patch below. That's a bug in glibc 2.1.3. This is from the mmap64 source: [offset is in ecx:edx] testl $0x3ff, %edx jne L(einval) shrdl $12, %ecx, %edx /* mmap2 takes the offset in pages. */ shrl $12, %ecx But of course 0x3ff only tests 10 bits, not 12, so if bits 10 or 11 are set they will be silently dropped. This has been fixed in glibc-2.2. Another related problem is that even without this bug, mmap64 will always refuse to do an unaligned mmap, even if the kernel might have accepted it (with kernel 2.2.x for instance). Maybe the best solution would be to directly call the mmap syscall instead of mmap2 when mapping executables, this would fix both problems. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: virtual memory problems with Linux 2.4.5
by Alexandre Julliard June 12, 2001

June 12, 2001

Mike McCormack <mike_mccormack(a)start.com.au> writes: > i have found a problem with Wine and the Linux 2.4.5 Kernel. > The Kernel no longer return EINVAL when offsets are not page > aligned... it simply does the mapping ignoring the lower bits of the > offset. This small patch fixes that problem. That's a glibc bug IMO. What version are you using? -- Alexandre Julliard julliard(a)winehq.com

3 5

Re: Re: virtual memory problems with Linux 2.4.5
by Mike McCormack June 12, 2001

June 12, 2001

Hi Marcus, your patch produced a yes, BUT when i changed the offset value to 0x400, and it failed ... see new patch below. something strange is going on ... ;-) Mike >Could you please apply following check to configure.in, then do: > autoconf > rm config.cache > ./configure > >and check whether mmap64 detects as 'no' and check the output of config.log ? > >Ciao, Marcus > >Index: configure.in .. Index: configure.in =================================================================== RCS file: /home/wine/wine/configure.in,v retrieving revision 1.208 diff -u -r1.208 configure.in --- configure.in 2001/06/08 19:34:57 1.208 +++ configure.in 2001/06/13 01:28:16 @@ -538,6 +538,10 @@ ) { exit(1); } + if (-1!=mmap(0,2,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x400)){ + fprintf(stderr,"mapped at non aligned offset?\n"); + exit(2); + } close(fd); fprintf(stderr,"success!\n"); exit(0); ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

PNG or no PNG
by Igor Furlan June 12, 2001

June 12, 2001

On Tue, 12 June 2001, Francois Gouget wrote: > Still, quite often I noticed that JPEG is not very good for screenshots: > - screenshots often have large uniform surfaces, e.g. title bar, window > background... JPEG tends to render these with weird dithering-like > patterns. > - it tends to blur fonts. I believe that's because fonts are basically > thin lines, which means high frequency, which is exactly what JPEG's > lossy compression removes. start using PNG format... it is supported by netscape 4.x, mozilla, opera... and yes, big surprise.. it is supported by redmond too Igor

1 0

Re: FYI: ControlSpy has stopped working
by Alexandre Julliard June 12, 2001

June 12, 2001

520053692817-0001(a)t-online.de (Andreas Mohr) writes: > Well, this simply means there will be no "official" Wine release for some time > to come. > We have two possibilities: > 1. do major changes and debug until it's ready, then commit it > 2. do major changes, commit them and wait for the patches to arrive > > Obviously 2. means there will be *no* new official release before it's fixed > in its entirety (or at least only relatively "trivial" bugs remain). Well, not exactly; the release will be made once I no longer have any bug reports to work on. So if you feel the code is not ready for release, you better send me bug reports... So far the things I'm working on are: - ScrollWindow doesn't always get exposure events - client rect must be empty for zero size window - must create X window before WM_NCCREATE - hardware events priority order is messed up - ControlSpy refresh (?? needs more details) So if you see problems that are not listed here, you have to report them or they won't get fixed before the release. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Make ChooseFontW use ChooseFontA
by Alexandre Julliard June 12, 2001

June 12, 2001

Ian Pilcher <ian.pilcher(a)home.com> writes: > ChooseFontW was not returning the iPointSize member, and possibly > others. This patch rewrites ChooseFontW to convert all its inputs to > ASCII, call ChooseFontA, and convert the outputs back to Unicode. It would be much better to make ChooseFontA call ChooseFontW instead; converting Unicode to ASCII must be avoided as much as possible. -- Alexandre Julliard julliard(a)winehq.com

2 1

OT: BSD License ?
by Bob June 12, 2001

June 12, 2001

If Microsoft picked up some of the code in Wine , wouldn't they need to include the copyright , permissions notice, and the authors list? It looks like the license isn't clear as to where the Copyright needs to be displayed? Could anyone clear this up? Daniel Walker

3 4

Missing functionality in mmaux
by Florian Bauer June 12, 2001

June 12, 2001

Hi, I tried to run Naturally Speaking, a speech recognition software under wine without a real windows installation. It installs just fine, but when I try to run it, it tries to adapt the audio settings. That fails, and I get the following fixme's from wine: fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000007) fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000008) I looked at the sources, and it seems that this is due to missing case clauses in the function MIX_GetLineInfo in mixer.c . Unfortunately, I don't know enough about C programming and the Windows and OSS API's involved to add the missing parts myself. Is it likely that this will be fixed soon? I would love to use NatSpeak under linux, because then I could delete my Windows 98 Partition... Anyway, keep up the good work regards Florian

4 3

Re:Missing functionality in mmaux
by Eric Pouech June 12, 2001

June 12, 2001

> It installs just fine, but when I try to run it, it tries to adapt the audio > settings. That fails, and I get the following fixme's from wine: > > fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000007) > fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000008) it just misses the wavein component types as a quick fix, you can try to duplicate the case MIXERLINE_COMPONENTTYPE_MIC with MIXERLINE_COMPONENTTYPE_WAVEIN, but I'm not sure it'll fix all your issues, and let the program fully run. I'll have a closer look at it this week-end, if I have some time A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

1 0

Re: Re: virtual memory problems with Linux 2.4.5
by Mike McCormack June 11, 2001

June 11, 2001

i'm using Suse linux 7.0 with the following files: /usr/lib/libg++-3-libc6.1-2-2.8.1.3.so /lib/libc.so.6 i've upgrade the kernel and various bits and pieces, but not the C libraries. i think there was a discussion about changes to the mmap interface on KT at some time... Mike Original message from: Alexandre Julliard <julliard(a)winehq.com> > >Mike McCormack <mike_mccormack(a)start.com.au> writes: > >> i have found a problem with Wine and the Linux 2.4.5 Kernel. >> The Kernel no longer return EINVAL when offsets are not page >> aligned... it simply does the mapping ignoring the lower bits of the >> offset. This small patch fixes that problem. > >That's a glibc bug IMO. What version are you using? > >-- >Alexandre Julliard >julliard(a)winehq.com >. > ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: winapi_extract and winapi_fixup
by Alexandre Julliard June 11, 2001

June 11, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > Here is some new tools that is and will be > more useful in the future. If anybody > wishes to test them they should consider > them prealpha. I'd prefer if you put everything inside the winapi_check directory. Having 4 different directories for such similar tools is a bit overkill IMO. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: FYI: ControlSpy has stopped working
by Guy L. Albertelli June 11, 2001

June 11, 2001

-----Original Message----- From: Alexandre Julliard <julliard(a)winehq.com> To: andi(a)rhlx01.fht-esslingen.de <andi(a)rhlx01.fht-esslingen.de> Cc: Gerard Patel <gerard.patel(a)nerim.net>; Wine Devel <wine-devel(a)winehq.com> Date: Monday, June 11, 2001 4:52 PM Subject: Re: FYI: ControlSpy has stopped working >- ControlSpy refresh (?? needs more details) > The ControlSpy problem seems to be related to not repainting children windows of the rebar control. The attached traces show (+x11drv,+win,+rebar) for the 6/1 and 6/9 CVS. The 6/9 has submitted patch for zero client rect applied. If you want the full traces, let me know. Thanks, Guy Albertelli

1 0

Problems with GetFileVersionInfo[Size]()
by Malte.Starostik＠t-online.de June 11, 2001

June 11, 2001

Hi, The Shockwave ActiveX control I'm loading tries to read the VERSIONINFO resource from my winelib app. AFAICS it subsequently crashes because that fails. Anyway, there seems to be a problem: char path[PATH_MAX]; GetModuleFileName(inst, path, sizeof(path)); kdDebug() << "GetModuleFileName: " << path << endl; DWORD dummy; kdDebug() << "GetFileVersionInfoSize: " << GetFileVersionInfoSize(path, &dummy) << endl; kdDebug() << "GetLastError: " << GetLastError() << endl; outputs activexproxy: GetModuleFileName: Y:\src\kde\build\kdenonbeta\activexproxy\proxy\activexproxy activexproxy: GetFileVersionInfoSize: 0 activexproxy: GetLastError: 0 which means it obviously doesn't find the resource. (btw, why is GetLastError() 0 here?) However, this code suceeds (inst is the HINSTANCE passed to WinMain()): HRSRC ver = FindResource(inst, MAKEINTRESOURCE(VS_VERSION_INFO), MAKEINTRESOURCE(VS_FILE_INFO)); kdDebug() << "FindResource: " << ver << endl; int size = SizeofResource(inst, ver); kdDebug() << "SizeofResource:" << size << endl; HGLOBAL mem = LoadResource(inst, ver); void *buf, *block = LockResource(mem); UINT len; VerQueryValue(block, "StringFileInfo\\040904b0\\FileDescription", &buf, &len); kdDebug() << "Description: " << reinterpret_cast<WCHAR *>(buf) << endl; FreeResource(mem); the output is: activexproxy: FindResource: 1078760168 activexproxy: SizeofResource:608 activexproxy: Description: ActiveX-Proxy for Konqueror So basically the code GetFileInfoVersion[Size]() use to load a library fail if the given path is the winelib app (the symlink to wine) itself :( Thanks, -Malte -- Wars don't determine who's right, only who's left.

1 0

New Application Database is ONLINE
by Jeremy Newman June 11, 2001

June 11, 2001

Hey all! The 'shiny' new Wine Application Database is up and ready for your comments. We will be spending the rest of the day getting the initial category structure and 1st round off applications in. Once we have enough input, and we fell stable enough, I will link the AppDB to Winehq.com and post to wine-users. http://wine.codeweavers.com/appdb/ There is one sample app in so far so you can see what we mean. in: Main > Utilities > Compression > WinZip Use that as a guideline for how this is going to work. Go at it guys! -- _ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://jnewman.codeweavers.com | .` / -_) V V / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

1 0

New Application Database is ONLINE
by Jeremy Newman June 11, 2001

June 11, 2001

Hey all! The 'shiny' new Wine Application Database is up and ready for your comments. We will be spending the rest of the day getting the initial category structure and 1st round off applications in. Once we have enough input, and we fell stable enough, I will link the AppDB to Winehq.com and post to wine-users. http://wine.codeweavers.com/appdb/ There is one sample app in so far so you can see what we mean. in: Main > Utilities > Compression > WinZip Use that as a guideline for how this is going to work. Go at it guys! -- _ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://jnewman.codeweavers.com | .` / -_) V V / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

1 0

wine binary loader problem - incorrect code at entry point
by Mike McCormack June 11, 2001

June 11, 2001

Hi, Using the latest CVS, i'm trying to run the Adobe acrobat installer program (ar500enu.exe) and it crashes without doing anything at all. i have traced the problem to bad code at the program's entry point... which presumably means that the wrong piece of the program was mmapped into memory. i have run this program before using wine, (not recently though) and it has worked. Other programs (such as the netscape installer) at least start up and get going before crashing in a similar way. Mike from the debugger: 0x0040c110 (<Debugged process>.EntryPoint in <Debugged process>): decl 0x0(%edi) Using Sang Cho's disassembler i get: //******************** Program Entry Point ******** :0040C110 55 push ebp Disassembly of File: ./c/ar500enu.exe T.DateStamp = 351A66B8: Thu Mar 26 06:31:20 1998 Code Offset = 00000400, Code Size = 00010E00 Data Offset = 00011800, Data Size = 00003200 Number of Objects = 0005 (dec), Imagebase = 00400000h Object01: .text RVA: 00001000 Offset: 00000400 Size: 00010E00 Flags: 60000020 Object02: .rdata RVA: 00012000 Offset: 00011200 Size: 00000600 Flags: 40000040 Object03: .data RVA: 00013000 Offset: 00011800 Size: 00003200 Flags: C0000040 Object04: .idata RVA: 0001A000 Offset: 00014A00 Size: 00001000 Flags: C0000040 Object05: .rsrc RVA: 0001B000 Offset: 00015A00 Size: 0000A400 Flags: 40000040 and from the trace i get: trace:module:PE_LoadImage loading C:\ar500enu.exe trace:module:map_image mapped PE file at 0x400000-0x426000 trace:module:map_image mapping section .text at 0x401000 off 400 size 10e00 flags 60000020 trace:module:map_image mapping section .rdata at 0x412000 off 11200 size 600 flags 40000040 trace:module:map_image mapping section .data at 0x413000 off 11800 size 3200 flags c0000040 trace:module:map_image clearing 0x416200 - 0x417000 trace:module:map_image mapping section .idata at 0x41a000 off 14a00 size 1000 flags c0000040 trace:module:map_image mapping section .rsrc at 0x41b000 off 15a00 size a400 flags 40000040 trace:module:load_library loaded ntdll.dll 0x403512c4 40050000 ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

[Problem report] X11DRV_ScrollWindowEx
by Gerard Patel June 10, 2001

June 10, 2001

This function hangs with the following apps (at least) - Notepad Win 3.11 - Notepad NT 4 - Eudora 1.5 In all cases, the problem appears when a text has several pages and I try to scroll toward the beginning of text. The problem disappears if I comment out the calls to X11DRV_StartGraphicsExposure and X11DRV_EndGraphicsExposure. The apps seem to work just as well. The hanging occurs because there is no X event generated in X11DRV_EndGraphicsExposure. I don't quite see why there should be one in this case. Gerard

1 0

FYI: ControlSpy has stopped working
by Guy L. Albertelli June 10, 2001

June 10, 2001

Using the current CVS (6/9), certain ControlSpy modules (REBAR and COMBOBOXEX) no longer seem to work, even with the native versions of COMCTL32. The internal child windows in the left pane are no longer drawn. Seems to have occured sometime since 6/1. I will look into it tomorrow after some rest. Strange. Guy Albertelli <<galberte(a)neo.lrun.com>>

2 1

Re: FYI: ControlSpy has stopped working
by Gerard Patel June 10, 2001

June 10, 2001

At 11:56 PM 09/06/2001 -0400, you wrote: >Using the current CVS (6/9), certain ControlSpy modules (REBAR and >COMBOBOXEX) no longer seem to work, even with the native versions of >COMCTL32. The internal child windows in the left pane are no longer drawn. >Seems to have occured sometime since 6/1. I will look into it tomorrow after >some rest. Strange. Strange ??? After this patch : ChangeSet ID: 991691718458116964902729 CVSROOT: /opt/cvs-commit Module name: wine Changes by: julliard(a)wine2. 01/06/04 17:55:18 (...) Log message: Create an X window for every window, including children. I see a lot of problems in most of my test apps after the implementation of this evil scheme. I have already sent several patches to work around some of these problems, two have been applied, one has been ignored so far, but even with this last Wine's status is beyond the usual breakage level. Gerard

2 1

Help needed
by Renukaprasad, MR June 9, 2001

June 9, 2001

Hi, We are planning to port wine onto Tru64 Unix. I have some basic Questions. Can you tell me how to go about it. How do we start. How big is the task and how to start about it.. Thanks And Regards, Renuka

1 0

Re: VirtualProtect() fixup
by Alexandre Julliard June 8, 2001

June 8, 2001

520053692817-0001(a)t-online.de (Andreas Mohr) writes: > (you do know that I disagree on these things, right ? after all Wine emulates > *Windows*, and if Windows does it that way, then we should do it, too, for > heaven's sake, especially if it's not really painful) There is no such thing as "Windows", there are multiple versions that do different things, and we have to choose what we emulate. In this case it's clear that it makes more sense to emulate the NT behavior, since this is what is documented. Of course we could do a winver check, but if we do this for every single difference between Win98 and NT, we'll end up with a mess of spaghetti code with more version checks than actual code. So winver checks must be limited to cases where they are demonstrably necessary for a real-world application. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: VirtualProtect() fixup
by Alexandre Julliard June 8, 2001

June 8, 2001

520053692817-0001(a)t-online.de (Andreas Mohr) writes: > What isn't the case ? Both fixups ? Or only one of these ? The return value: NT returns a BOOL, 0 or 1. I haven't checked the old protection behavior; but anyway this doesn't belong in VirtualProtect, if we have to ignore the execute permission it must be done consistently throughout the code. > Well, to be exact, no application. > I just found this out by accident. That's what I suspected ;-) > IMHO the probability that some applications exist that are too lazy > to supply their own old_prot variable and that check the return value instead > is rather high, so I think that patch is necessary. We can't start breaking things based only on your suspicion that someone somewhere will have used a feature that isn't documented at all (plus there is a documented way of doing exactly the same thing). If you have an app that needs it sure, otherwise we'll just keep returning a BOOL, as the function is documented to do. > Maybe we should add a winver check, though. No thanks. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wcmd fix
by Francois Gouget June 8, 2001

June 8, 2001

On Fri, 8 Jun 2001, Andreas Mohr wrote: > Hi all, > > file_size.XXXPart should be file_size.s.XXXPart. > > Thanks to Lasse Melsaeter for spotting this. That's the 'Dummy struct name problem in wcmd' I sent this morning. But actually whether there should an 's.' depends on the compiler (for Winelib applications) so you should test for NONAMELESSSTRUCT as I did in my patch. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

1 0

Re: VirtualProtect() fixup
by Alexandre Julliard June 8, 2001

June 8, 2001

Andreas Mohr <a.mohr(a)mailto.de> writes: > VirtualProtect had two big problems: > > - undocumented return value > - should return protection flags only instead of whole flag setting This isn't the case under NT. Which application depends on that? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Fwd: Re: WINE fix for HOMM3 [bluefire@zauberwald.net]
by Uwe Bonnes June 7, 2001

June 7, 2001

>>>>> "BlueFire" == BlueFire <bluefire(a)zauberwald.net> writes: BlueFire> Now with the missing diff..... sorry... On Thu, 07 Jun 2001 BlueFire> 11:37:14 BlueFire wrote: >> This is messed up (totally unreadable) formatting. Anyway, how about >> doing a diff -u of your change, and then submitting that patch (in >> more readable form) either to Debian's BTS, or directly to >> wine-patches(a)winehq.com? BlueFire> Sorry, I'm not familiar with either diff or the debian BlueFire> bts. That's why I tried mailing the stuff to you (and to BlueFire> wine-patches). I did a BlueFire> diff /tmp/dos_fs.c dos_fs.c > dos_fs.c.diff Hallo, find some help at http://www.winehq.com/dev.shtml BlueFire> diff -u is preferred due to it's better readability. Appending the plain file makes it easier for others to read your patch. But don't " cut and paste", as that will ofter reformat and make the patch a pain to apply. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Question about the new window design
by Gerard Patel June 6, 2001

June 6, 2001

Since the patch of 4 June, all windows are created as X windows. This makes one of my test apps to crash; it's creating a child window in the WM_NCCREATE event handling of a window. When the child window is created, X bombs because the X window parent does not exist yet - Wine is trying to call XCreateWindow with parent = 0. What is the best way of fixing this ? Gerard

1 0

Re: stack limit
by Alexandre Julliard June 6, 2001

June 6, 2001

Stephen Crowley <stephenc(a)placemark.com> writes: > Works like a charm! Thanks. I'm curious though.. I set the stack size > to 64 megs and the application immediately uses up that much ram. Is > that the default behaviour on windows? What stops it from behaving > like a normal stack and just allocating what's needed from the heap? The ram isn't actually used, it's only reserved from the address space with an anonymous mapping. Only the pages that are really accessed will use physical memory/swap, so it doesn't use any more ram than a normal stack. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: stack limit
by Alexandre Julliard June 6, 2001

June 6, 2001

Stephen Crowley <stephenc(a)placemark.com> writes: > On Mon, Jun 04, 2001 at 12:02:09PM -0700, Alexandre Julliard wrote: > > There is no way to do this at the moment; but it shouldn't be too hard > > to add support for a 'stack' statement in the application spec file. > > Thanks. Where would I look to change this in the source? I'm using some linear > regression DLLs under linux and we have to deal with some fairly large > matrices. Try this: Index: scheduler/process.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/process.c,v retrieving revision 1.154 diff -u -r1.154 process.c --- scheduler/process.c 2001/06/06 20:24:13 1.154 +++ scheduler/process.c 2001/06/06 22:46:20 @@ -319,12 +319,6 @@ LPTHREAD_START_ROUTINE entry; WINE_MODREF *wm; - /* build command line */ - if (!ENV_BuildCommandLine( main_exe_argv )) goto error; - - /* create 32-bit module for main exe */ - if (!(current_process.module = BUILTIN32_LoadExeModule( current_process.module ))) goto error; - /* use original argv[0] as name for the main module */ if (!main_exe_name[0]) { @@ -498,7 +492,6 @@ { if (PE_HEADER(current_process.module)->FileHeader.Characteristics & IMAGE_FILE_DLL) ExitProcess( ERROR_BAD_EXE_FORMAT ); - stack_size = PE_HEADER(current_process.module)->OptionalHeader.SizeOfStackReserve; goto found; } @@ -512,6 +505,13 @@ _EnterWin16Lock(); found: + /* build command line */ + if (!ENV_BuildCommandLine( main_exe_argv )) goto error; + + /* create 32-bit module for main exe */ + if (!(current_process.module = BUILTIN32_LoadExeModule( current_process.module ))) goto error; + stack_size = PE_HEADER(current_process.module)->OptionalHeader.SizeOfStackReserve; + /* allocate main thread stack */ if (!THREAD_InitStack( NtCurrentTeb(), stack_size )) goto error; Index: tools/winebuild/README =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/README,v retrieving revision 1.4 diff -u -r1.4 README --- tools/winebuild/README 2000/12/26 01:22:34 1.4 +++ tools/winebuild/README 2001/06/06 22:46:21 @@ -6,6 +6,7 @@ [file WINFILENAME] [mode dll|cuiexe|guiexe|cuiexe_unicode|guiexe_unicode] [heap SIZE] +[stack SIZE] [init FUNCTION] [import [IMP_FLAGS] DLL] [rsrc RESFILE] @@ -39,6 +40,9 @@ "heap" is the size of the module local heap (only valid for Win16 modules); default is no local heap. + +"stack" is the stack size for Win32 exe modules, in kilobytes; default +size is 1024 (1Mb stack). "file" gives the name of the Windows file that is replaced by the builtin. <name>.DLL is assumed if none is given. (This is important Index: tools/winebuild/build.h =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/build.h,v retrieving revision 1.17 diff -u -r1.17 build.h --- tools/winebuild/build.h 2001/05/22 19:55:51 1.17 +++ tools/winebuild/build.h 2001/06/06 22:46:21 @@ -161,6 +161,7 @@ extern int DLLHeapSize; extern int UsePIC; extern int debugging; +extern int stack_size; extern int nb_debug_channels; extern int nb_lib_paths; Index: tools/winebuild/main.c =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/main.c,v retrieving revision 1.17 diff -u -r1.17 main.c --- tools/winebuild/main.c 2001/05/22 19:55:51 1.17 +++ tools/winebuild/main.c 2001/06/06 22:46:21 @@ -27,6 +27,7 @@ int Limit = 0; int DLLHeapSize = 0; int UsePIC = 0; +int stack_size = 0; int nb_entry_points = 0; int nb_names = 0; int nb_debug_channels = 0; Index: tools/winebuild/parser.c =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/parser.c,v retrieving revision 1.18 diff -u -r1.18 parser.c --- tools/winebuild/parser.c 2001/05/22 19:55:51 1.18 +++ tools/winebuild/parser.c 2001/06/06 22:46:21 @@ -559,6 +559,12 @@ if (!IsNumberString(token)) fatal_error( "Expected number after heap\n" ); DLLHeapSize = atoi(token); } + else if (strcmp(token, "stack") == 0) + { + token = GetToken(0); + if (!IsNumberString(token)) fatal_error( "Expected number after stack\n" ); + stack_size = atoi(token); + } else if (strcmp(token, "init") == 0) { if (SpecType == SPEC_WIN16) Index: tools/winebuild/spec32.c =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/spec32.c,v retrieving revision 1.28 diff -u -r1.28 spec32.c --- tools/winebuild/spec32.c 2001/05/22 19:55:51 1.28 +++ tools/winebuild/spec32.c 2001/06/06 22:46:21 @@ -656,7 +656,10 @@ fprintf( outfile, " %ld,\n", page_size ); /* SizeOfHeaders */ fprintf( outfile, " 0,\n" ); /* CheckSum */ fprintf( outfile, " 0x%04x,\n", subsystem ); /* Subsystem */ - fprintf( outfile, " 0, 0, 0, 0, 0, 0,\n" ); + fprintf( outfile, " 0,\n" ); /* DllCharacteristics */ + fprintf( outfile, " %d, 0,\n", stack_size*1024 ); /* SizeOfStackReserve/Commit */ + fprintf( outfile, " %d, 0,\n", DLLHeapSize*1024 );/* SizeOfHeapReserve/Commit */ + fprintf( outfile, " 0,\n" ); /* LoaderFlags */ fprintf( outfile, " %d,\n", IMAGE_NUMBEROF_DIRECTORY_ENTRIES ); /* NumberOfRvaAndSizes */ fprintf( outfile, " {\n" ); fprintf( outfile, " { %s, %d },\n", /* IMAGE_DIRECTORY_ENTRY_EXPORT */ -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Question about the new window design
by Alexandre Julliard June 6, 2001

June 6, 2001

Gerard Patel <gerard.patel(a)nerim.net> writes: > This makes one of my test apps to crash; it's creating a child window > in the WM_NCCREATE event handling of a window. When the > child window is created, X bombs because the X window parent > does not exist yet - Wine is trying to call XCreateWindow with > parent = 0. > > What is the best way of fixing this ? The X window should be created before the WM_NCCREATE. I'm planning to fix it, but it needs to correctly handle style changes happening in WM_NCCREATE (otherwise we get the managed tooltips bug), and this needs a bit more work. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: uname(1) on UnixWare (Solaris)
by Alexandre Julliard June 6, 2001

June 6, 2001

Bang Jun-Young <bjy(a)mogua.org> writes: > I've nearly completed new DLL configuration code in configure.in. > Before making it available, I need to know what uname(1) command > prints out on UnixWare (and Solaris?). Why do you need that? Using uname(1) in a configure script is almost certainly the wrong thing to do. -- Alexandre Julliard julliard(a)winehq.com

4 9

Re: [PATCH] Flag unicode structure for user create window
by Uwe Bonnes June 6, 2001

June 6, 2001

>>>>> "Gerard" == Gerard Patel <gerard.patel(a)nerim.net> writes: Gerard> In the CreateWindow user driver function, it is not enough to Gerard> test the window procedure to know if the cs structure is unicode Gerard> or not : the window can be subclassed, in the cbt hook, for Gerard> example. Gerard> ChangeLog: Hallo, yesterday I tried to find why the findfile95 dialog only displayed the first character ( "o" versus "open"). Your patch fixed it :-) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

RE: uname(1) on UnixWare (Solaris)
by Patrik Stridvall June 6, 2001

June 6, 2001

> On Tue, Jun 05, 2001 at 12:18:00AM -0700, Francois Gouget wrote: > > On Tue, 5 Jun 2001, Bang Jun-Young wrote: > > > 1. Configure message is wrong: > > > checking whether we can build a Linux dll... yes > > > I see this even on FreeBSD and NetBSD. :( It's not a > Linux dll, > > > but an FreeBSD/NetBSD dll. > > > > Maybe this message should be changed, yes. But I don't think you > > should put a `uname` there. > > Could you explain me a bit further why we shouldn't do that? As far as the question above is concerned see Francois's reply. I fully agree with him. However regardless of this, uname shouldn't be used (at least not directly). Autoconf provides a standard way to do this (which BTW happends to use uname). It can be used as below. AC_CANONICAL_HOST case $host_os in *cygwin* ) CYGWIN=yes;; * ) CYGWIN=no;; esac It requires two files config.sub and config.guess be distribute along with Wine but that is not really a problem. Perhaps we need to do this anyway. Autoconf 2.50 has discontinued AC_CYGWIN so CYGWIN support seems to require it regardless. Actually the code above is how this is done with Autoconf 2.50. However making CYGWIN an exception is one thing, doing it in other cases is quite another thing. IMHO you will need to provide a _really_ convincing argument that we should make another exception assuming of course we make the first one for CYGWIN which we haven't done yet either.

2 1

RE: uname(1) on UnixWare (Solaris)
by Patrik Stridvall June 6, 2001

June 6, 2001

> On Tue, Jun 05, 2001 at 11:51:19PM -0700, Francois Gouget wrote: > > Maybe it was not your intention but I was afraid that we > would end up > > with something like: > > "checking whether we can build a `uname` dll..." > > and then a few lines down: > > "checking whether we can build a `uname` dll..." > > > > The problem is then you don't know exactly where the > message comes > > from. > > Sorry but I don't catch what you mean quite well. It's obvious which > message is printed on the screen, isn't it? Yes, but this means that the text no longer describes what it is trying to check. If somebody runs it on a OS called Foo it might trick the him/her into thinking that we know about and have added special handling for OS Foo, which we haven't. > What do you think about replacing "Linux dll" with "GNU style > ELF dll"? Acceptable, but it is not my decision.

1 0

Is this a bug?
by Ian Pilcher June 6, 2001

June 6, 2001

While poking around in gdi.h, I came upon the following: static inline INT WINE_UNUSED INTERNAL_XWSTODS(DC *dc, INT width) { FLOAT floatWidth; /* Perform operation with floating point */ floatWidth = (FLOAT)width; INTERNAL_XWSTODS_FLOAT(dc, &floatWidth); /* Round to integers */ return GDI_ROUND(floatWidth); } ... and a little later ... static inline INT WINE_UNUSED INTERNAL_YWSTODS(DC *dc, INT height) { FLOAT floatHeight; /* Perform operation with floating point */ floatHeight = (FLOAT)height; INTERNAL_XWSTODS_FLOAT(dc, &floatHeight); /* Round to integers */ return GDI_ROUND(floatHeight); } Shouldn't one of these (probably INTERNAL_YWSTODS) be calling INTERNAL_YWSTODS_FLOAT instead of INTERNAL_XWSTODS_FLOAT? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

2 1

Re: PATCH: set_thread_buffer fixed
by Gerard Patel June 5, 2001

June 5, 2001

At 10:43 AM 05/06/2001 +0200, you wrote: >> This calls fails because glibc detects that the value at (esp+28) >> is different of 0 - the real system call is never done, with your >> test app and Wine. > >Well, note that the second version is only pushing a 32bit offset, so >mmap64 accesses random stack space! Yes :-/ <snip> >Yes, check the sys/mman.h header, it should have __off64_t as argument >to the mmap ... asm("mmap64") not __off_t. Yes, it is __off_t and that is the problem; but how this header has come to be in this state is part of what I don't understand. It's marked as part of the glibc, but there is nothing like it in the glibc source that I used to compile. The mman.h in my glibc source is much shorter and the declaration of mmap64 seems correct. I guess that the file in my /usr/include/sys/mman.h is a generated file. I don't even want to count the number of 'mman.h' files on my system :-/ >So I think I can use this test program as check for mmap64 brokeness... Btw, the reference on large files http://www.suse.de/~aj/linux_lfs.html says that locking will never be supported on 64 bits files with glibc 2.1.3 so I don't see why it's necessary to support this case. Gerard

1 0

RE: Stanford Checker
by Patrik Stridvall June 5, 2001

June 5, 2001

> On Tue, 5 Jun 2001 David.Goodenough(a)dga.co.uk wrote: > > but has anyone thought of running these against Wine? > > I'm not sure if it'd do that much good. They're currently working on > checking the XFree86 tree (see the Xpert mailing list archives on > www.XFree86.org if you want), without a lot of big results > yet. From what > I gather, this tool has very limited and context-dependent > intelligence, Perhaps. But see below. > and is not conceptually very different from what a glorified > version of > Patrik's tools/winapi_check script might be, if given enough people > working on it. Not quite. winapi_check is 1. Specifically written for Wine 2. A syntax analyzer 3. Mostly ad hoc. The Stanford checker on the other hand is 1. Generalized for all C/C++ applications 2. A semantic analyzer 3. Formalized with a script language The way I choose when designing winapi_check was the one of the easiest ways and the way they choose is one of the hardest. So just calling it is glorified winapi_check gives the Stanford people too little credit. Anyway the way Stanford choose is really _very_ hard so what I fear is that they had to make some limiting decisions that makes their tool much less useful. That said regardless of how good the Stanford checker really will be I'm pretty there will be a lot of things that will be _much_ easier checked by writting a script for the Stanford checker than by extending winapi_check, because they have fundamentally different design philosofies. However don't underestimate winapi_check either. There is a lot of things that can quite easilt be checked by adding some clever perl pattern, if:s and a little state. Syntax level matching is not that bad just a little more crude. If somebody have something that he want to be automatically checked, please post it on the list and I will see what I can do.

1 0

Stanford Checker
by David.Goodenough＠dga.co.uk June 5, 2001

June 5, 2001

On the kernel list and in Alan Cox's patches for the kernel there are a lot of references to some logic checking tools being generated by Stanford. I do not know if these are generally available but has anyone thought of running these against Wine?

2 1

RE: Stanford Checker
by Patrik Stridvall June 5, 2001

June 5, 2001

> Maybe we have to ask them to check our code, rather than the other way > around? I think it far to much to ask. As Eric said, while it is AFAIK highly configurable with specific scripts, for each kind of check it is currently seems to be very much focused on the Linux kernel. I also believe, like Eric, that it is currently very buggy and that even if they have a powerful enough scripting language to be usable for Wine it will probably need some serious debugging to make the scripts we need to actually work in practise not only in theory. No, as I said, I think it is to much to ask. We will have to wait until they release it whenever that will be.

1 0

Re:Stanford Checker
by Eric Pouech June 5, 2001

June 5, 2001

last time I checked (a month ago), the tool wasn't freely available (nor finished), so nothing can be done for now when the tool is finished (<put here your date estimation>), one could be able to configure the tool for use in Wine (read: write the scripts for the things we want to check, like windows locks...) but, the tool is (as of today) configured for Linux, and check can only be done agains the Linux tree (AFAIU, they check for specific constructs like getting a spin lock, enabling / disabling IRQ... so highly dependent on Linux source...) however, I don't know (yet) the power of the script language they use for configuring, and whether it could be used for Wine... you'll have to wait until the tool is released... (I suspect, the tool is still buggy *AND* still requires lots of processing by hand - you get a 100 warnings from where only a few are real issues). A+ > On the kernel list and in Alan Cox's patches for the kernel there are a lot > of references to some logic checking tools being generated by Stanford. I > do not know if these are generally available but has anyone thought of > running these against Wine? --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

1 0

RE: Stanford Checker
by David.Goodenough＠dga.co.uk June 5, 2001

June 5, 2001

Maybe we have to ask them to check our code, rather than the other way around? Patrik Stridvall <ps(a)leissner.se> on 05-06-2001 12:31:25 PM To: David Goodenough/DGA/GB cc: wine-devel(a)winehq.com Subject: RE: Stanford Checker [Forgot to include list. Trying again.] > On the kernel list and in Alan Cox's patches for the kernel > there are a lot > of references to some logic checking tools being generated by > Stanford. I > do not know if these are generally available but has anyone thought of > running these against Wine? Yes, I have. However the problem is that it is not publicly available (yet) and I read somewhere (don't remember where) that it is no use trying to get copy even if you promise not to distribute it further. I will probably look into it when it is released. I have no idea when that will be though.

1 0

RE: Stanford Checker
by Patrik Stridvall June 5, 2001

June 5, 2001

[Forgot to include list. Trying again.] > On the kernel list and in Alan Cox's patches for the kernel > there are a lot > of references to some logic checking tools being generated by > Stanford. I > do not know if these are generally available but has anyone thought of > running these against Wine? Yes, I have. However the problem is that it is not publicly available (yet) and I read somewhere (don't remember where) that it is no use trying to get copy even if you promise not to distribute it further. I will probably look into it when it is released. I have no idea when that will be though.

1 0

CVS compilation problem: XvSelectNotify
by Heiko Nardmann June 5, 2001

June 5, 2001

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just compiled CVS wine using ./configure --prefix=/opt/wine-20010605 --enable-dll --with-x and get the following error message starting Word: err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /opt/wine-20010510/lib/libwine_tsx11.so: undefined symbol: XvSelectPortNotify Could not load graphics driver 'x11drv' - -- 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 iD8DBQE7HJ2Opm53PRScYygRAkZsAKCXRyt3ncR7sFRNatc7/6Bls3+eywCg9sO5 7oombEYBU9llG4o8Gp7LeyA= =a8Qa -----END PGP SIGNATURE-----

1 0

Re: PATCH: set_thread_buffer fixed
by Gerard Patel June 5, 2001

June 5, 2001

At 07:20 AM 05/06/2001 +0200, you wrote: >Not really, as Alexandre said. > >Could you please test the attached small test program? It fails (of course). Here is the call with my working computer (glibc2.2, linux 2.4) 0x8048668 <main+72>: call 0x8048464 <write> 0x804866d <main+77>: add $0xc,%esp 0x8048670 <main+80>: push $0x0 0x8048672 <main+82>: push $0x0 0x8048674 <main+84>: push %ebx 0x8048675 <main+85>: push $0x1 0x8048677 <main+87>: push $0x3 0x8048679 <main+89>: push $0x4 0x804867b <main+91>: push $0x0 0x804867d <main+93>: call 0x80484a4 <mmap64>p For the failing one : 0x80486c8 <main+72>: call 0x80484dc <write> 0x80486cd <main+77>: addl $0x20,%esp 0x80486d0 <main+80>: addl $0xfffffff8,%esp 0x80486d3 <main+83>: pushl $0x0 0x80486d5 <main+85>: pushl %ebx 0x80486d6 <main+86>: pushl $0x1 0x80486d8 <main+88>: pushl $0x3 0x80486da <main+90>: pushl $0x4 0x80486dc <main+92>: pushl $0x0 0x80486de <main+94>: call 0x804851c <mmap64> This calls fails because glibc detects that the value at (esp+28) is different of 0 - the real system call is never done, with your test app and Wine. In the glibc 2.1.3 source, this test is not explained; in the 2.2.2 source, there is a comment saying that the offset is 'too large'. I understand that the app is calling mmap64 on an operating system that is not supporting it (it's perfectly correct in this case, the failing box having 2.2.5 kernel), and glibc tests if the call can be mapped to standard mmap. I think that the problem is in the compilation; pushing only 6 dwords on the stack to call mmap64 is wrong. I have not yet figured out why, though (I have never been any good with C header problems) Gerard

2 1

Re: PATCH: set_thread_buffer fixed
by Gerard Patel June 5, 2001

June 5, 2001

At 08:12 AM 03/06/2001 +0200, you wrote: >> After applying your patch to current cvs, rm config.cache, ./configure, >> make depend && make Wine crashes as before. > >You need to run 'autoheader -l include' if any change to acconfig.h >is submitted. Thanks, it worked. Problem solved IMO. Gerard

1 0

mIRC crash when processing large files.
by rpbrown＠xtra.co.nz June 5, 2001

June 5, 2001

Details how to replicate the crash. (yes its time consuming, but it shows the crash) Ok, this is what I do to crash mIRC in wine. I install the mp3-script for mIRC. http://welcome.to/autoget load the script according to the readme..and join IRC Undernet, any Undernet server will do. /join #mpthree the person we're looking for is SuperServ (an Op) right mouse on the nick, and grab there mp3 list.. you can try other ppls lists, but SuperServ has a rather big list (8Mb) which at the end of the download the script keeps on loading (processing the txt file) ..and then crashes mIRC. Loading _this_ list itself into mIRC under windows normally, mIRC is locked for a 3-4 minutes (processing the list).. maybe wine gives up too soon, since its not getting a response within X amount of time. Or the list is too big for wine to handle? thats my guesses.. I hope this helps. -mdew

1 0

uname(1) on UnixWare (Solaris)
by Bang Jun-Young June 4, 2001

June 4, 2001

Hi, I've nearly completed new DLL configuration code in configure.in. Before making it available, I need to know what uname(1) command prints out on UnixWare (and Solaris?). As in NetBSD, it's: $ uname NetBSD I guess it would be $ uname UnixWare on UnixWare. I also wonder if UnixWare and Solaris refer to the same. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

1 0

Re: FreeType autoconf checks
by Alexandre Julliard June 4, 2001

June 4, 2001

Ian Pilcher <ian.pilcher(a)home.com> writes: > CPPFLAGS works. Where the heck is that documented? (I can't find it in > the info pages for gcc or cpp.) It's not a gcc option, it's a configure internal variable (from $ac_cpp definition). This is the whole point: it will work independently of the compiler, or at least break the same way during configure and during the compile, which is what we want. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: set_thread_buffer fixed
by lawson_whitney＠juno.com June 4, 2001

June 4, 2001

On Sun, 3 Jun 2001, Marcus Meissner wrote: > Is this the case where set_thread_buffer fails or not? > Okay, it is not. It crashes in debug_printf or dump_exports (pe_image.c). However, it is so too a glibc-2.1.3 problem. I think. Sort of. The same Wine that crashes with kernel 2.4.4 and 2.4.5 works fine with kernel 2.2.14, and I bet later 2.2.x kernels when (if) I get around to building them. I think I might not be smart enough to debug it in detail. Maybe I should just send www4mail after glibc-2.2 instead. > I don't see a failure message here. > > Also, could you try to run the attached test program and see if it fails? success with either kernel version. Hmmm, do I have 2.0.30 still lying around? 1.3.18? > > Ciao, Marcus > Lawson Constants aren't, and variables won't. ---cut--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: FreeType autoconf checks
by Alexandre Julliard June 4, 2001

June 4, 2001

Ian Pilcher <ian.pilcher(a)home.com> writes: > One thing to keep in mind, however. The FreeType headers themselves > use relative paths to include one another, so this is an issue that > we're not going to be able to completely eliminate. This is why I > had to mess around with the C_INCLUDE_PATH variable; AC_CHECK_HEADER > tries to preprocess the header file, so it has to be able to find any > subsidiary headers. (Is this what you mean by finding a way to check > that #include <freetype/freetype.h> works?) Yes; we should be using only relative paths in AC_CHECK_HEADER, since this is what we will use in the code. I don't think C_INCLUDE_PATH is portable either. Did you try setting CPPFLAGS instead? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: FreeType autoconf checks
by Ian Pilcher June 4, 2001

June 4, 2001

Alexandre Julliard wrote: > > Well, I don't like it much, but I haven't had time to look into a > better solution yet. Basically I think it's dangerous to check for the > file name with an absolute path and then include it with a relative > path, since there is no guarantee we'll get the same file. I think we > should really find a way to check that #include <freetype/freetype.h> > works given the right C flags. Also I'm not sure about the portability > of the ${FREETYPEINCL#-I} construct. > I see your point. Now that I think about it, I probably would have been bitten by it if anyone will. I run Red Hat 7.1 which has: /usr/include/freetype/freetype.h (from FreeType 1.x) /usr/include/freetype2/freetype/freetype.h (from FreeType 2.x) I just checked the gcc documentation, and directories specified with '-I' options on the command line are checked first. I have no idea, however, if other compilers behave in a similar manner. Using absolute paths for the FreeType headers would be non-trivial, but probably doable. We would have to use autoconf to define macros that include the complete path name of the headers we want to include; then #include those macros instead of the file names. Somehow, I don't think you're going to want to do that. One thing to keep in mind, however. The FreeType headers themselves use relative paths to include one another, so this is an issue that we're not going to be able to completely eliminate. This is why I had to mess around with the C_INCLUDE_PATH variable; AC_CHECK_HEADER tries to preprocess the header file, so it has to be able to find any subsidiary headers. (Is this what you mean by finding a way to check that #include <freetype/freetype.h> works?) I also had the same thought about the ${FREETYPEINCL#-I} construct. According to http://www.opengroup.org/onlinepubs/7908799/xcu/chap2.html#tag_001_006_002 it seems to be OK. Frankly, I share your distaste for this whole mess. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Re: fixup bogus SetLastError()
by Alexandre Julliard June 4, 2001

June 4, 2001

Andreas Mohr <a.mohr(a)mailto.de> writes: > objects/gdiobj.c really has no business dealing with SetLastError(). > SetLastError() is a mechanism to communicate errors to external programs, > so it should definitely not be used for highly internal functions. You didn't include the gdiobj.c patch, but I disagree with it anyway... There can be many good reasons for setting last error in internal functions; for instance setting it inside GDI_GetObjPtr avoids having to set it in every single caller. And in the very rare case where this is not what we want, the caller can always set it to another value. -- Alexandre Julliard julliard(a)winehq.com

3 2

stack limit
by Stephen Crowley June 4, 2001

June 4, 2001

What is the correct way to increase the default stack size for winelib applications? Also, are there any drawbacks to making the value fairly large? -- Stephen Crowley Software Engineer Placemark Investments 972.404.8100 x28

2 1

Re: stack limit
by Alexandre Julliard June 4, 2001

June 4, 2001

Stephen Crowley <stephenc(a)placemark.com> writes: > What is the proper way to increase the stack size for winelib > applications? There seems to be a limit of around 2^20 bytes right now. There is no way to do this at the moment; but it shouldn't be too hard to add support for a 'stack' statement in the application spec file. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: fixup bogus SetLastError()
by Alexandre Julliard June 4, 2001

June 4, 2001

520053692817-0001(a)t-online.de (Andreas Mohr) writes: > Now that's where I disagree ! > The caller can *not* always set it to another value. > If it does and the program intends to read the LastError of a *previously* > executed API that failed, then the LastError will be reset even though > it shouldn't have been ! Then the caller needs to save/restore it across the GDI_GetObjPtr call. That's trivial to do. > In short: the SetLastError behaviour needs to match Windows behaviour very, > very closely. Definitely; but it's not clear to me that not setting last error is anywhere closer to Windows than setting it to INVALID_HANDLE. GDI_GetObjPtr should do what most callers need, and IMO this means setting it. I may be wrong, I haven't checked the error returns of all GDI functions (and of course this is nowhere documented). > This would be SelectObject() in this case, BTW. Which case? Do you have evidence that a SelectObject() with an invalid handle must not set last error? If so then of course it needs fixing. -- Alexandre Julliard julliard(a)winehq.com

2 1

stack limit
by Stephen Crowley June 4, 2001

June 4, 2001

What is the proper way to increase the stack size for winelib applications? There seems to be a limit of around 2^20 bytes right now. -- Stephen Crowley Software Engineer Placemark Investments 972.404.8100 x28

1 0

tan not exported by msvcrt, ntdll
by Francois Gouget June 3, 2001

June 3, 2001

I tried compiling Winelib applications without '-lm' (btw, the comment in configure.in is incorrect, it concerns Linux too, not just BeOS). But I had undefined symbol errors for applications that use tan and a couple other math functions. The reason is that both ntdll and msvcrt declare them with '-noimport': * msvcrt.spec: @ forward -noimport tan ntdll.tan * ntdll.spec: @ cdecl -noimport tan(double) tan So a Winelib application that imports msvcrt and ntdll does not get tan and thus must link with libm in the Unix sense. sin, cos and most others were ok though! Changelog: * dlls/msvcrt/msvcrt.spec Remove some '-noimport' for math functions -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

1 0

AnimateWindow() calls SetWindowPos() on a timer???
by Bobby Bingham June 3, 2001

June 3, 2001

Forgot a detail ... Every time it send the messages it tells it not to move, size, redraw, activate, or change z-order. I could see the reason for these if if didn't tell it not to do anything, but ... ?? Bobby Bingham uhmmmm(a)ameritech.net

1 0

AnimateWindow() calls SetWindowPos() on a timer???
by Bobby Bingham June 3, 2001

June 3, 2001

I am implementing AnimateWindow(), and I recorded all the messages win98 sent to my window when I called AnimateWindow(). It send a lot of groups of WM_WINDOWPOSCHANGING, WM_NCCALCSIZE, and WM_WINDOWPOSCHANGED. The number of times it sends these seems to correspond to how long I tell it to make the animation, almost as if it were on a timer. It looks like it calls SetWindowPos() on the window a lot, but I don't see why they would do this. Does anyone know?? I can supply my test app once I clean it up a little. Bobby Bingham uhmmmm(a)ameritech.net

1 0

off topic: Windows 98 and binutils
by Brian Craft June 3, 2001

June 3, 2001

Hey -- Sorry for the OT post, but I suspect someone here will know the answer to this. I'm trying to objdump some Windows 98 device drivers & dlls. Last time I did something like this it was user-mode code from 95 or NT (not sure which), and I just configured binutils for i386-pe. Only this same configuration won't read the Windows 98 files -- it says the file format isn't recognised. I can still read the old Windows binaries with this config. I also tried i386-msdos, for good measure. What's the scoop? 98 has a new format? Is there a binutils target that will do the job? b.c.

2 1

Re: PATCH: set_thread_buffer fixed
by Gerard Patel June 3, 2001

June 3, 2001

At 07:19 PM 02/06/2001 +0200, you wrote: <snip> >I have now changed config.h to only enable 64bit support for glibc 2.2 >or better. After applying your patch to current cvs, rm config.cache, ./configure, make depend && make Wine crashes as before. Did you leave something to for Alexandre Julliard implicit (he certainly knows about this stuff, I don't) ? I don't understand why _FILE_OFFSET_BITS is still defined in config.h.in. Gerard

3 2

Re: PATCH: set_thread_buffer fixed
by Alexandre Julliard June 2, 2001

June 2, 2001

Marcus Meissner <marcus(a)jet.franken.de> writes: > Enable 64bit file operations on Linux only for glibc 2.2 or better, > since mmap64 is broken on glibc 2.1. It would be much better to do a configure check. Including features.h from config.h is very ugly IMO (not to mention that mmap64 seems to work fine on my glibc 2.1.3...) -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: PATCH: set_thread_buffer fixed
by Ove Kaaven June 2, 2001

June 2, 2001

On Sat, 2 Jun 2001, Marcus Meissner wrote: > -/* This is for glibc on Linux, it will turn on 64 bit file support at compile time */ > -#define _FILE_OFFSET_BITS 64 > +#include <features.h> > +/* This is for glibc on Linux, it will turn on 64 bit file support at > + * compile time > + * Since glibc 2.1.x has various degrees of broken mmap64 prototypes, > + * we do not use this on glibc 2.1.x systems. > + */ > +#if (__GLIBC__ >= 2) && (__GLIBC_MINOR__ > 1) > +# define _FILE_OFFSET_BITS 64 > +#endif > + That's probably not going to work. The features.h is the only header that checks whether _FILE_OFFSET_BITS is defined, and it's protected against multiple inclusion, so _FILE_OFFSET_BITS must be defined *before* you include features.h. If you must check version, use autoconf.

1 0

Re: set_thread_buffer (fwd)
by lawson_whitney＠juno.com June 2, 2001

June 2, 2001

This seems to have bounced once. Hope winehq feels better soon. On Fri, 1 Jun 2001 =?iso-8859-1?Q?G=E9rard_Patel_=3Cgerard.patel=40nerim.net=3E?=(a)tourian.nerim.net wrote: > Just what I have. > > if you verify if you have the same problem as myself, with current cvs > remove the line defining _FILE_OFFSET_BITS. This fixes it for me. > > Gerard > By this I understood to rip #define _FILE_OFFSET_BITS 64 out of config.h (and acconfig.h just to be sure) and rerun make. It recompiles nearly everything, of course, and makes a wine that will run my app again, so I guess it is the same problem. Now, what is the problem? :-/ glibc-2.1.3 - from Mandrake 7.2 - ?? - I am fairly sure I haven't munged any headers myself.. but Mandrake might have. Are <linux/ and <asm/ considered glibc headers? I don't see them in the rpm, but some motorist broke both my legs a while ago and it is too tough to change the CD and see what is in Slackware's glibc-2.1.2. I guess that wouldn't be conclusive anyway. gcc-2.95.2 locally built, with genuine strength-reduce bug. kernel 2.4.4 with devfs? Other? Feels to me like an inconsistancy between headers and library -? Lawson ---cut--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re:AnimateWindow() constants?
by Eric Pouech June 2, 2001

June 2, 2001

> I am about to implement the AnimateWindow() function, but I don't have up to > date windows headers. I did some trial and error on a win98 box and came up > with what I think are the correct values, but could somebody check? all correct A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

1 0

wine-users down?
by Francois Gouget June 1, 2001

June 1, 2001

Hi, I didn't receive any message on wine-users since May 30th. Is the mailing list down or is it a problem on my end? There's been many messages since then on the newsgroup. Btw, why is the link to the wine-users archive disabled on WineHQ? (http://www.winehq.com/dev.shtml#ml) I found wine-users archives via Google: http://www.winehq.com/hypermail/wine-users/ And I see in the mailing list archives that there's no message since May 30th either. Looks like a mailing list problem to me... Last question (for this email...): Why do the mailing list archives point to the Integrita archives rather than the WineHQ archives? Is there an advantage of one over the other? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

2 1

AnimateWindow() constants?
by Bobby Bingham June 1, 2001

June 1, 2001

I am about to implement the AnimateWindow() function, but I don't have up to date windows headers. I did some trial and error on a win98 box and came up with what I think are the correct values, but could somebody check? AW_SLIDE 0x00040000 AW_ACTIVATE 0x00020000 AW_BLEND 0x00080000 AW_HIDE 0x00010000 AW_CENTER 0x00000010 AW_HOR_POSITIVE 0x00000001 AW_HOR_NEGATIVE 0x00000002 AW_VER_POSITIVE 0x00000004 AW_VER_NEGATIVE 0x00000008 I'm pretty sure about all of them except AW_BLEND because win98 doesn't implement it. Thanks in advance Bobby Bingham uhmmmm(a)ameritech.net

1 0

Finding (or not) the exact number of args
by Gaël de Chalendar June 1, 2001

June 1, 2001

Hi, I'm trying to implement stubs for some missing ordinal functions in shlwapi. Reading the NOTES comment in dlls/shlwapi/ordinal.c I don't know if it is a good idea, but it allows explorer.exe (Win 98) to show its desktop and it is what I'm testing (just for fun. I do not hope to be able to use it right now). Anyway, it uses at a moment or another unimplemented ordinal functions. To implement their stubs, I begins with a lot of args, reducing this number until the function is passed. It seems to work but I wonder if I do not add only problems with this strategy. If I left the stack in a corrupted state, maybe the problem will become visible a lot later... I was not able to find in docs, mails archives or google groups any useful tip to find (simply) the right number of args. Particularly, the URL http://www.ece.cmu.edu/afs/ece/usr/dacut/www/src is dead. So, do I continue ? If yes, in this way or differently ? Thanks for your advices. Gael. PS: I will not read my mail until monday 28.

3 4

Re: critical section blocking
by Duane Clark June 1, 2001

June 1, 2001

Aric Stewart wrote: > > Working with QuickTime5 I found a situation where mouse messages could > lockup wine. This leaving and entering the critical section resolves > that bug. > > -aric > > ------------------------------------------------------------------------ > Index: windows/message.c > =================================================================== > RCS file: /home/wine/wine/windows/message.c,v With this patch, Myst locks up solid as soon as the mouse is moved into the Myst window. Without it, Myst works fine. Duane

3 2

Can MAPI be directed to sendmail from a Windows app on Wine ?
by Steve Ball June 1, 2001

June 1, 2001

I am running a windows voicemail server under wine and it runs extremely well, but I believe there is no MAPI support in Wine, and the voicemail server complains that there is no MAPI provider. I would not want to install a Windows email client even if I thought I could use MAPI, and would much prefer to use sendmail as the MAPI sender. I don't think it would be difficult to write code that would produce a sendmail mail message from a Wine stub, but I cannot find where the MAPI support goes and I know very little about MAPI under Windows, since I have done very little Windows programming. Has anyone done this before, or could anyone direct me to the hooks in Wine, and preferably some information on how MAPI works in Windows apps. The Wine project is a fantastic achievement, I hope that I can give something back. Steve Ball

1 0

Re: wineps include fix.
by Ian Pilcher June 1, 2001

June 1, 2001

David Hammerton wrote: > > hi, seems you have done some updating on it.. but now it still doesnt compile, > im not sure if your trying to include something that is defined elsewhere or > you made a typo, but it seems to bawk on: > > gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -g -O2 > -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT > -I/usr/X11R6/include -o truetype.o truetype.c > truetype.c:13: `#include' expects "FILENAME" or <FILENAME> > truetype.c:14: `#include' expects "FILENAME" or <FILENAME> > I give up. You're getting the error because FreeType's macros are not being defined by your include files. This is supposed to be the way to work around the fact that the FreeType guys rename their include files with every minor release. freetype/freetype.h should either define the macros or include another file that does so. If you can figure out why that isn't happening, let me know. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

5 9

Re: WINE server messages
by Alexandre Julliard May 31, 2001

May 31, 2001

David Howells <dhowells(a)redhat.com> writes: > Actually, I see that you do maintain a view list in the client as well as the > module list and section lists in the server. What I was thinking of was just > consolidating the three into a single view list and a single section list in > the server. > > In effect, Wine'd still have the module list, it's just that there'd be > non-modules in the list too. I still don't see why you want that. The fact that the section list is in the client or in the server is orthogonal to the fact that we maintain a list of modules. If you have a list of mapped views in the server you can simplify the module list a bit by making each module point to the view instead of the backing file, but you still need a module list to send debugger events and do toolhelp snapshots. You could of course hide the module list inside the section list by adding some magic flags to the section descriptor, but all it changes is that you then need to walk the whole section list to retrieve the modules; I don't really see the point. -- Alexandre Julliard julliard(a)winehq.com

1 0