December 2002 - Wine-Devel - list.winehq.org

Re: wineboot - Andy's version

by Francois Gouget

On Sun, 22 Dec 2002, Shachar Shemesh wrote: [...] > What I'm thinking is incorporating the first group into the wine code > itself (I'm thinking the server startup, synchroniously done). For the > second group, create a wineboot program, and have a single option saying > whether the wineserver should run it on startup or not. It is my understanding that if you put these in the wine server you will not be able to use the Windows APIs. This will make it unnecessarily complex to handle the move and renames since the paths will be windows paths. Putting this code in a standalone utility will allow you to use the Windows API and then calling it from the Wine server (if that is the way we go) is just a fork away. It also makes the 'when is it called' more flexible which can come in handy. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

Dec. 22, 2002

Re: A crash destroying imagelists

by Duane Clark

Duane Clark wrote: > I am trying to track down a crash when exiting an application. Here is > what I think are relevant parts of the trace. Does it appear that I am > in the right area? Any hints on how to proceed would be appreciated. I think the problem comes down to this. The application explicitly destroys the imagelist that belongs to a listview: > 08073208:Call comctl32.ImageList_Destroy(41691ba0) ret=005027f5 > ... That area is then freed. When freed, COMCTL32_Free writes prev and next entries into himl. > trace:commctrl:COMCTL32_Free (0x41691ba0) > trace:heap:RtlFreeHeap (0x41690000,00000002,41691ba0): returning TRUE > 08073208:Ret comctl32.ImageList_Destroy() retval=00000001 ret=005027f5 > ... Then LISTVIEW_NCDestroy is called. > > trace:listview:LISTVIEW_NCDestroy () > trace:listview:LISTVIEW_DeleteAllItems () > trace:commctrl:DPA_DeleteAllPtrs (0x41690d98) > ... > trace:listview:notify_hdr <= 0 > trace:listview:LISTVIEW_NCDestroy Start destroying data structures. > ... The listview does not know that the imagelist was already destroyed, so it again calls ImageList_Destroy. > trace:listview:LISTVIEW_NCDestroy Start destroying image lists. > 08073208:Call gdi32.DeleteObject(aaaaaaaa) ret=409fcadd > 08073208:Ret gdi32.DeleteObject() retval=00000000 ret=409fcadd > 08073208:Call gdi32.DeleteObject(aaaaaaaa) ret=409fcaea > 08073208:Ret gdi32.DeleteObject() retval=00000000 ret=409fcaea > 08073208:Call gdi32.DeleteObject(aaaaaaaa) ret=409fcaf7 > 08073208:Ret gdi32.DeleteObject() retval=00000000 ret=409fcaf7 > 08073208:Call gdi32.DeleteObject(aaaaaaaa) ret=409fcb04 > 08073208:Ret gdi32.DeleteObject() retval=00000000 ret=409fcb04 At the end of ImageList_Destroy, there is a call to ZeroMemory, which obliterates the prev and next pointers which had been written there. Then another COMCTL32_Free call detects the error. At least I assume it is an error. > trace:commctrl:COMCTL32_Free (0x41691ba0) > err:heap:HEAP_ValidateFreeArena Heap 41690000: bad next ptr 00000000 for arena 41691b98

Dec. 22, 2002

Re: [RFH] _FORCENAMELESSUNION

by Francois Gouget

On Sun, 22 Dec 2002, Dimitrie O. Paun wrote: > On December 22, 2002 06:03 am, Ove Kaaven wrote: > > Perhaps you could investigate the mingw headers to see > > if they've changed the #ifs around to get around this. > > This is how they do it: > > #ifdef NONAMELESSUNION > #define __VARIANT_NAME_1 n1 > #define __VARIANT_NAME_2 n2 > #define __VARIANT_NAME_3 n3 > #define __VARIANT_NAME_4 n4 > #else > #define __tagVARIANT > #define __VARIANT_NAME_1 > #define __VARIANT_NAME_2 > #define __VARIANT_NAME_3 > #define __VARIANT_NAME_4 > #endif > > Maybe our way is the right way. But it seems like wxWindows expects > nameless structures under all compilers, without defining > _FORCENAMELESSUNION... I can just define it, it's not a big deal, > just a small incompatibility. Maybe you should submit patches to wxWindows and/or MinGW. I think this could only improve these projects to be more compatible with the Windows headers... -- 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...

Dec. 22, 2002

Winemaker line 3041: "WRCFLAGS = -r -L" -> "WRCFLAGS = -r" ?

by Kjetil S. Matheussen

Shouldnt it? Breaks the compilation of the vstserver. Please apply. :) --

Dec. 22, 2002

Re: __WINE__ vs. __WINESRC__

by Shachar Shemesh

Dimitrie O. Paun wrote: >It shouldn't. In theory. But the difference between practice and theory >is that while in theory practice and theory are the same, in practice >they are different ((c) Larry McVoy) :). > > That works great in practice, but it will never fly in theory (anonymous). Sh.

Dec. 22, 2002

Usage of strtolW in Setupapi install

by Uwe Bonnes

Hallo, for me it looks as if the same fix as to files/drive.c with regard to the usage of strtolW versus strtoulW should be applied to dlls/setupapi/install.c too. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/dlls/setupapi/install.c =================================================================== RCS file: /home/wine/wine/dlls/setupapi/install.c,v retrieving revision 1.5 diff -u -r1.5 install.c --- wine/dlls/setupapi/install.c 18 Oct 2002 23:48:58 -0000 1.5 +++ wine/dlls/setupapi/install.c 22 Dec 2002 16:56:27 -0000 @@ -315,7 +315,7 @@ if (type == REG_DWORD) { - DWORD dw = str ? strtolW( str, NULL, 16 ) : 0; + DWORD dw = str ? strtoulW( str, NULL, 16 ) : 0; TRACE( "setting dword %s to %lx\n", debugstr_w(value), dw ); RegSetValueExW( hkey, value, 0, type, (BYTE *)&dw, sizeof(dw) ); }

Dec. 22, 2002

Re: [RFH] _FORCENAMELESSUNION

by Dimitrie O. Paun

On December 22, 2002 06:03 am, Ove Kaaven wrote: > Perhaps you could investigate the mingw headers to see > if they've changed the #ifs around to get around this. This is how they do it: #ifdef NONAMELESSUNION #define __VARIANT_NAME_1 n1 #define __VARIANT_NAME_2 n2 #define __VARIANT_NAME_3 n3 #define __VARIANT_NAME_4 n4 #else #define __tagVARIANT #define __VARIANT_NAME_1 #define __VARIANT_NAME_2 #define __VARIANT_NAME_3 #define __VARIANT_NAME_4 #endif Maybe our way is the right way. But it seems like wxWindows expects nameless structures under all compilers, without defining _FORCENAMELESSUNION... I can just define it, it's not a big deal, just a small incompatibility. Many things to fix, I'll get to it later on. -- Dimi.

Dec. 22, 2002

Re: __WINE__ vs. __WINESRC__

by Dimitrie O. Paun

On December 22, 2002 04:44 am, Dmitry Timoshkov wrote: > Compiling under Wine should not IMO require defining additional symbols > except probably __WIN32__. It shouldn't. In theory. But the difference between practice and theory is that while in theory practice and theory are the same, in practice they are different ((c) Larry McVoy) :). For example, they may test for it to work around bugs in Wine. Yeah, Wine shouldn't have bugs, but it does, and will continue to do so for the forseeable future. Yes, they should submit a patch instead, but they are 3rd party apps, they can't wait for the change to propagate to all users. Just like we asked for -fshort-char in gcc, but we can't assume all gccs out there support it the moment it got into the gcc tree. Or they may want to use glibc functions not available on MinGW. And so on. Of course, you will say, all these are better served by a configure script, and I agree with you. But this is _their_ project, not ours to decide how they do it. Some don't even have a configure script, and it may be way easier for them to add 1-2 #ifdefs than to completely change their build to port to Wine. Some may be libraries (e.g. wxWindows) that don't want their headers to depend on configure scripts, just like we don't want ours, because they will be used by 3rd party apps and they don't want to force them to have a configure script (as we shouldn't force our users). But all this is irrelevant: current practice is to define a standard symbol to mark the platform. Unless we have overriding concerns (and I can't see any, defining a symbol that we don't test for in Wine is a noop), we should do the same. It is the user's prerogative to make use of it as they see fit. -- Dimi.

Dec. 22, 2002

Re: Some strange winedbg regression...

by Ove Kaaven

On Sat, 21 Dec 2002, Lionel Ulmer wrote: > On Sat, Dec 21, 2002 at 05:49:23PM +0100, Eric Pouech wrote: > > > So I was wondering how to debug this ? I tried to attach 'gdb' to it (and it > > > works) but how do I know which symbols to load (winedbg being a script, wine > > > having no code except linking to DLLs, ....) ? > > load miscemu/wine in gdb, it'll get what you're looking for > > OK, what happens is that the application is loading the DINPUT library... > And at DLL load time, it adds a low-level hook for the keyboard (I wonder > why only for the keyboard and not the mouse, but well, that's another > problem :-) ). > > And it seems that the invocation of this hook from the wineconsole makes > Wine crash. I think that the problem is that the DLL is loaded from the > application's context and called from the console context. > > Now, one could do the same for the mouse, ie install the hook only later on > when acquiring the keyboard, Or when creating the device (since Arjen Nienhuis made it hook on startup because some app used GetDeviceState without acquiring the device), like in this WineX patch I just wrote to fix a game that didn't like the dinput hook to be installed before its own keyboard hook: Index: dinput_main.c =================================================================== RCS file: /cvsroot/winex/wine/dlls/dinput/dinput_main.c,v retrieving revision 1.18 diff -u -r1.18 dinput_main.c --- dinput_main.c 25 Sep 2002 20:23:15 -0000 1.18 +++ dinput_main.c 22 Dec 2002 14:52:02 -0000 @@ -43,10 +43,8 @@ switch(reason) { case DLL_PROCESS_ATTACH: - keyboard_hook = SetWindowsHookExW( WH_KEYBOARD_LL, KeyboardCallback, 0, 0 ); break; case DLL_PROCESS_DETACH: - UnhookWindowsHookEx(keyboard_hook); break; } return TRUE; Index: dinput_private.h =================================================================== RCS file: /cvsroot/winex/wine/dlls/dinput/dinput_private.h,v retrieving revision 1.8 diff -u -r1.8 dinput_private.h --- dinput_private.h 5 Sep 2002 11:52:43 -0000 1.8 +++ dinput_private.h 22 Dec 2002 14:52:02 -0000 @@ -26,10 +26,6 @@ extern void dinput_register_device(dinput_device *device) ; -HHOOK keyboard_hook; - -LRESULT CALLBACK KeyboardCallback( int code, WPARAM wparam, LPARAM lparam ); - HRESULT DeviceThunkA_create_device(dinput_device* device, IDirectInputImpl* dinput, REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEA* pdev); HRESULT DeviceThunkW_create_device(dinput_device* device, IDirectInputImpl* dinput, REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEW* pdev); HRESULT DeviceThunkA_enum_device(dinput_device* device, DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEA lpddi); Index: keyboard/main.c =================================================================== RCS file: /cvsroot/winex/wine/dlls/dinput/keyboard/main.c,v retrieving revision 1.16 diff -u -r1.16 main.c --- keyboard/main.c 25 Sep 2002 20:23:15 -0000 1.16 +++ keyboard/main.c 22 Dec 2002 14:52:02 -0000 @@ -59,6 +59,8 @@ static BYTE DInputKeyState[256]; /* array for 'GetDeviceState' */ +CRITICAL_SECTION keyboard_crit = CRITICAL_SECTION_INIT("dinput_keyboard"); +DWORD keyboard_users; HHOOK keyboard_hook; LRESULT CALLBACK KeyboardCallback( int code, WPARAM wparam, LPARAM lparam ) @@ -147,6 +149,11 @@ memcpy(&(newDevice->guid),rguid,sizeof(*rguid)); newDevice->dinput = dinput; + EnterCriticalSection(&keyboard_crit); + if (!keyboard_users++) + keyboard_hook = SetWindowsHookExW( WH_KEYBOARD_LL, KeyboardCallback, 0, 0 ); + LeaveCriticalSection(&keyboard_crit); + return newDevice; } @@ -179,6 +186,31 @@ DECL_GLOBAL_CONSTRUCTOR(keyboarddev_register) { dinput_register_device(&keyboarddev); } +static ULONG WINAPI SysKeyboardAImpl_Release(LPDIRECTINPUTDEVICE8A iface) +{ + ICOM_THIS(SysKeyboardAImpl,iface); + + This->ref--; + if (This->ref) + return This->ref; + + EnterCriticalSection(&keyboard_crit); + if (!--keyboard_users) { + UnhookWindowsHookEx( keyboard_hook ); + keyboard_hook = 0; + } + LeaveCriticalSection(&keyboard_crit); + + /* Free the data queue */ + if (This->buffer != NULL) + HeapFree(GetProcessHeap(),0,This->buffer); + + DeleteCriticalSection(&(This->crit)); + + HeapFree(GetProcessHeap(),0,This); + return 0; +} + static HRESULT WINAPI SysKeyboardAImpl_SetProperty( LPDIRECTINPUTDEVICE8A iface,REFGUID rguid,LPCDIPROPHEADER ph ) @@ -381,7 +413,7 @@ ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE IDirectInputDevice2AImpl_QueryInterface, IDirectInputDevice2AImpl_AddRef, - IDirectInputDevice2AImpl_Release, + SysKeyboardAImpl_Release, SysKeyboardAImpl_GetCapabilities, IDirectInputDevice2AImpl_EnumObjects, IDirectInputDevice2AImpl_GetProperty,

Dec. 22, 2002

Re: [RFC] wintab dll design: how to intergrate with current X11 code.

by Robert North

Right, can now ignore my original post, and comment on the following. Ok, I've sort of found a template for the X11_drv wintab seperation: The tablate is the direct X drirect draw, and open GL dlls. These dlls do the following: X11_drv thread synchronisation Grab the X device the GDI code uses. (I only want to grab the same display string, and build my own XDisplay object). Get the X window handle from a win32 window handle. This is all that's needed to attach the wintab dll to the XInput code. I shall put no extra code in the X11_drv. All XInput calls will live in the wintab dll. One fly may appear in the ointment: It is possible for the X11 driver to insert wintab messages into wthe win32 message queue. This can be handled entirely inside the wintab dll, but the tablet messages may get out of sync with the rest of the windows messages. If the messages do get out of sync, then wintab may need to hook into the event code int x11_drv/event.c. For the moment I'm assuming this won't happen. That's all for now Merry Christmas -Rob.

Dec. 22, 2002

Re: Conditional to support Solaris

by Robert Lunnon

On Sun, 22 Dec 2002 05:42, Alexandre Julliard wrote: > Robert Lunnon <bob(a)yarrabee.net.au> writes: > > I need to introduce a compile time conditional to better facilitate > > Solaris, in particular the macro ADDRESS_SPACE_LIMIT in virtual.c. > > > > I understand HAVE_SOLARIS is frowned upon so can anyone suggest a more > > targetted alternative (Could use __sysv__ but who knows whether all SYSV > > implementations need to define ADDRESS_SPACE_LIMIT the same way !) > > As has been discussed already, ADDRESS_SPACE_LIMIT is a Windows > limitation, not a Linux one, so it must not be changed for > Solaris. The right way is to somehow reserve the area above > ADDRESS_SPACE_LIMIT so that it's not used for normal allocations. Either way, there needs to be a conditional (or run-time test)

Dec. 22, 2002

Re: [RFH] _FORCENAMELESSUNION

by Ove Kaaven

On Sun, 22 Dec 2002, Francois Gouget wrote: > On Sun, 22 Dec 2002, Dimitrie O. Paun wrote: > > > Folks, > > > > Why do we need to define _FORCENAMELESSUNION to get nameless unions > > in oleauto.h? Is this a standard feature, or is it just another Wine > > extension? Can someone please check the Windows headers to see how > > struct tagVARIANT is defined? Our is as follows: > > _FORCENAMELESSUNION is a Windows 'feature' (checked against the latest > SDK afaik). We do it like they do. Our variant type matches the Windows > one except for tiny differences (e.g. short instead of SHORT) and we > lack the __tagBRECORD field. I can send a patch to add these (tomorrow, > it's late here). BRECORD is already in my oaidl.idl (should be submitted sometime after the holidays), so it's not necessary.

Dec. 22, 2002

Re: [RFH] _FORCENAMELESSUNION

by Francois Gouget

On Sun, 22 Dec 2002, Dimitrie O. Paun wrote: > Folks, > > Why do we need to define _FORCENAMELESSUNION to get nameless unions > in oleauto.h? Is this a standard feature, or is it just another Wine > extension? Can someone please check the Windows headers to see how > struct tagVARIANT is defined? Our is as follows: _FORCENAMELESSUNION is a Windows 'feature' (checked against the latest SDK afaik). We do it like they do. Our variant type matches the Windows one except for tiny differences (e.g. short instead of SHORT) and we lack the __tagBRECORD field. I can send a patch to add these (tomorrow, it's late here). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

Dec. 22, 2002

Re: [RFH] _FORCENAMELESSUNION

by Ove Kaaven

On Sun, 22 Dec 2002, Dimitrie O. Paun wrote: > Folks, > > Why do we need to define _FORCENAMELESSUNION to get nameless unions > in oleauto.h? Is this a standard feature, or is it just another Wine > extension? It's a standard MS feature, and Wine defines VARIANT exactly like Windows. Perhaps the problem is more that MS defines __STDC__ only in "strict ANSI C compatibility without nameless unions mode" or something, and mingw defines it always? Perhaps you could investigate the mingw headers to see if they've changed the #ifs around to get around this. If you come up with something, I could make the necessary changes to my coming-soon oaidl.idl.

Dec. 22, 2002

Re: __WINE__ vs. __WINESRC__

by Dmitry Timoshkov

"Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > Here is another problem: we are currently defining the __WINE__ symbol > to signal the headers that we are compiling Wine. This is fine. The > problem that I'm facing is that there are apps (such as wxWindows) that > want to know that they are _compiled_ (not run) under Wine. > All platforms (and Wine is a platform, even if a virtual one) define > standard symbols by default: __WIN32__, __MINGW32__, you name it. Compiling under Wine should not IMO require defining additional symbols except probably __WIN32__. > There are valid reasons for a program to be able to test that > is being compiled under Wine, and not under MinGW for example. What are that reasons? Care to list some of them? -- Dmitry.

Dec. 22, 2002

Re: wineboot - Andy's version

by Shachar Shemesh

Ok, I was under the impression that we want something in so that we can start working on it. As this is the way you feel about the current wineboot, I think I'll go a completely new route. Please let me know your thoughts about the new proposed process. In windows, some of the boot operations are done by the core "windows". These include wininit processing, win.ini, rename registry keys, and the services (can probably wait with these, however). Other things are performed by explorer when it first starts. These include the run and runonce keys. What I'm thinking is incorporating the first group into the wine code itself (I'm thinking the server startup, synchroniously done). For the second group, create a wineboot program, and have a single option saying whether the wineserver should run it on startup or not. Ideas, comments, opinions are welcome. Shachar Alexandre Julliard wrote: >Shachar Shemesh <wine-devel(a)sun.consumer.org.il> writes: > > > >>Just wanted to know whether this fell through the cracks, or whether >>there was another reason this was not commited to CVS. >> >> > >I was hoping you would clean it up, not simply resubmit Andi's >stuff. As discussed with Andi already, this thing is much too complex >and over-engineered. It has to be a simple application that doesn't >require user interaction or a dozen configuration parameters. > > >

Dec. 22, 2002

Re: MSVC4, next two buttons on installer

by Eric Pouech

Dan Kegel wrote: > Q1. What do I have to do to get Wine's builtin rich text DLL to work there? > I tried "wine --dll riched32=b", but that didn't help. there are several version of the richedit DLLs. riched32 should be version 1.0. what your app requires seems to be version 2.0 of this DLL. as of today, version 1.0 is very poorly implemented in wine, and far from 2.0... so you're stuck with either using native riched20.dll, or doing lots of hard work to implement version 1.0 and 2.0 (IIRC, there's also a 3.0 version ;-) > Q2. Any idea what I'd need to do to get a Windows Explorer going > without actually installing the real Windows Explorer?-) > Does Wine have a builtin Windows Explorer clone yet? there's a winfile compatible (winefile) in the programs directory, but this isn't really an explorer clone. however making it explorer.exe compatible (from the command line point of view) shouldn't be too difficult. but there are lots of other stuff in there (DDE server for example) which will require quite some work too. A+ -- Eric Pouech

Dec. 22, 2002

[RFH] _FORCENAMELESSUNION

by Dimitrie O. Paun

Folks, Why do we need to define _FORCENAMELESSUNION to get nameless unions in oleauto.h? Is this a standard feature, or is it just another Wine extension? Can someone please check the Windows headers to see how struct tagVARIANT is defined? Our is as follows: struct tagVARIANT { union { struct __tagVARIANT { VARTYPE vt; WORD wReserved1; WORD wReserved2; WORD wReserved3; union /* DUMMYUNIONNAME */ { /* By value. */ CHAR cVal; USHORT uiVal; ULONG ulVal; INT intVal; UINT uintVal; BYTE bVal; short iVal; long lVal; float fltVal; double dblVal; VARIANT_BOOL boolVal; SCODE scode; DATE date; BSTR bstrVal; CY cyVal; IUnknown* punkVal; IDispatch* pdispVal; SAFEARRAY* parray; /* By reference */ CHAR* pcVal; USHORT* puiVal; ULONG* pulVal; INT* pintVal; UINT* puintVal; BYTE* pbVal; short* piVal; long* plVal; float* pfltVal; double* pdblVal; VARIANT_BOOL* pboolVal; SCODE* pscode; DATE* pdate; BSTR* pbstrVal; VARIANT* pvarVal; PVOID byref; CY* pcyVal; DECIMAL* pdecVal; IUnknown** ppunkVal; IDispatch** ppdispVal; SAFEARRAY** pparray; } __VARIANT_NAME_3; } __VARIANT_NAME_2; DECIMAL decVal; } __VARIANT_NAME_1; }; -- Dimi.

Dec. 22, 2002

MSVC4, next two buttons on installer

by Dan Kegel

I tried installing msvc++4.0 again with today's cvs wine. The 'exit' button works now, which is nice, but none of the other buttons do anything. (Well, they highlight when you mouse over them, and they play a sound, but that's it.) I discovered that under Windows, if you copy the disc's setup.exe to the hard drive, two of the buttons do nothing, just like in Wine. Two more buttons, however, simply launch external programs -- "Explore the CD" launches Windows Explorer on the directory containing setup.exe, and "Standard Template Library" launches WordPad on a particular file. OK, those sound so simple I ought to be able to get them working. So I copied wordpad.exe and mfc42.dll from my windows system into the same place on my fake windows area, and now when I click on "Standard Template Library", I get "Could not load the richEdit control DLL. The system may be low on memory or the file RICHED20.DLL may be missing or corrupt." OK, copied that too, now that button launches wordpad, albeit with lots of "fixme:clipboard:..." messages. Q1. What do I have to do to get Wine's builtin rich text DLL to work there? I tried "wine --dll riched32=b", but that didn't help. Q2. Any idea what I'd need to do to get a Windows Explorer going without actually installing the real Windows Explorer?-) Does Wine have a builtin Windows Explorer clone yet? Thanks, Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 22, 2002

__WINE__ vs. __WINESRC__

by Dimitrie O. Paun

Hi folks, Here is another problem: we are currently defining the __WINE__ symbol to signal the headers that we are compiling Wine. This is fine. The problem that I'm facing is that there are apps (such as wxWindows) that want to know that they are _compiled_ (not run) under Wine. All platforms (and Wine is a platform, even if a virtual one) define standard symbols by default: __WIN32__, __MINGW32__, you name it. There are valid reasons for a program to be able to test that is being compiled under Wine, and not under MinGW for example. Thus, we need to define a standard symbol, and __WINE__ seems to be the most appropriate. I think it's better to expose the prettier name, and use a longer/uglier one internally. So, my proposal is: let's rename the __WINE__ symbol (as it's currently used) to something else (__WINESRC__, or whatever, suggestions welcome), once that's done, define __WINE__ when __WINESRC__ is not defined (the symbols would be mutually exclusive). I can send in a patch if people don't object... -- Dimi.

Dec. 22, 2002

A crash destroying imagelists

by Duane Clark

I am trying to track down a crash when exiting an application. Here is what I think are relevant parts of the trace. Does it appear that I am in the right area? Any hints on how to proceed would be appreciated. 08073208:Call comctl32.ImageList_Destroy(41691ba0) ret=005027f5 08073208:Call gdi32.DeleteObject(0000098c) ret=409fcadd 08073208:Call x11drv.DeleteBitmap(0000098c) ret=4078081b 08073208:Call gdi32.GDI_GetObjPtr(0000098c,00004f4b) ret=40adcfe4 08073208:Ret gdi32.GDI_GetObjPtr() retval=40279910 ret=40adcfe4 08073208:Call gdi32.GDI_ReleaseObj(0000098c) ret=40add01e 08073208:Ret gdi32.GDI_ReleaseObj() retval=00000000 ret=40add01e 08073208:Ret x11drv.DeleteBitmap() retval=00000001 ret=4078081b trace:heap:RtlFreeHeap (0x40230000,00000002,40279910): returning TRUE 08073208:Ret gdi32.DeleteObject() retval=00000001 ret=409fcadd 08073208:Call gdi32.DeleteObject(00000990) ret=409fcaea 08073208:Call x11drv.DeleteBitmap(00000990) ret=4078081b 08073208:Call gdi32.GDI_GetObjPtr(00000990,00004f4b) ret=40adcfe4 08073208:Ret gdi32.GDI_GetObjPtr() retval=402799c8 ret=40adcfe4 08073208:Call gdi32.GDI_ReleaseObj(00000990) ret=40add01e 08073208:Ret gdi32.GDI_ReleaseObj() retval=00000000 ret=40add01e 08073208:Ret x11drv.DeleteBitmap() retval=00000001 ret=4078081b trace:heap:RtlFreeHeap (0x40230000,00000002,402799c8): returning TRUE 08073208:Ret gdi32.DeleteObject() retval=00000001 ret=409fcaea 08073208:Call gdi32.DeleteObject(00001282) ret=409fcaf7 trace:heap:RtlFreeHeap (0x40230000,00000002,40279ac0): returning TRUE trace:heap:RtlFreeHeap (0x40230000,00000002,40279a58): returning TRUE 08073208:Call kernel32.LOCAL_Free(000001b7,00001282) ret=4078e36f 08073208:Ret kernel32.LOCAL_Free() retval=00000000 ret=4078e36f 08073208:Ret gdi32.DeleteObject() retval=00000001 ret=409fcaf7 08073208:Call gdi32.DeleteObject(00001286) ret=409fcb04 trace:heap:RtlFreeHeap (0x40230000,00000002,40279b28): returning TRUE trace:heap:RtlFreeHeap (0x40230000,00000002,40279ae0): returning TRUE 08073208:Call kernel32.LOCAL_Free(000001b7,00001286) ret=4078e36f 08073208:Ret kernel32.LOCAL_Free() retval=00000000 ret=4078e36f 08073208:Ret gdi32.DeleteObject() retval=00000001 ret=409fcb04 trace:commctrl:COMCTL32_Free (0x41691ba0) trace:heap:RtlFreeHeap (0x41690000,00000002,41691ba0): returning TRUE 08073208:Ret comctl32.ImageList_Destroy() retval=00000001 ret=005027f5 The next mention of 41691ba0 is 08073208:Call window proc 0x40a0f0c8 (hwnd=0x1002e,msg=LVM_GETIMAGELIST,wp=00000001,lp=00000000) 08073208:Call kernel32._ConfirmSysLevel(4070bc18) ret=406b681d 08073208:Ret kernel32._ConfirmSysLevel() retval=00000000 ret=406b681d 08073208:Call user32.GetWindowLongW(0001002e,00000000) ret=40a0f0e5 08073208:Ret user32.GetWindowLongW() retval=41690a18 ret=40a0f0e5 trace:listview:LISTVIEW_WindowProc (uMsg=1002 wParam=1 lParam=0) 08073208:Call user32.GetWindowLongW(0001002e,fffffff0) ret=40a0f164 08073208:Ret user32.GetWindowLongW() retval=40018405 ret=40a0f164 08073208:Call kernel32.GlobalGetAtomNameW(0000c012,4070ce90,0000003c) ret=40693ce9 08073208:Ret kernel32.GlobalGetAtomNameW() retval=0000000d ret=40693ce9 08073208:Call kernel32.lstrcpynW(4070cf08,40274130 L"List1",00000010) ret=406b9fe6 08073208:Ret kernel32.lstrcpynW() retval=4070cf08 ret=406b9fe6 08073208:Ret window proc 0x40a0f0c8 (hwnd=0x1002e,msg=LVM_GETIMAGELIST,wp=00000001,lp=00000000) retval=41691ba0 08073208:Ret user32.CallWindowProcA() retval=41691ba0 ret=005050d2 08073208:Ret user32.CallWindowProcA() retval=41691ba0 ret=005050d2 08073208:Call kernel32.GlobalGetAtomNameW(0000c012,4070ce90,0000003c) ret=40693ce9 08073208:Ret kernel32.GlobalGetAtomNameW() retval=0000000d ret=40693ce9 08073208:Call kernel32.lstrcpynW(4070cf08,40274130 L"List1",00000010) ret=406b9fe6 08073208:Ret kernel32.lstrcpynW() retval=4070cf08 ret=406b9fe6 08073208:Ret window proc 0x5048bf (hwnd=0x1002e,msg=LVM_GETIMAGELIST,wp=00000001,lp=00000000) retval=41691ba0 So it appears to still get the imagelist, even though it has been destroyed. Then the next mention is where it gives a bad ptr message. 08073208:Call window proc 0x503959 (hwnd=0x1002d,msg=WM_NOTIFY,wp=0000041b,lp=40581ea4) 08073208:Call kernel32._ConfirmSysLevel(4070bc18) ret=406b681d 08073208:Ret kernel32._ConfirmSysLevel() retval=00000000 ret=406b681d 08073208:Call kernel32.GlobalFindAtomW(406f3982 L"PropertySheetInfo") ret=406d7488 08073208:Ret kernel32.GlobalFindAtomW() retval=00000000 ret=406d7488 08073208:Call kernel32.GlobalGetAtomNameW(00008002,4070ce90,0000003c) ret=40693ce9 08073208:Ret kernel32.GlobalGetAtomNameW() retval=00000007 ret=40693ce9 08073208:Call kernel32.lstrcpynW(4070cf08,402757e8 L"Conference Information Window",00000010) ret=406b9fe6 08073208:Ret kernel32.lstrcpynW() retval=4070cf08 ret=406b9fe6 08073208:Ret window proc 0x503959 (hwnd=0x1002d,msg=WM_NOTIFY,wp=0000041b,lp=40581ea4) retval=00000000 08073208:Call kernel32.GlobalFindAtomW(406f3982 L"PropertySheetInfo") ret=406d7488 08073208:Ret kernel32.GlobalFindAtomW() retval=00000000 ret=406d7488 08073208:Call kernel32.GlobalGetAtomNameW(00008002,4070ce90,0000003c) ret=40693ce9 08073208:Ret kernel32.GlobalGetAtomNameW() retval=00000007 ret=40693ce9 08073208:Call kernel32.lstrcpynW(4070cf08,402757e8 L"Conference Information Window",00000010) ret=406b9fe6 08073208:Ret kernel32.lstrcpynW() retval=4070cf08 ret=406b9fe6 08073208:Ret window proc 0x4069aaf8 (hwnd=0x1002d,msg=WM_NOTIFY,wp=0000041b,lp=40581ea4) retval=00000000 08073208:Ret user32.CallWindowProcA() retval=00000000 ret=005050d2 08073208:Call kernel32.GlobalFindAtomW(406f3982 L"PropertySheetInfo") ret=406d7488 08073208:Ret kernel32.GlobalFindAtomW() retval=00000000 ret=406d7488 08073208:Call kernel32.GlobalGetAtomNameW(00008002,4070ce90,0000003c) ret=40693ce9 08073208:Ret kernel32.GlobalGetAtomNameW() retval=00000007 ret=40693ce9 08073208:Call kernel32.lstrcpynW(4070cf08,402757e8 L"Conference Information Window",00000010) ret=406b9fe6 08073208:Ret kernel32.lstrcpynW() retval=4070cf08 ret=406b9fe6 08073208:Ret window proc 0x5048bf (hwnd=0x1002d,msg=WM_NOTIFY,wp=0000041b,lp=40581ea4) retval=00000000 08073208:Call kernel32.GlobalLock16(0000020f) ret=406ae141 08073208:Ret kernel32.GlobalLock16() retval=4025f210 ret=406ae141 08073208:Ret user32.SendMessageW() retval=00000000 ret=40a00f12 trace:listview:notify_hdr <= 0 trace:listview:LISTVIEW_NCDestroy Start destroying data structures. trace:commctrl:DPA_Destroy (0x41690e10) trace:heap:RtlFreeHeap (0x41690000,00000002,41690e30): returning TRUE trace:heap:RtlFreeHeap (0x41690000,00000002,41690e10): returning TRUE trace:commctrl:DPA_Destroy (0x41690e88) trace:heap:RtlFreeHeap (0x41690000,00000002,41690ea8): returning TRUE trace:heap:RtlFreeHeap (0x41690000,00000002,41690e88): returning TRUE trace:commctrl:DPA_Destroy (0x41690f00) trace:heap:RtlFreeHeap (0x41690000,00000002,41690f20): returning TRUE trace:heap:RtlFreeHeap (0x41690000,00000002,41690f00): returning TRUE trace:commctrl:DPA_Destroy (0x41690f78) trace:heap:RtlFreeHeap (0x41690000,00000002,41690f98): returning TRUE trace:heap:RtlFreeHeap (0x41690000,00000002,41690f78): returning TRUE trace:commctrl:DPA_DeleteAllPtrs (0x41690d98) trace:heap:RtlFreeHeap (0x41690000,00000002,41690db8): returning TRUE trace:heap:RtlAllocateHeap (0x41690000,0000000a,00000050): returning 41690d20 trace:commctrl:DPA_Destroy (0x41690d98) trace:heap:RtlFreeHeap (0x41690000,00000002,41690d20): returning TRUE trace:heap:RtlFreeHeap (0x41690000,00000002,41690d98): returning TRUE trace:commctrl:COMCTL32_Free (0x41690d78) trace:heap:RtlFreeHeap (0x41690000,00000002,41690d78): returning TRUE trace:listview:LISTVIEW_NCDestroy Start destroying image lists. 08073208:Call gdi32.DeleteObject(aaaaaaaa) ret=409fcadd 08073208:Ret gdi32.DeleteObject() retval=00000000 ret=409fcadd 08073208:Call gdi32.DeleteObject(aaaaaaaa) ret=409fcaea 08073208:Ret gdi32.DeleteObject() retval=00000000 ret=409fcaea 08073208:Call gdi32.DeleteObject(aaaaaaaa) ret=409fcaf7 08073208:Ret gdi32.DeleteObject() retval=00000000 ret=409fcaf7 08073208:Call gdi32.DeleteObject(aaaaaaaa) ret=409fcb04 08073208:Ret gdi32.DeleteObject() retval=00000000 ret=409fcb04 trace:commctrl:COMCTL32_Free (0x41691ba0) err:heap:HEAP_ValidateFreeArena Heap 41690000: bad next ptr 00000000 for arena 41691b98 Heap: 41690000 Next: 41680000 Sub-heaps: 41690000 Free lists: Block Stat Size Id 41690038 free 00000001 prev=41692180 next=41691ca0 4169004c free 00000001 prev=41691de0 next=416900b0 41690060 free 00000001 prev=41690988 next=41691d28 41690074 free 00000001 prev=41691fa0 next=41690d18 Sub-heap 41690000: size=00110000 committed=00010000 Block Stat Size Id 41690090 used 00000018 416900b0 free 00000078 prev=4169004c next=41690988 41690138 Used 00000088 back=416900b0 416901c8 used 00000088 41690258 used 000000c0 41690320 free 00000638 prev=41690d18 next=41692180 41690968 Used 00000018 back=41690320 41690988 free 00000058 prev=416900b0 next=41690060 416909f0 Used 00000018 back=41690988 41690a10 used 00000300 41690d18 free 000002c0 prev=41690074 next=41690320 41690fe8 Used 00000300 back=41690d18 416912f0 used 00000050 41691348 used 00000018 41691368 used 00000018 41691388 used 00000050 416913e0 used 00000018 41691400 used 00000050 41691458 used 00000018 41691478 used 00000050 416914d0 used 00000018 416914f0 used 00000050 41691548 used 00000018 41691568 used 00000050 416915c0 used 00000300 416918c8 used 00000050 41691920 used 00000018 41691940 used 00000018 41691960 used 00000050 416919b8 used 00000018 416919d8 used 00000050 41691a30 used 00000018 41691a50 used 00000050 41691aa8 used 00000018 41691ac8 used 00000050 41691b20 used 00000018 41691b40 used 00000050 41691b98 free 000000d8 prev=00000000 next=00000000 41691c80 Used 00000018 back=41691b98 41691ca0 free 00000010 prev=41690038 next=41691ec0 41691cc0 Used 00000018 back=41691ca0 41691ce0 used 00000020 41691d08 used 00000018 41691d28 free 00000088 prev=41690060 next=41691b98 41691dc0 Used 00000018 back=41691d28 41691de0 free 00000008 prev=41691ec0 next=4169004c 41691df8 Used 00000018 back=41691de0 41691e18 used 00000060 41691e80 used 00000018 41691ea0 used 00000018 41691ec0 free 00000008 prev=41691ca0 next=41691de0 41691ed8 Used 00000018 back=41691ec0 41691ef8 used 00000018 41691f18 used 00000060 41691f80 used 00000018 41691fa0 free 000001b0 prev=41691b98 next=41690074 41692160 Used 00000018 back=41691fa0 41692180 free 0010de70 prev=41690320 next=41690038 Total: Size=00110000 Committed=00010000 Free=0010eb68 Used=000011e0 Arenas=000002b8 (0%)

Dec. 21, 2002

Re: wine + eBay's auction-tool "MisterLister"

by Tony Lambregts

Sylvain Petreolle wrote: >In terms o standards , this threads opens a new question : >why not have a standard for bug reporting ? >We could create create a document named 'BUGREPORT' and refer to it >in any question we are asked to answer. > > > Isn't this what http://www.winehq.org/Docs/wine-user/bugs.shtml is for? If not what would you have changed? -- Tony Lambregts

Dec. 21, 2002

Re: wineboot - Andy's version

by Alexandre Julliard

Shachar Shemesh <wine-devel(a)sun.consumer.org.il> writes: > Just wanted to know whether this fell through the cracks, or whether > there was another reason this was not commited to CVS. I was hoping you would clean it up, not simply resubmit Andi's stuff. As discussed with Andi already, this thing is much too complex and over-engineered. It has to be a simple application that doesn't require user interaction or a dozen configuration parameters. -- Alexandre Julliard julliard(a)winehq.com

Dec. 21, 2002

Re: Conditional to support Solaris

by Alexandre Julliard

Robert Lunnon <bob(a)yarrabee.net.au> writes: > I need to introduce a compile time conditional to better facilitate Solaris, > in particular the macro ADDRESS_SPACE_LIMIT in virtual.c. > > I understand HAVE_SOLARIS is frowned upon so can anyone suggest a more > targetted alternative (Could use __sysv__ but who knows whether all SYSV > implementations need to define ADDRESS_SPACE_LIMIT the same way !) As has been discussed already, ADDRESS_SPACE_LIMIT is a Windows limitation, not a Linux one, so it must not be changed for Solaris. The right way is to somehow reserve the area above ADDRESS_SPACE_LIMIT so that it's not used for normal allocations. -- Alexandre Julliard julliard(a)winehq.com

Dec. 21, 2002

Re: Some strange winedbg regression...

by Alexandre Julliard

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > And it seems that the invocation of this hook from the wineconsole makes > Wine crash. I think that the problem is that the DLL is loaded from the > application's context and called from the console context. The problem is that system hooks don't work so well in builtin dlls because the load address is not always aligned. For the low-level keyboard and mouse hooks it shouldn't matter because they should always be called in the context of the process that set the hook, but this is not implemented yet. There's the same problem with the journalling hooks, I'm working on it. > Now, one could do the same for the mouse, ie install the hook only later on > when acquiring the keyboard, but well, I think the problem would be the same > if the debugger is started after the 'acquire'. We should definitely do that in any case. Having the keyboard hook set even when not needed will be a serious performance hit. -- Alexandre Julliard julliard(a)winehq.com

Dec. 21, 2002

Re: Conformance tests failing

by Paul Millar

On Fri, 20 Dec 2002 chrismorgan(a)rcn.com wrote: > Afaik these tests pass under wine so maybe wine has incorrect default > nls values? Its worth pointing out that, with LANG=en_US make test all the tests pass, whereas with LANG=en_GB make test the four tests fail. ---- Paul Millar

Dec. 21, 2002

Re: Some strange winedbg regression...

by Lionel Ulmer

On Sat, Dec 21, 2002 at 05:49:23PM +0100, Eric Pouech wrote: > > So I was wondering how to debug this ? I tried to attach 'gdb' to it (and it > > works) but how do I know which symbols to load (winedbg being a script, wine > > having no code except linking to DLLs, ....) ? > load miscemu/wine in gdb, it'll get what you're looking for OK, what happens is that the application is loading the DINPUT library... And at DLL load time, it adds a low-level hook for the keyboard (I wonder why only for the keyboard and not the mouse, but well, that's another problem :-) ). And it seems that the invocation of this hook from the wineconsole makes Wine crash. I think that the problem is that the DLL is loaded from the application's context and called from the console context. Now, one could do the same for the mouse, ie install the hook only later on when acquiring the keyboard, but well, I think the problem would be the same if the debugger is started after the 'acquire'. So I wonder how to 'fix' this... I think I know Eric's answer : use GDB's proxy stuff and debug Wine using a non-Wine application :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 21, 2002

Re: Some strange winedbg regression...

by Eric Pouech

> So I was wondering how to debug this ? I tried to attach 'gdb' to it (and it > works) but how do I know which symbols to load (winedbg being a script, wine > having no code except linking to DLLs, ....) ? load miscemu/wine in gdb, it'll get what you're looking for if it doesn't work better you can also try the attached patch (if the bug is triggered inside the debugger, otherwise - in some builtin DLLs, or in wineconsole - it won't help at all) A+ -- Eric Pouech Name: wd_extexcpt ChangeLog: added internal variables to: - trigger the external debugger when an exception occurs inside winedbg -turn on/off the emacs controls on line edition License: X11 GenDate: 2002/12/21 16:46:51 UTC ModifiedFiles: programs/winedbg/dbg.y programs/winedbg/intvar.h programs/winedbg/winedbg.c AddedFiles: =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/programs/winedbg/dbg.y,v retrieving revision 1.3 diff -u -u -r1.3 dbg.y --- programs/winedbg/dbg.y 12 Dec 2002 23:34:01 -0000 1.3 +++ programs/winedbg/dbg.y 21 Dec 2002 16:21:28 -0000 @@ -388,32 +392,36 @@ static WINE_EXCEPTION_FILTER(wine_dbg_cmd) { - DEBUG_Printf(DBG_CHN_MESG, "\nwine_dbg_cmd: "); - switch (GetExceptionCode()) { - case DEBUG_STATUS_INTERNAL_ERROR: - DEBUG_Printf(DBG_CHN_MESG, "WineDbg internal error\n"); - break; - case DEBUG_STATUS_NO_SYMBOL: - DEBUG_Printf(DBG_CHN_MESG, "Undefined symbol\n"); - break; - case DEBUG_STATUS_DIV_BY_ZERO: - DEBUG_Printf(DBG_CHN_MESG, "Division by zero\n"); - break; - case DEBUG_STATUS_BAD_TYPE: - DEBUG_Printf(DBG_CHN_MESG, "No type or type mismatch\n"); - break; - case DEBUG_STATUS_NO_FIELD: - DEBUG_Printf(DBG_CHN_MESG, "No such field in structure or union\n"); - break; - case DEBUG_STATUS_ABORT: - break; - default: - DEBUG_Printf(DBG_CHN_MESG, "Exception %lx\n", GetExceptionCode()); - DEBUG_ExternalDebugger(); - break; - } + if (DBG_IVAR(ExtDbgOnInternalException)) + DEBUG_ExternalDebugger(); + DEBUG_Printf(DBG_CHN_MESG, "\nwine_dbg_cmd: "); + switch (GetExceptionCode()) { + case DEBUG_STATUS_INTERNAL_ERROR: + DEBUG_Printf(DBG_CHN_MESG, "WineDbg internal error\n"); + if (DBG_IVAR(ExtDbgOnInternalException)) + DEBUG_ExternalDebugger(); + break; + case DEBUG_STATUS_NO_SYMBOL: + DEBUG_Printf(DBG_CHN_MESG, "Undefined symbol\n"); + break; + case DEBUG_STATUS_DIV_BY_ZERO: + DEBUG_Printf(DBG_CHN_MESG, "Division by zero\n"); + break; + case DEBUG_STATUS_BAD_TYPE: + DEBUG_Printf(DBG_CHN_MESG, "No type or type mismatch\n"); + break; + case DEBUG_STATUS_NO_FIELD: + DEBUG_Printf(DBG_CHN_MESG, "No such field in structure or union\n"); + break; + case DEBUG_STATUS_ABORT: + break; + default: + DEBUG_Printf(DBG_CHN_MESG, "Exception %lx\n", GetExceptionCode()); + DEBUG_ExternalDebugger(); + break; + } - return EXCEPTION_EXECUTE_HANDLER; + return EXCEPTION_EXECUTE_HANDLER; } static void set_default_channels(void) Index: programs/winedbg/intvar.h =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/programs/winedbg/intvar.h,v retrieving revision 1.1 diff -u -u -r1.1 intvar.h --- programs/winedbg/intvar.h 13 Sep 2002 17:54:28 -0000 1.1 +++ programs/winedbg/intvar.h 6 Dec 2002 20:16:10 -0000 @@ -20,20 +20,22 @@ */ /* break handling */ -INTERNAL_VAR(BreakAllThreadsStartup, FALSE, NULL, DT_BASIC_CONST_INT) +INTERNAL_VAR(BreakAllThreadsStartup, FALSE, NULL, DT_BASIC_CONST_INT) INTERNAL_VAR(BreakOnCritSectTimeOut, FALSE, NULL, DT_BASIC_CONST_INT) INTERNAL_VAR(BreakOnAttach, FALSE, NULL, DT_BASIC_CONST_INT) INTERNAL_VAR(BreakOnFirstChance, TRUE, NULL, DT_BASIC_CONST_INT) INTERNAL_VAR(BreakOnDllLoad, FALSE, NULL, DT_BASIC_CONST_INT) INTERNAL_VAR(CanDeferOnBPByAddr, FALSE, NULL, DT_BASIC_CONST_INT) - /* output handling */ + /* console handling */ INTERNAL_VAR(ConChannelMask, DBG_CHN_MESG, NULL, DT_BASIC_CONST_INT) INTERNAL_VAR(StdChannelMask, 0, NULL, DT_BASIC_CONST_INT) +INTERNAL_VAR(UseEmacsBindings, TRUE, NULL, DT_BASIC_CONST_INT) INTERNAL_VAR(UseXTerm, TRUE, NULL, DT_BASIC_CONST_INT) /* debugging debugger */ INTERNAL_VAR(ExtDbgOnInvalidAddress, FALSE, NULL, DT_BASIC_CONST_INT) +INTERNAL_VAR(ExtDbgOnInternalException, FALSE, NULL, DT_BASIC_CONST_INT) /* current process/thread */ INTERNAL_VAR(ThreadId, FALSE, &DEBUG_CurrTid, DT_BASIC_CONST_INT)

Dec. 21, 2002

Re: wine + eBay's auction-tool "MisterLister"

by Sylvain Petreolle

In terms o standards , this threads opens a new question : why not have a standard for bug reporting ? We could create create a document named 'BUGREPORT' and refer to it in any question we are asked to answer. > Did you try it? Why not? There are a zillion win programs out there, > and a > zillion patterns how to use those programs. So best is you try your > favorite > programm. Report success to the application database and report > failures/problems in the bug list or here with a good error report. > Have a look in the archive, to find out what is a good report. > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Dec. 21, 2002

Re: wine + eBay's auction-tool "MisterLister"

by Uwe Bonnes

>>>>> "Siegfried" == Siegfried Haas <KatjaundSiegfried.Haas(a)t-online.de> writes: Siegfried> Hello everybody - I am not a "developer, but I choose this Siegfried> way to make a suggestion! I tried to start eBay's Siegfried> auction-tool "MisterLister", which allows to edti the Siegfried> auctions offline and do an upload of 100 auctions in one Siegfried> time, with wine - but it doesn't work. I asked at eBay, if Siegfried> other systems then "Windows" are supported in anyway, but Siegfried> they told off. That's quiet unlucky, because that is the Siegfried> only remaining reason for me, to leave the Siegfried> "Windows-partition" on my system! Is there a possibility to Siegfried> start "MisterLister" with wine? Did you try it? Why not? There are a zillion win programs out there, and a zillion patterns how to use those programs. So best is you try your favorite programm. Report success to the application database and report failures/problems in the bug list or here with a good error report. Have a look in the archive, to find out what is a good report. Siegfried> I think, that would be a Siegfried> realy useful project, and i guess, a lot of Linux-user would Siegfried> be happy about a soliution "MisterLister-working-on-Linux"?! Siegfried> Thank's for reading and perhaps someone thinks about 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 ----------

Dec. 21, 2002

Re: wineboot - Andy's version

by Shachar Shemesh

Hi Alexander, Just wanted to know whether this fell through the cracks, or whether there was another reason this was not commited to CVS. Shachar Shachar Shemesh wrote: > Changelog: > Andreas Mohr > > programs/wineboot > > * Initial implementation > >

Dec. 21, 2002

wine + eBay's auction-tool "MisterLister"

by KatjaundSiegfried.Haas＠t-online.de

Hello everybody - I am not a "developer, but I choose this way to make a suggestion! I tried to start eBay's auction-tool "MisterLister", which allows to edti the auctions offline and do an upload of 100 auctions in one time, with wine - but it doesn't work. I asked at eBay, if other systems then "Windows" are supported in anyway, but they told off. That's quiet unlucky, because that is the only remaining reason for me, to leave the "Windows-partition" on my system! Is there a possibility to start "MisterLister" with wine? I think, that would be a realy useful project, and i guess, a lot of Linux-user would be happy about a soliution "MisterLister-working-on-Linux"?! Thank's for reading and perhaps someone thinks about it Greatings Siegfried

Dec. 21, 2002

Fwd: Get rid of W->A calls: GetPrinterDriverDirectory

by Stefan Leichter

Hello, is there any reason why this patch did not made it into CVS & 20021219? Stefan ---------- Weitergeleitete Nachricht ---------- Subject: Get rid of W->A calls: GetPrinterDriverDirectory Date: Sun, 15 Dec 2002 10:24:44 +0100 From: Stefan Leichter <Stefan.Leichter(a)camLine.com> To: wine-patches(a)winehq.com Hello, after spending some days fixing the read-write errors on my DDYS-T18350 disk here a new patch Changelog ------------ moved implementation of GetPrinterDriverDirectory from ascii to unicode Index: dlls/winspool/info.c =================================================================== RCS file: /home/wine/wine/dlls/winspool/info.c,v retrieving revision 1.61 diff -u -r1.61 info.c --- dlls/winspool/info.c 12 Nov 2002 02:22:24 -0000 1.61 +++ dlls/winspool/info.c 15 Dec 2002 08:40:09 -0000 @@ -41,6 +41,7 @@ #include "winbase.h" #include "winerror.h" #include "winreg.h" +#include "winternl.h" #include "wine/windef16.h" #include "wine/unicode.h" #include "wine/debug.h" @@ -2390,23 +2391,23 @@ } /*************************************************************************** ** - * GetPrinterDriverDirectoryA [WINSPOOL.@] + * GetPrinterDriverDirectoryW [WINSPOOL.@] */ -BOOL WINAPI GetPrinterDriverDirectoryA(LPSTR pName, LPSTR pEnvironment, +BOOL WINAPI GetPrinterDriverDirectoryW(LPWSTR pName, LPWSTR pEnvironment, DWORD Level, LPBYTE pDriverDirectory, DWORD cbBuf, LPDWORD pcbNeeded) { DWORD needed; - TRACE("(%s, %s, %ld, %p, %ld, %p)\n", pName, pEnvironment, Level, - pDriverDirectory, cbBuf, pcbNeeded); + TRACE("(%s, %s, %ld, %p, %ld, %p)\n", debugstr_w(pName), + debugstr_w(pEnvironment), Level, pDriverDirectory, cbBuf, pcbNeeded); if(pName != NULL) { - FIXME("pName = `%s' - unsupported\n", pName); + FIXME("pName = `%s' - unsupported\n", debugstr_w(pName)); SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } if(pEnvironment != NULL) { - FIXME("pEnvironment = `%s' - unsupported\n", pEnvironment); + FIXME("pEnvironment = `%s' - unsupported\n", debugstr_w(pEnvironment)); SetLastError(ERROR_INVALID_ENVIRONMENT); return FALSE; } @@ -2414,10 +2415,16 @@ WARN("Level = %ld - assuming 1\n", Level); /* FIXME should read from registry */ - needed = GetSystemDirectoryA(pDriverDirectory, cbBuf); + needed = GetSystemDirectoryW( (LPWSTR)pDriverDirectory, cbBuf/sizeof(WCHAR)); + /* GetSystemDirectoryW returns number of TCHAR without '\0' + * adjust this now + */ needed++; + needed*=sizeof(WCHAR); + if(pcbNeeded) *pcbNeeded = needed; + TRACE("required <%08lx>\n", *pcbNeeded); if(needed > cbBuf) { SetLastError(ERROR_INSUFFICIENT_BUFFER); return FALSE; @@ -2427,25 +2434,41 @@ /*************************************************************************** ** - * GetPrinterDriverDirectoryW [WINSPOOL.@] + * GetPrinterDriverDirectoryA [WINSPOOL.@] */ -BOOL WINAPI GetPrinterDriverDirectoryW(LPWSTR pName, LPWSTR pEnvironment, +BOOL WINAPI GetPrinterDriverDirectoryA(LPSTR pName, LPSTR pEnvironment, DWORD Level, LPBYTE pDriverDirectory, DWORD cbBuf, LPDWORD pcbNeeded) { - LPSTR pNameA = NULL, pEnvironmentA = NULL; + UNICODE_STRING nameW, environmentW; BOOL ret; - - if(pName) - pNameA = HEAP_strdupWtoA( GetProcessHeap(), 0, pName ); - if(pEnvironment) - pEnvironmentA = HEAP_strdupWtoA( GetProcessHeap(), 0, pEnvironment ); - ret = GetPrinterDriverDirectoryA( pNameA, pEnvironmentA, Level, - pDriverDirectory, cbBuf, pcbNeeded ); - if(pNameA) - HeapFree( GetProcessHeap(), 0, pNameA ); - if(pEnvironmentA) - HeapFree( GetProcessHeap(), 0, pEnvironmentA ); + DWORD pcbNeededW; + INT len = cbBuf * sizeof(WCHAR)/sizeof(CHAR); + WCHAR *driverDirectoryW = NULL; + + if (len) driverDirectoryW = HeapAlloc( GetProcessHeap(), 0, len ); + + if(pName) RtlCreateUnicodeStringFromAsciiz(&nameW, pName); + else nameW.Buffer = NULL; + if(pEnvironment) RtlCreateUnicodeStringFromAsciiz(&environmentW, pEnvironment); + else environmentW.Buffer = NULL; + + ret = GetPrinterDriverDirectoryW( nameW.Buffer, environmentW.Buffer, Level, + (LPBYTE)driverDirectoryW, len, &pcbNeededW ); + if (ret) { + ret = WideCharToMultiByte( CP_ACP, 0, driverDirectoryW, -1, + pDriverDirectory, cbBuf, NULL, NULL); + *pcbNeeded = WideCharToMultiByte( CP_ACP, 0, driverDirectoryW, -1, + NULL, 0, NULL, NULL); + } else + *pcbNeeded = pcbNeededW * sizeof(CHAR)/sizeof(WCHAR); + + TRACE("provided<%ld> required <%ld>\n", cbBuf, *pcbNeeded); + + if(driverDirectoryW) + HeapFree( GetProcessHeap(), 0, driverDirectoryW ); + RtlFreeUnicodeString(&environmentW); + RtlFreeUnicodeString(&nameW); return ret; } -------------------------------------------------------

Dec. 21, 2002

Re: [ros-kernel] Re: Wine 0.9 TODO v0.7

by Dmitry Timoshkov

"Casper Hornstrup" <chorns(a)users.sourceforge.net> wrote: > dlltool isn't needed anymore to build dlls. gcc -shared will do the same > without any .def/.edf files. Yes, I know. I was talking about removing stdcall decorations from exported symbols in DLLs which is currently done in ROS by having two sets of .def files (.def and .edf) with and without name decorations. Latest binutils allow to have only one .def file with decorated names. Wine build system utilizes that possibility. -- Dmitry.

Dec. 20, 2002

shlwapi/clist test error on NT4

by Francois Gouget

OPn NT4 the clist shwlwapi test fails on the first call to SHLWAPI_166 (on line 478 here). That call triggers wat looks like an internal check which pops up a nice error window: Debug Error! Program: ...dlls\shlwapi\tests\Output\Win32_MSVC_Headers\shlwapi_test.exe Module: File: i386\chkesp.c Line: 42 The value of ESP was not properly saved accross a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a differen calling convention. (Press Retry to debug the application) Could it be a problem with the way IDummyStream is declared? Maybe the virtual function pointer is off? I noticed that no 'COM' macro was used which sees a bit strange. Or maybe it's a problem with the prototype of SHLWAPI_166? Could someone more knowledgeable with shlwapi investigate this? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

Dec. 20, 2002

[RFC] wintab dll design: how to intergrate with current X11 code.

by Robert North

Ok, I'm about to start some serious implementation on the wintab dll. What I need now is some giudance as to how to proceed, regarding integration with X11 code. Please comment on anything mentioned below. If this is too concise, please ask for further clasification. *****Requirement for interfacing with X11***** To access the graphics tablet, the dll must access the XInput extension to X11. Therefore it needs some level of cooperation/integration with x11_drv. The reqirements are: Access to an XDisplay object. Event dispatch code similar to event.c It must be able to claim XInput events, and expose them through the wintab32.dll interface. Wintab32.dll is defined as having it's own event dispatch system, totally distinct from the win32 system. Access to an X window that contains the wine/win32 window client area. This is available in a win32 property named: __wine_x11_client_window. It is also accessible through x11_drv internals. If necessary, could always use the DefaultRootWindow(display)!. *********Assumptions****** It is bad practice/impossible to call functions from one dll in another, if they are not defined in the .spec file. I'm also assuming the same applies to variables. A call to XOpenDisplay(NULL) will ensure the same display is accessed as in X11_Drv. It is a good idea to call XInput functions in the wintab32.dll. It is a good idea to access the X11 windows needed by the Win32 window's propery. will reqire that the GetProp and GlobalFindAtom functions in wine. Wintab can be given it's own version of WaitForMultipleObjectsEx that will deal solely with XInput events. I'm also assuming that there is no reason why XInput events should occur in ***********Questions******* Is function X11DRV_MsgWaitForMultipleObjectsEx really the place where all X11 events enter the system before being translated into win32/16 events? It appears to be a principle of wine design that all X11 code should live in the x11_drv dll. Therefore, when complete, where should XInput code live? *************Design principles********** Genericity. I would like anything in X11_drv to be as generic as possible. So, Initially, I'd like to keep code in X11_drv to a minimun. Therefore, Given the ideas above, all XInput code is in wintab32.dll! ********** And that's it! *********** Well that's the lot, Please comment Cheers -Rob.

Dec. 20, 2002

Re: Some strange winedbg regression...

by Tony Lambregts

Lionel Ulmer wrote: >Hello, > >Seems that lately, as soon as I press a key in the debugger, it segfaults >and starts another debugger ... which will also segtault ... und so weiter. > >So I was wondering how to debug this ? I tried to attach 'gdb' to it (and it >works) but how do I know which symbols to load (winedbg being a script, wine >having no code except linking to DLLs, ....) ? > > Lionel > > > I have the same problem when debugging a certain program (dink smallwood) but not with others. Debugging winzip does not have this problem. the problem started at least a week ago but I have not had time to do a regression set on it. -- Tony Lambregts

Dec. 20, 2002

RE: [ros-kernel] Re: Wine 0.9 TODO v0.7

by Casper Hornstrup

> -----Original Message----- > From: Steven Edwards [mailto:steven_ed4153(a)yahoo.com] > Sent: 20. december 2002 17:41 > To: Dmitry Timoshkov; dpaun(a)rogers.com > Cc: wine-devel(a)winehq.com; ros-kernel(a)reactos.com > Subject: [ros-kernel] Re: Wine 0.9 TODO v0.7 > > > > --- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > "Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > > > > > We still need to double check the latest import lib and winebuild > > > changes on Mingw32. I am going to be swamped for the next week or > > > two. > > > > Alexandre told me that it works for him with binutils > 2.13.90. I have > > tested it under Cygwin and can confirm that it works for me > too after > > latest winebuild import fixes from Alexandre. > > > > Btw, you can suggest ReactOS people to look how handling of import > > libs via .def files done in Wine and get rid of that ugly .def/.edf > > stuff. > > I will look in to it when I get back from my vacation in a > few weeks unless one of the ReactOS guys is interested. > > Thanks > Steven dlltool isn't needed anymore to build dlls. gcc -shared will do the same without any .def/.edf files. Casper Hornstrup

Dec. 20, 2002

Some strange winedbg regression...

by Lionel Ulmer

Hello, Seems that lately, as soon as I press a key in the debugger, it segfaults and starts another debugger ... which will also segtault ... und so weiter. So I was wondering how to debug this ? I tried to attach 'gdb' to it (and it works) but how do I know which symbols to load (winedbg being a script, wine having no code except linking to DLLs, ....) ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 20, 2002

Conditional to support Solaris

by Robert Lunnon

I need to introduce a compile time conditional to better facilitate Solaris, in particular the macro ADDRESS_SPACE_LIMIT in virtual.c. I understand HAVE_SOLARIS is frowned upon so can anyone suggest a more targetted alternative (Could use __sysv__ but who knows whether all SYSV implementations need to define ADDRESS_SPACE_LIMIT the same way !) Bob

Dec. 20, 2002

Re: Listview report mode tweaks #2

by Dimitrie O. Paun

On December 20, 2002 01:02 pm, Duane Clark wrote: > So the only fix to LISTVIEW_GetSubItemRect that remains is to change the > offset that is applied. This looks great. Another small nit: + if (!(uFormat & (DT_RIGHT | DT_CENTER))) + { + if (himl && lvItem.iImage >= 0 && !IsRectEmpty(&rcIcon)) rcLabel.left += 2; + else rcLabel.left += 5; + } + else if (uFormat & DT_RIGHT) rcLabel.right -= 5; It seems this "5" is the same, so maybe a symbolic constant would be better. Also, it seems the 2 has to do with IMAGE_PADDING which you changed to 0, so maybe a small rearangement can make this thing more clear. What I mean is that you disabled image padding, and you achive it some other way using explicit numbers (2, 5, etc). Turning the logic inside out, maybe we can give meaning back to IMAGE_PADDING. If not, we should remove it and introduce another meaningful constant. -- Dimi.

Dec. 20, 2002

Re: rpcdce.h fixes

by Dimitrie O. Paun

On December 20, 2002 12:21 pm, Francois Gouget wrote: > No. If it's supposed to be 'unsigned char*' then that's how it should be > and Wine's code just has to deal with it. I am not the one maintaining the rpcdce code, so I don't really care. Ove and Alexandre should determine what to do. I don't have time to fix the warnings though, so someone else will have to run with this. -- Dimi.

Dec. 20, 2002

Re: rpcdce.h fixes

by Francois Gouget

On Fri, 20 Dec 2002, Dimitrie O. Paun wrote: > On December 20, 2002 04:55 am, Ove Kaaven wrote: > > It does, but it was more difficult to get things (rpcrt4 in particular) to > > compile without warnings (or huge piles of typecasts) this way, so I > > decided to just use LPSTR/LPWSTR instead in the rpc headers. Didn't think > > it would cause problems. > > It does, in C++ because of stronger typing than in C. We can do a conditional > thing #ifdef __WINE__ ... Alexandre? No. If it's supposed to be 'unsigned char*' then that's how it should be and Wine's code just has to deal with it. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

Dec. 20, 2002

Re: ThunkTheTemplateHandle and Kazaa

by Acke Carlsson

Hi On Friday 20 December 2002 02:31 pm, you wrote: > > It's works for me on Wine-cvs-20021219. Kazaa was broken for a time, > > but has now work for at least 2-weeks. I don't think the problem was in > > Wine, the solution was to load "winedefault.reg". > > Yes I've got all that. Kazaa 2.0.2 (or is it 2.2... the new one anyway) > calls ThunkTheTemplateHandle when running in Win98 mode. This function > needs an implementation to work - a lot of people have similar problems if > you read the compatability db and forums... I suspect their problem is > also this function. > > So getting a working implementation (and as I said, from my uneducated > debugging it seems to be nothing much more than a wrapper function) into > WINE would be very nice :) > > Cheers, > Ender If it's Kazaa Lite 2.0.2 (no spyware and it's the new) I have it running, look on the about snapshot 5-min old. The full version including spyware I have not test but that I don't find in version 2.0.2 on the net. Mean "running in Win98 mode" the [Version] tag in .wine/config I have "Windows" = "win98". Looking for the calls ThunkTheTemplateHandle give nothing, [ace(a)ackes KaZaA Lite]$ wine Kazaa.exe &> Kazaa.exe.log [ace(a)ackes KaZaA Lite]$ grep ThunkTheTemplateHandle Kazaa.exe.log [ace(a)ackes KaZaA Lite]$ But the include "Speed Up.exe" don't run, and Kazaa.exe go down then try to run it. How do I check the version on the native dlls under Wine. My are from a Swedish Win98SE maybe that ...

Dec. 20, 2002

Re: Listview report mode tweaks

by Duane Clark

Dimitrie O. Paun wrote: > On December 19, 2002 07:48 pm, Duane Clark wrote: > >>I also altered LISTVIEW_GetSubItemRect so that it reports correct >>values, as compared against WinNT on ControlSpy. > > > Problem is that LISTVIEW_GetSubItemRect is documented to return > same thing for LVIR_LABEL and LVIR_BOUNDS. Of course, incorrect > documentation is known to exist, so as long as you checked it... > > However, when we implement things different from the documented > behavior, a clear comment explaining why we deviate is appropriate. > Otherwise, someone might get rid of it in the future. :( > Well well... I had not read the docs that closely. I did not expect the definition of LVIR_LABEL to depend on what function used it. This might require that I do a bit more testing. I had noticed that LISTVIEW_GetSubItemRect was only specified for use with a "one-based index of the subitem", but it works fine on WinNT with subitem '0', the first item. A little more testing shows that with subitem '0', LISTVIEW_GetSubItemRect succeeds with LVIR_SELECTBOUNDS too, but that item fails for any other subitem. So I suspect the correct behavior is for subitem '0' to pass the request on to LISTVIEW_GetItemRect. For non zero subitems I may need to try to get icons inserted into another column to test with.

Dec. 20, 2002

Re: Conformance tests failing

by chrismorgan＠rcn.com

It looks like my NT4 machine is setup differently than the ones running those tests, or perhaps all default windows installs. The issue is that for LOCALE_SYSTEM_DEFAULT the default format that we are looking for is "h:m:s tt", the one that on the testing machines is "HH:m:s", this results in "8:46 AM" -> "08:56" for TIME_NOSECONDS and "8AM" -> "08" for TIME_NOMINUTESORSECONDS. Not sure what the correct way to resolve this is as it appears the default can change, maybe we shouldn't be testing against the defaults? Afaik these tests pass under wine so maybe wine has incorrect default nls values? Chris > > From: Paul Millar <paulm(a)astro.gla.ac.uk> > Date: 2002/12/20 Fri AM 07:10:27 EST > To: Development to WINE <wine-devel(a)winehq.com> > Subject: Conformance tests failing > > Hi everyone, > > The extra support added by Chris in: > http://cvs.winehq.com/patch.py?id=6743 > doesn't seem be enough for wine to pass all of his new conformance tests > added in: > http://cvs.winehq.com/patch.py?id=6744 > A few of them failed, caused WRT reported: > > locale.c:164: Test failed 1 of 1 time (100%): > [test instance 1] > locale.c:164: Test failed: GetTimeFormat: got 6 instead of 8 > > locale.c:146: Test failed 1 of 1 time (100%): > [test instance 1] > locale.c:146: Test failed: GetTimeFormat got '08' instead of '8 AM' > > locale.c:147: Test failed 1 of 1 time (100%): > [test instance 1] > locale.c:147: Test failed: GetTimeFormat: got 3 instead of 5 > > locale.c:163: Test failed 1 of 1 time (100%): > [test instance 1] > locale.c:163: Test failed: GetTimeFormat got '08:56' instead of '8:56 AM' > > for 95, 98, me, NT, Win2k, ... (the database is still updating at the > moment) > > Details of the build are available at: > http://www.astro.gla.ac.uk/users/paulm/WRT/buildinfo.php?id=271 > > ---- > Paul Millar > > > > >

Dec. 20, 2002

Re: Wineconsole 'regression'

by Lionel Ulmer

> that's a feature (see previous discussion on wineconsole implementation) > we could add an option for that, but it's better to fix actually the > curses implementation *first* Yeah, this is what I though too :-) > does this attached patch solves some issues ? (it won't solve all of the > issues for ida) It works a LOT better (and it's a lot faster than the USER based one too). It's still a bit flaky (ie no 'Alt-XX' shortcuts or some GUI stuff like sliders and stuff are not displayed) but IDA is now mostly usable. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 20, 2002

Re: Conformance tests failing

by chrismorgan＠rcn.com

I'll take a look at it and see what might be up. The tests all passed on my nt4 machine and on my local wine with the ole2nls changes, it should be pretty easy to resolve these issues. Chris > > From: Paul Millar <paulm(a)astro.gla.ac.uk> > Date: 2002/12/20 Fri AM 07:10:27 EST > To: Development to WINE <wine-devel(a)winehq.com> > Subject: Conformance tests failing > > Hi everyone, > > The extra support added by Chris in: > http://cvs.winehq.com/patch.py?id=6743 > doesn't seem be enough for wine to pass all of his new conformance tests > added in: > http://cvs.winehq.com/patch.py?id=6744 > A few of them failed, caused WRT reported: > > locale.c:164: Test failed 1 of 1 time (100%): > [test instance 1] > locale.c:164: Test failed: GetTimeFormat: got 6 instead of 8 > > locale.c:146: Test failed 1 of 1 time (100%): > [test instance 1] > locale.c:146: Test failed: GetTimeFormat got '08' instead of '8 AM' > > locale.c:147: Test failed 1 of 1 time (100%): > [test instance 1] > locale.c:147: Test failed: GetTimeFormat: got 3 instead of 5 > > locale.c:163: Test failed 1 of 1 time (100%): > [test instance 1] > locale.c:163: Test failed: GetTimeFormat got '08:56' instead of '8:56 AM' > > for 95, 98, me, NT, Win2k, ... (the database is still updating at the > moment) > > Details of the build are available at: > http://www.astro.gla.ac.uk/users/paulm/WRT/buildinfo.php?id=271 > > ---- > Paul Millar > > > > >

Dec. 20, 2002

Re: Wine 0.9 TODO v0.7

by Steven Edwards

--- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > "Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > > > We still need to double check the latest import lib and winebuild changes on Mingw32. > > I am going to be swamped for the next week or two. > > Alexandre told me that it works for him with binutils 2.13.90. > I have tested it under Cygwin and can confirm that it works for me too > after latest winebuild import fixes from Alexandre. > > Btw, you can suggest ReactOS people to look how handling of import libs > via .def files done in Wine and get rid of that ugly .def/.edf stuff. I will look in to it when I get back from my vacation in a few weeks unless one of the ReactOS guys is interested. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Dec. 20, 2002

Re: IE5.5 and 6.0sp1 error [Unimplimented]

by Greg Turner

On Thursday 19 December 2002 11:04 pm, Boris wrote: > I just downloaded the latest cvs on a system without windows files. I > tried to install IE5.5 and IE 6.0sp1 as win2k or winxp and as it > tries to install, the following error occurs > > Unimplimented Kernel32.dll.VerSetConditionMask in 32bit mode. Anyone > looking to write an update to kernel32.dll to add the function? I don't know about this API, but, you can set the version to nt40, and use "wine --dll urlmon=n ie5setup" to get IE55 setup to mostly succeed. -- gmt

Dec. 20, 2002

Re: Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library

by Dimitrie O. Paun

On December 20, 2002 02:07 am, Francois Gouget wrote: > Does this work? It seems to work very well! It can go to Alexandre as far as I'm concerned. Thanks. -- Dimi.

Dec. 20, 2002

Re: rpcdce.h fixes

by Dimitrie O. Paun

On December 20, 2002 04:55 am, Ove Kaaven wrote: > It does, but it was more difficult to get things (rpcrt4 in particular) to > compile without warnings (or huge piles of typecasts) this way, so I > decided to just use LPSTR/LPWSTR instead in the rpc headers. Didn't think > it would cause problems. It does, in C++ because of stronger typing than in C. We can do a conditional thing #ifdef __WINE__ ... Alexandre? -- Dimi.

Dec. 20, 2002

Re: ThunkTheTemplateHandle and Kazaa

by Ender

> It's works for me on Wine-cvs-20021219. Kazaa was broken for a time, > but has now work for at least 2-weeks. I don't think the problem was in > Wine, the solution was to load "winedefault.reg". Yes I've got all that. Kazaa 2.0.2 (or is it 2.2... the new one anyway) calls ThunkTheTemplateHandle when running in Win98 mode. This function needs an implementation to work - a lot of people have similar problems if you read the compatability db and forums... I suspect their problem is also this function. So getting a working implementation (and as I said, from my uneducated debugging it seems to be nothing much more than a wrapper function) into WINE would be very nice :) Cheers, Ender

Dec. 20, 2002

Conformance tests failing

by Paul Millar

Hi everyone, The extra support added by Chris in: http://cvs.winehq.com/patch.py?id=6743 doesn't seem be enough for wine to pass all of his new conformance tests added in: http://cvs.winehq.com/patch.py?id=6744 A few of them failed, caused WRT reported: locale.c:164: Test failed 1 of 1 time (100%): [test instance 1] locale.c:164: Test failed: GetTimeFormat: got 6 instead of 8 locale.c:146: Test failed 1 of 1 time (100%): [test instance 1] locale.c:146: Test failed: GetTimeFormat got '08' instead of '8 AM' locale.c:147: Test failed 1 of 1 time (100%): [test instance 1] locale.c:147: Test failed: GetTimeFormat: got 3 instead of 5 locale.c:163: Test failed 1 of 1 time (100%): [test instance 1] locale.c:163: Test failed: GetTimeFormat got '08:56' instead of '8:56 AM' for 95, 98, me, NT, Win2k, ... (the database is still updating at the moment) Details of the build are available at: http://www.astro.gla.ac.uk/users/paulm/WRT/buildinfo.php?id=271 ---- Paul Millar

Dec. 20, 2002

Re: I need help debugging COM

by Ove Kaaven

On Fri, 20 Dec 2002, Mehmet YASAR wrote: > Hi, > > I'm working on enhancing Wine's Ddraw surface code. I have not enough > experience of COM (and very small knowledge asm) to understand why I > have a crash on the following line in my test app test.exe : > > lpov->Lock(NULL, &SurfaceDesc, DDLOCK_WAIT, NULL); > > Here is more info on the crash : > > Wine-dbg>c > First chance exception: page fault on read access to 0x00000064 in > 32-bit code (0x00401a7b). I'd say this probably points to that the vtbl of the interface pointed to by lpov has not been initialized (the vtbl seems to be a null pointer). Perhaps you should look into the surface constructor code.

Dec. 20, 2002

I need help debugging COM

by Mehmet YASAR

Hi, I'm working on enhancing Wine's Ddraw surface code. I have not enough experience of COM (and very small knowledge asm) to understand why I have a crash on the following line in my test app test.exe : lpov->Lock(NULL, &SurfaceDesc, DDLOCK_WAIT, NULL); Here is more info on the crash : Wine-dbg>c First chance exception: page fault on read access to 0x00000064 in 32-bit code (0x00401a7b). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0007 EIP:00401a7b ESP:406d28e8 EBP:406d2c68 EFLAGS:00010206( R- 00 I - -P1 ) EAX:403c670c EBX:4086b8bc ECX:403c670c EDX:00000000 ESI:406d2bec EDI:406d2c64 Stack dump: 0x406d28e8 (NTDLL.DLL.memcpy+0x4287b8): 403c670c 00000000 406d2bfc 00000001 0x406d28f8 (NTDLL.DLL.memcpy+0x4287c8): 00000000 00020022 00000000 40098c19 0x406d2908 (NTDLL.DLL.memcpy+0x4287d8): 4086b478 400fa444 406d2934 400be095 0x406d2918 (NTDLL.DLL.memcpy+0x4287e8): 4086b478 00000002 400fa25f 40110360 0x406d2928 (NTDLL.DLL.memcpy+0x4287f8): 4086b8bc 00000000 406d29f0 406d2944 0x406d2938 (NTDLL.DLL.memcpy+0x428808): 408116fc 4086b478 4086b8bc 406d29d8 0x406d2948 (NTDLL.DLL.memcpy+0x428818): 0011: sel=008f base=40110360 limit=00000fff 32-bit rw- Backtrace: =>0 0x00401a7b (test.exe..text+0xa7b in Y:\devel\test.exe) (ebp=406d2c68) 1 0x004028ee (test.exe..text+0x18ee in Y:\devel\test.exe) (ebp=406d2d0c) 2 0x4081a3c3 (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=406d2d30) 3 0x4081a45d (WINPROC_CallWndProc+0x8d(proc=0x402860, hwnd=0x20022, msg=0x708, wParam=0x0, lParam=0x0) [winproc.c:183] in user32.dll.so) (ebp=406d2d60) ll.so) (ebp=406d2d60) 4 0x40820e52 (CallWindowProcA+0xb2(func=0x40e80458, hwnd=0x20022, msg=0x708, wParam=0x0, lParam=0x0) [winproc.c:2789] in user32.dll.so) (ebp=406d2d94) l.so) (ebp=406d2d94) 5 0x40802114 (DispatchMessageA+0x134(msg=0x406d2de8) [message.c:1094] in user32.dll.so) (ebp=406d2dd8) 6 0x00402747 (test.exe..text+0x1747 in Y:\devel\test.exe) (ebp=406d2e04) 7 0x00402fe5 (test.exe.EntryPoint+0xce in Y:\devel\test.exe) (ebp=406d2e90) 8 0x400b92bf (start_process+0x24f [process.c:564] in libntdll.dll.so) (ebp=406d2f38) 9 0x400bda27 (call_on_thread_stack+0x27(func=0x400b9070) [sysdeps.c:112] in libntdll.dll.so) (ebp=406d2ff4) 10 0x400bdbe0 (SYSDEPS_CallOnStack+0x14 in libntdll.dll.so) (ebp=00000000) 0x00401a7b (test.exe..text+0xa7b in Y:\devel\test.exe): call *0x64(%edx) Wine-dbg>disas 0x00401a7b (test.exe..text+0xa7b in Y:\devel\test.exe): call *0x64(%edx) 0x00401a7e (test.exe..text+0xa7e in Y:\devel\test.exe): movl %eax,0xffffff5c(%ebp) 0x00401a84 (test.exe..text+0xa84 in Y:\devel\test.exe): movl 0xffffff5c(%ebp),%ecx 0x00401a8a (test.exe..text+0xa8a in Y:\devel\test.exe): pushl %ecx 0x00401a8b (test.exe..text+0xa8b in Y:\devel\test.exe): pushl $0x40a164 0x00401a90 (test.exe..text+0xa90 in Y:\devel\test.exe): pushl $0x1 0x00401a92 (test.exe..text+0xa92 in Y:\devel\test.exe): call 0x00402510 (test.exe..text+0x1510 in Y:\devel\test.exe) 0x00401a97 (test.exe..text+0xa97 in Y:\devel\test.exe): addl $12,%esp 0x00401a9a (test.exe..text+0xa9a in Y:\devel\test.exe): cmpl $0x88760104,0xffffff5c(%ebp) 0x00401aa4 (test.exe..text+0xaa4 in Y:\devel\test.exe): jz 0x00401ab2 (test.exe..text+0xab2 in Y:\devel\test.exe) I have certainly introduced bugs in ddraw code, but where should I look ? Mehmet

Dec. 20, 2002

Re: rpcdce.h fixes

by Ove Kaaven

On Fri, 20 Dec 2002, Dimitrie O. Paun wrote: > MinGW has them defined this way, and wxWindows likes them like this. > Can someone please check that this matches the Windows headers? It does, but it was more difficult to get things (rpcrt4 in particular) to compile without warnings (or huge piles of typecasts) this way, so I decided to just use LPSTR/LPWSTR instead in the rpc headers. Didn't think it would cause problems. > RPCRTAPI RPC_STATUS RPC_ENTRY > - RpcStringFreeA(LPSTR* String); > + RpcStringFreeA(unsigned char** String); > RPCRTAPI RPC_STATUS RPC_ENTRY > - RpcStringFreeW(LPWSTR* String); > + RpcStringFreeW(unsigned short** String); > #define RpcStringFree WINELIB_NAME_AW(RpcStringFree)

Dec. 20, 2002

Re: ThunkTheTemplateHandle and Kazaa

by Acke Carlsson

On Friday 20 December 2002 09:34 am, Ender wrote: > Hi all. > > Trying to run any recent version of Kazaa (Lite) under WINE fails for me, > as it trys to call an unimplemented krnl386.exe stub... ordinal 538 > (ThunkTheTemplateHandle). > > After doing a little minimal debugging, all I could see that ordinal doing > was messing with some segment pointers and calling ordinal 630 (C16ThkSL). > > I really have no idea what any of this stuff does (*cough*), although > copying the line for ordinal 630 into ordinal 538 makes Kazaa work for me > > :) > > I don't suppose anybody with a little more knowledge of this bit of > Windows knows what actually goes on here? It'd be nice to see this fixed > (properly :) in CVS, as Kazaa is a fairly popular application. > > Cheers, > Ender It's works for me on Wine-cvs-20021219. Kazaa was broken for a time, but has now work for at least 2-weeks. I don't think the problem was in Wine, the solution was to load "winedefault.reg". ${HOME}/.wine/config ---------------SNIP--------------- [AppDefaults\\kazaa.exe\\DllOverrides] "commctrl" = "native" "comctl32" = "native" "shdoclc" = "native" "shdocvw" = "native" "shlwapi" = "native" "ole32" = "native" "oleaut32" = "native" "rpcrt4" = "native" ---------------SNIP---------------

Dec. 20, 2002

ThunkTheTemplateHandle and Kazaa

by Ender

Hi all. Trying to run any recent version of Kazaa (Lite) under WINE fails for me, as it trys to call an unimplemented krnl386.exe stub... ordinal 538 (ThunkTheTemplateHandle). After doing a little minimal debugging, all I could see that ordinal doing was messing with some segment pointers and calling ordinal 630 (C16ThkSL). I really have no idea what any of this stuff does (*cough*), although copying the line for ordinal 630 into ordinal 538 makes Kazaa work for me :) I don't suppose anybody with a little more knowledge of this bit of Windows knows what actually goes on here? It'd be nice to see this fixed (properly :) in CVS, as Kazaa is a fairly popular application. Cheers, Ender

Dec. 20, 2002

Re: Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library

by Dimitrie O. Paun

On December 20, 2002 02:07 am, Francois Gouget wrote: > Does this work? It might, but if I try to compile with the glibc headers, I get other problems not in that _stricmp, and _strdup are not declared. Which is odd, as I seem to have compiled with glibc headers a few files before... It's way past my bed time, I'll into it tomorrow. -- Dimi.

Dec. 20, 2002

Re: HELP: DEVMODE def

by Dimitrie O. Paun

On December 19, 2002 07:48 pm, Dan Kegel wrote: > gcc3.2 has them. I just verified that a fragment like that compiles fine > with g++3.2. Thank you. ChangeLog Enable nameless structures in C++ for gcc >= 3.x. (Discovery and testing done by Dan Kegel). Index: include/winnt.h =================================================================== RCS file: /var/cvs/wine/include/winnt.h,v retrieving revision 1.147 diff -u -r1.147 winnt.h --- include/winnt.h 19 Dec 2002 21:12:35 -0000 1.147 +++ include/winnt.h 20 Dec 2002 06:38:42 -0000 @@ -140,8 +140,8 @@ # define NONAMELESSSTRUCT # define NONAMELESSUNION #else -/* Anonymous struct support starts with gcc 2.96 */ -# if !defined(NONAMELESSSTRUCT) && (defined(__GNUC__) && (defined(__cplusplus) || ((__GNUC__ < 2) || ((__GNUC__ == 2) && (__GNUC_MINOR__ < 96))))) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) +/* Anonymous struct support starts with gcc 2.96 or gcc/g++ 3.x */ +# if !defined(NONAMELESSSTRUCT) && (defined(__GNUC__) && ((__GNUC__ < 2) || ((__GNUC__ == 2) && (defined(__cplusplus) || (__GNUC_MINOR__ < 96))))) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) # define NONAMELESSSTRUCT # endif /* Anonymous unions support starts with gcc 2.96/g++ 2.95 */ -- Dimi.

Dec. 20, 2002

Re: Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library

by Francois Gouget

On Wed, 18 Dec 2002, Dimitrie O. Paun wrote: > Folks, > > This does not work (<= is include): > winsock.h > <= sys/types.h > <= sys/select.h > > BANG! FD_CLR gets defined before we have a chance to manipulate it. > > Any ideas on how to fix this? Does this work? There might still be problems with FreeBSD but I did not have time to check today... Index: include/winsock.h =================================================================== RCS file: /home/wine/wine/include/winsock.h,v retrieving revision 1.49 diff -u -r1.49 winsock.h --- include/winsock.h 21 Nov 2002 23:44:19 -0000 1.49 +++ include/winsock.h 20 Dec 2002 01:14:39 -0000 @@ -56,29 +56,83 @@ /* * This section defines the items that conflict with the Unix headers. */ +#if !defined(USE_WS_PREFIX) && !defined(__WINE_USE_MSVCRT) +/* We are not using the WS_ prefix and not using the MSVCRT either so we + * risk getting conflicts for everything related to select. + */ +# ifdef FD_CLR +/* Too late, the Unix version of stdlib.h was included before winsock.h. + * This means select and all the related stuff is already defined and we + * cannot override types and function prototypes. + * All we can do is disable all these symbols so that they are not used + * inadvertantly. + */ +# undef FD_SETSIZE +# undef FD_CLR +# undef FD_SET +# undef FD_ZERO +# undef FD_ISSET -#ifndef __WINE_USE_MSVCRT -/* Get the u_xxx types from the Unix headers. They will do and doing it - * this way will avoid redefinitions. But on FreeBSD we may get macros - * and prototypes for htonl & co. This means the functions will not be - * called because of the macros. So this should not harm us too much unless - * we try to define our own prototypes (different calling convention). +# define FD_SETSIZE Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library +# define FD_CLR Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library +# define FD_SET Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library +# define FD_ZERO Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library +# define FD_ISSET Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library +# define fd_set Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library +# define select Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library +# include <sys/types.h> +# ifdef __MINGW_H + /* MinGW doesn't define the u_xxx types */ +# define WS_DEFINE_U_TYPES +# endif +# else +/* stdlib.h has not been included yet so it's not too late. Include it now + * making sure that none of the select symbols is affected. Then we can + * define them with our own values. */ +# define fd_set unix_fd_set +# define timeval unix_timeval +# define select unix_select +# include <sys/types.h> +# ifndef FD_CLR + /* On Windows-style platforms, sys/types.h does not define FD_CLR + * and does not define the u_xxx types + */ +# define WS_DEFINE_U_TYPES +# endif +# undef fd_set +# undef timeval +# undef select +# undef FD_SETSIZE +# undef FD_CLR +# undef FD_SET +# undef FD_ZERO +# undef FD_ISSET + +# define WS_DEFINE_SELECT +# endif /* FD_CLR */ + +#elif !defined(__WINE_USE_MSVCRT) +# define WS_DEFINE_SELECT # include <sys/types.h> -# if defined(USE_WS_PREFIX) || !defined(htonl) -# define WS_DEFINE_HTONL -# endif /* htonl */ +# ifndef FD_CLR + /* On Windows-style platforms, sys/types.h does not define FD_CLR + * and does not define the u_xxx types + */ +# define WS_DEFINE_U_TYPES +# endif #else -/* Since we are using the MSVCRT headers, we must define the u_xxx - * types ourselves. - */ +# define WS_DEFINE_SELECT + /* Our MSVCRT headers don't define the u_xxx types */ +# define WS_DEFINE_U_TYPES +#endif /* !USE_WS_PREFIX && !__WINE_USE_MSVCRT */ + +#ifdef WS_DEFINE_U_TYPES typedef unsigned char u_char; typedef unsigned short u_short; typedef unsigned int u_int; typedef unsigned long u_long; -# define WS_DEFINE_HTONL -#endif /* __WINE_USE_MSVCRT */ - +#endif /* @@ -349,55 +403,6 @@ * Select */ -#if !defined(USE_WS_PREFIX) && !defined(__WINE_USE_MSVCRT) -/* We are not using the WS_ prefix and not using the MSVCRT either so we - * risk getting conflicts for everything related to select. - */ -# ifdef FD_CLR -/* Too late, the Unix version of stdlib.h was included before winsock.h. - * This means select and all the related stuff is already defined and we - * cannot override types and function prototypes. - * All we can do is disable all these symbols so that they are not used - * inadvertantly. - */ -# undef FD_SETSIZE -# undef FD_CLR -# undef FD_SET -# undef FD_ZERO -# undef FD_ISSET - -# define FD_SETSIZE Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library -# define FD_CLR Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library -# define FD_SET Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library -# define FD_ZERO Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library -# define FD_ISSET Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library -# define fd_set Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library -# define select Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library -# else -/* stdlib.h has not been included yet so it's not too late. Include it now - * making sure that none of the select symbols is affected. Then we can - * define them with our own values. - */ -# define fd_set unix_fd_set -# define timeval unix_timeval -# define select unix_select -# include <stdlib.h> -# undef fd_set -# undef timeval -# undef select -# undef FD_SETSIZE -# undef FD_CLR -# undef FD_SET -# undef FD_ZERO -# undef FD_ISSET - -# define WS_DEFINE_SELECT -# endif /* FD_CLR */ - -#else -# define WS_DEFINE_SELECT -#endif /* !USE_WS_PREFIX && !__WINE_USE_MSVCRT */ - #ifdef WS_DEFINE_SELECT /* Define our own version of select and the associated types and macros */ @@ -929,12 +934,16 @@ int WINAPI WS(shutdown)(SOCKET,int); SOCKET WINAPI WS(socket)(int,int,int); -#ifdef WS_DEFINE_HTONL +#if defined(htonl) && !defined(USE_WS_PREFIX) +# undef htonl +# undef htons +# undef ntohl +# undef ntohs +#endif u_long WINAPI WS(htonl)(u_long); u_short WINAPI WS(htons)(u_short); u_long WINAPI WS(ntohl)(u_long); u_short WINAPI WS(ntohs)(u_short); -#endif #if defined(__WINE__) || !defined(__WINE_WINSOCK2__) /* Stuff specific to winsock.h */ -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

Dec. 20, 2002

Re: Listview report mode tweaks

by Dimitrie O. Paun

On December 19, 2002 07:48 pm, Duane Clark wrote: > I also altered LISTVIEW_GetSubItemRect so that it reports correct > values, as compared against WinNT on ControlSpy. Problem is that LISTVIEW_GetSubItemRect is documented to return same thing for LVIR_LABEL and LVIR_BOUNDS. Of course, incorrect documentation is known to exist, so as long as you checked it... However, when we implement things different from the documented behavior, a clear comment explaining why we deviate is appropriate. Otherwise, someone might get rid of it in the future. :( -- Dimi.

Dec. 20, 2002

Re: strcasecmp

by David Fraser

Dimitrie O. Paun wrote: >On December 19, 2002 09:26 am, Waldek Hebisch wrote: > > >>If we are going to seriously support mingw then we need "mingw headers". >>I am not sure if true mingw headres are different enuugh from normal >>wine and msvcrt headers to warrant extra subdirectory, but logically >>they form a separate set. I suggest to put conditionls (if needed) in >>msvcrt headers corresponding to mingw headers, and make a separate >>subdirectory for mingw headers which emulate Unix headers. >> >> > >Right. I haven't looked at the mingw headers, but I assume they are >rather similar to the ones in glibc. If that's the case, we can >reuse those (if you have gcc which you have to anyway if you want to >use the mingwrap stuff): > >[dimi(a)dimi wine.src]$ sed -n 290,296p /usr/lib/gcc-lib/i386-redhat-linux/3.2/include/stddef.h >#ifndef __WCHAR_TYPE__ >#define __WCHAR_TYPE__ int >#endif >#ifndef __cplusplus >typedef __WCHAR_TYPE__ wchar_t; >#endif >#endif > >Which means we can simply -D__WCHAR_TYPE__=unsigned\ short > >But we still can not link. For that, we need to reimplement all wchar_t >using functions, and link those in before the glibc ones. Linking tricks >are not my strenght, anyone know how we can do that? Does it work to >just place a lib with those symbols first in the -l list? > > > Not sure exactly what you're looking for here - but I think you're wanting to know about the way it resolves symbols. Basically symbol lookups are only done in libraries that appear later on the command line than the one needing the symbol. So if libb.a depends on liba.a, then gcc bladibla -lb -la will work while gcc bladibla -la -lb will fail. Hope that's relevant David

Dec. 20, 2002

IE5.5 and 6.0sp1 error [Unimplimented]

by Boris

I just downloaded the latest cvs on a system without windows files. I tried to install IE5.5 and IE 6.0sp1 as win2k or winxp and as it tries to install, the following error occurs Unimplimented Kernel32.dll.VerSetConditionMask in 32bit mode. Anyone looking to write an update to kernel32.dll to add the function?

Dec. 19, 2002

Re: RECT def

by Dmitry Timoshkov

"Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > ChangeLog > > MS uses LONG for the members of RECT. > > Of course, this causes a sh*tload of warnings. This may be a > good time to convert most of these to the debugrect function > that I used in listview.c. Sounds like a plan? Personally I like this idea. -- Dmitry.

Dec. 19, 2002

Re: Wine 0.9 TODO v0.7

by Dmitry Timoshkov

"Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > We still need to double check the latest import lib and winebuild changes on Mingw32. > I am going to be swamped for the next week or two. Alexandre told me that it works for him with binutils 2.13.90. I have tested it under Cygwin and can confirm that it works for me too after latest winebuild import fixes from Alexandre. Btw, you can suggest ReactOS people to look how handling of import libs via .def files done in Wine and get rid of that ugly .def/.edf stuff. -- Dmitry.

Dec. 19, 2002

About WineLib : there is a lack of API in wine

by Kevin

hi ::) I have an appliction of Windows. In the appliction i call createRemoteThread 、SetDCPenColor and setDCBrushcolor，but wine don't support those API functions ,if there has the related function in wine?? Thanks kevin wine-devel(a)winehq.com ----- Original Message ----- From: <wine-devel-request(a)winehq.com> To: <wine-devel(a)winehq.com> Sent: Friday, December 20, 2002 2:00 AM Subject: wine-devel digest, Vol 1 #1519 - 5 msgs > Send wine-devel mailing list submissions to > wine-devel(a)winehq.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.winehq.com/mailman/listinfo/wine-devel > or, via email, send a message with subject or body 'help' to > wine-devel-request(a)winehq.com > > You can reach the person managing the list at > wine-devel-admin(a)winehq.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wine-devel digest..." > > > Today's Topics: > > 1. Re: [D3D8 PATCH] d3d8 shaders update - VS2 (David Laight) > 2. Re: [D3D8 PATCH] d3d8 shaders update - VS2 (Zsolt Rizsanyi) > 3. RE: Win2000 Conformance Test Results... (Kye Lewis) > 4. Re: strcasecmp (Dimitrie O. Paun) > 5. Re: Update to patches sgml (Tony Lambregts) > > --__--__-- > > Message: 1 > Date: Thu, 19 Dec 2002 14:54:21 +0000 > From: David Laight <david(a)l8s.co.uk> > To: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Cc: Fabian Cenedese <Cenedese(a)indel.ch>, wine-devel(a)winehq.com > Subject: Re: [D3D8 PATCH] d3d8 shaders update - VS2 > > On Thu, Dec 19, 2002 at 07:08:40AM -0500, Dimitrie O. Paun wrote: > > On December 19, 2002 05:29 am, David Laight wrote: > > > No, and I would use it if I did :-) > ^^^ > not > > Finger trouble... > > > http://www.vim.org > > Probably... > > > David > > -- > David Laight: david(a)l8s.co.uk > > --__--__-- > > Message: 2 > From: Zsolt Rizsanyi <rizsanyi(a)myrealbox.com> > To: Fabian Cenedese <Cenedese(a)indel.ch>, wine-devel(a)winehq.com > Subject: Re: [D3D8 PATCH] d3d8 shaders update - VS2 > Date: Thu, 19 Dec 2002 16:06:51 +0100 > > On Thursday 19 December 2002 14:27, Fabian Cenedese wrote: > > Considering the age of these two it's maybe understandable why they > > don't have this feature. Tell me an editor in Windows and I may switch. > > There is windows version of Vim. Try that :) > > > --__--__-- > > Message: 3 > From: "Kye Lewis" <kyethespy(a)softhome.net> > To: "'Francois Gouget'" <fgouget(a)free.fr> > Cc: wine-devel(a)winehq.org > Subject: RE: Win2000 Conformance Test Results... > Date: Thu, 19 Dec 2002 16:30:59 +1100 > > XP Results Round 2: > > ** If a test is not listed here, then it has passed ** > > advapi32_test registry: No Change > > Note: Test now always has 3 failures, > No cases of more failures are apparent. > > kernel32_test process: No Change > > netapi32_test access: No Change > > shell32_test shfileop: No Change > > user32_test sysparams: No Change > > Thanks, > Kye Lewis > LinksOS Project Administrator > LinksOS Web Team Leader > kyethespy(a)softhome.net > (New email address! kyethespy(a)liquid2k.com will still work, but please > send all emails now to new email) > > "640k ought to be enough for anyone!" > - Bill Gates > > ================================= > LinksOS: Linking you to the world > http://linksos.cjb.net > http://linksos.sourceforge.net/ > http://linksos.oxygen-x.net/ > Now with Bugzilla and phpBB installed :) > ================================= > > > -----Original Message----- > From: wine-devel-admin(a)winehq.com [mailto:wine-devel-admin(a)winehq.com] > On Behalf Of Francois Gouget > Sent: Friday, December 13, 2002 8:58 AM > To: David Fraser > Cc: Kye Lewis; wine-devel(a)winehq.org > Subject: Re: Win2000 Conformance Test Results... > > > Hmmm, I meant to send this two days ago... > > > On Tue, 10 Dec 2002, David Fraser wrote: > [...] > > for kernel32_test path, I got this additional error (before all the > others) > > I have made tons of fixes to the kernel/path test and it should now work > much better. I just uploaded the new version of the tests compiled from > my sources. One can download them from the usual URL: > > http://fgouget.free.fr/wine/winetests.zip > > > [...] > > >process: 116 tests executed, 0 marked as todo, 4 failures. > > > > > Exactly the same except I have 10 messages interspersed with these, > saying: > > tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. > > Why these extra messages? > > Because this executable invokes itself to test CreateProcess. And each > time it exits it prints statistics about how many tests passed and > failed, although the child processes are not actually performing any > test. So these messages can be ignored. > > > > >h:\wine\wine\dlls\shlwapi\tests\shreg.c:218: Test failed: (6) > > >h:\wine\wine\dlls\shlwapi\tests\shreg.c:219: Test failed: (6,43) > > >h:\wine\wine\dlls\shlwapi\tests\shreg.c:220: Test failed: > (3435973836) > [...] > > Same but I get 0 for all your 3435973836 which is 0xcccccccc. Must be > a > > debug/release build thing - variable not being initialized. > > Should not be the case. The code does: > dwType = -1; > dwRet = SHQueryValueExA( hKey, "Test3", NULL, &dwType, NULL, > &dwSize); > ok( dwType == REG_SZ, "(%lu)" , dwType); > > So we should either get -1 or something that makes sense, not > 0xcccccccc. This needs to be investigated more. > > > > Should we print out some of these results in hex as well to make life > > easier? > > We should print them in just one format, decimal or hex, whichever makes > more sense. > > > > >I will now be concentrating on working out what is wrong with these > > >tests :) > > Yep, I think this is priority number one now. Running the tests on more > platforms would only return pretty much the same list of bugs again and > again. > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Any sufficiently advanced bug is indistinguishable from a feature. > -- from some indian guy > > > > > > > --__--__-- > > Message: 4 > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Reply-To: dpaun(a)rogers.com > Organization: DSSD Software Inc. > To: Waldek Hebisch <hebisch(a)math.uni.wroc.pl>, wine-devel(a)winehq.com > Subject: Re: strcasecmp > Date: Thu, 19 Dec 2002 11:48:23 -0500 > > On December 19, 2002 09:26 am, Waldek Hebisch wrote: > > If we are going to seriously support mingw then we need "mingw headers". > > I am not sure if true mingw headres are different enuugh from normal > > wine and msvcrt headers to warrant extra subdirectory, but logically > > they form a separate set. I suggest to put conditionls (if needed) in > > msvcrt headers corresponding to mingw headers, and make a separate > > subdirectory for mingw headers which emulate Unix headers. > > Right. I haven't looked at the mingw headers, but I assume they are > rather similar to the ones in glibc. If that's the case, we can > reuse those (if you have gcc which you have to anyway if you want to > use the mingwrap stuff): > > [dimi(a)dimi wine.src]$ sed -n 290,296p /usr/lib/gcc-lib/i386-redhat-linux/3.2/include/stddef.h > #ifndef __WCHAR_TYPE__ > #define __WCHAR_TYPE__ int > #endif > #ifndef __cplusplus > typedef __WCHAR_TYPE__ wchar_t; > #endif > #endif > > Which means we can simply -D__WCHAR_TYPE__=unsigned\ short > > But we still can not link. For that, we need to reimplement all wchar_t > using functions, and link those in before the glibc ones. Linking tricks > are not my strenght, anyone know how we can do that? Does it work to > just place a lib with those symbols first in the -l list? > > -- > Dimi. > > > --__--__-- > > Message: 5 > Date: Thu, 19 Dec 2002 10:36:14 -0700 > From: Tony Lambregts <tony_lambregts(a)telusplanet.net> > To: Joerg Mayer <jmayer(a)loplof.de> > CC: "Dimitrie O. Paun" <dpaun(a)rogers.com>, wine-devel(a)winehq.com > Subject: Re: Update to patches sgml > > Joerg Mayer wrote: > > >On Thu, Dec 19, 2002 at 01:10:52AM -0500, Dimitrie O. Paun wrote: > > > > > >>This should read "Patches should be inlined (if you can configure your email > >>client to not wrap lines), or attached as text/plain attachements...." > >> > >> > > > >Maybe you should include a step by step instruction for outlook users > >how to do that. It seems that outlook is the leading misattachment generator, > >so instead of just telling people what NOT to do, maybe you can tell > >people how to do it right. > > > > > > > Well I suppose I could if I had those instructions. However it seems out > of scope for a style section. AFAIK just giving the patch a .txt > extention and attaching will solve the problem for most mailers > including outlook. > > -- > > Tony Lambregts > > > > > > --__--__-- > > _______________________________________________ > wine-devel mailing list - wine-devel(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-devel > > > End of wine-devel Digest > >

Dec. 19, 2002

Re: HELP: DEVMODE def

by Dan Kegel

> On December 19, 2002 03:20 pm, Ove Kaaven wrote: >> union { >> struct { >> short dmOrientation; >> short dmPaperSize; >> short dmPaperLength; >> short dmPaperWidth; >> }; >> POINTL dmPosition; >> }; > > This is a problem, because it seems we don't have nameless structs > in g++, and I have no idea how to solve this. gcc3.2 has them. I just verified that a fragment like that compiles fine with g++3.2. Red Hat 8.0, Suse 8.1, and Mandrake 9.0 have already standardized on gcc3.2. Debian supports gcc3.2 only in their 'testing' distribution, but historically, a lot of people switch to 'testing' when they need new stuff. I have a feeling enough distributions have updated to gcc3.2 that it might be ok to start depending on it. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 19, 2002

Re: RECT def

by Dimitrie O. Paun

On December 19, 2002 02:35 pm, Dimitrie O. Paun wrote: > ChangeLog > MS uses LONG for the members of RECT. Of course, this causes a sh*tload of warnings. This may be a good time to convert most of these to the debugrect function that I used in listview.c. Sounds like a plan? -- Dimi.

Dec. 19, 2002

Re: HELP: DEVMODE def

by Ove Kaaven

On Thu, 19 Dec 2002, Dimitrie O. Paun wrote: > Thanks for the help guys, > > Here is another one: the DEVMODE structure. The full MSVC++ definition: typedef struct _devicemodeA { BYTE dmDeviceName[CCHDEVICENAME]; WORD dmSpecVersion; WORD dmDriverVersion; WORD dmSize; WORD dmDriverExtra; DWORD dmFields; union { struct { short dmOrientation; short dmPaperSize; short dmPaperLength; short dmPaperWidth; }; POINTL dmPosition; }; short dmScale; short dmCopies; short dmDefaultSource; short dmPrintQuality; short dmColor; short dmDuplex; short dmYResolution; short dmTTOption; short dmCollate; BYTE dmFormName[CCHFORMNAME]; WORD dmLogPixels; DWORD dmBitsPerPel; DWORD dmPelsWidth; DWORD dmPelsHeight; DWORD dmDisplayFlags; DWORD dmDisplayFrequency; #if(WINVER >= 0x0400) DWORD dmICMMethod; DWORD dmICMIntent; DWORD dmMediaType; DWORD dmDitherType; DWORD dmReserved1; DWORD dmReserved2; #if (WINVER >= 0x0500) || (_WIN32_WINNT >= 0x0400) DWORD dmPanningWidth; DWORD dmPanningHeight; #endif #endif /* WINVER >= 0x0400 */ } DEVMODEA, *PDEVMODEA, *NPDEVMODEA, *LPDEVMODEA;

Dec. 19, 2002

Re: Import or ntdll

by Alexandre Julliard

"Jeff Smith" <whydoubt(a)hotmail.com> writes: > Realized that ntdll was not needed in the IMPORTS list. I have tested > this in Linux and have not encountered any problems. It is needed. You don't see a problem on Linux because winebuild adds that import automatically in most cases, but it will break Reactos etc. -- Alexandre Julliard julliard(a)winehq.com

Dec. 19, 2002

Re: HELP: DEVMODE def

by Jeff Smith

At a glance, for wine's to conform with VC6's: 1.) "SHORT" -> "short" 2.) dmICMMethod and below only if WINVER >= 0x0400 3.) dmPanningWidth and below only if WINVER >= 0x0500 or _WIN32_WINN >= 0x0400 4.) Windows has no DUMMY*NAME*'s -- Jeff S >From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > >Thanks for the help guys, > >Here is another one: the DEVMODE structure. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

Dec. 19, 2002

Re: HELP: DEVMODE def

by Vincent Béron

Dimitrie O. Paun a écrit: > Thanks for the help guys, > > Here is another one: the DEVMODE structure. > short rather than SHORT. The union is present. I have dmReserved1 and 2 in mine, along with the last 2 fields. (SDK downloaded last week). Vincent

Dec. 19, 2002

Re: another wtypes addition

by Ove Kaaven

On Thu, 19 Dec 2002, Dimitrie O. Paun wrote: > On December 19, 2002 02:32 pm, Ove Kaaven wrote: > > This is the last of the definition shuffling I had to do before my > > (rewind) build tree compiled with a replaced objidl.h. > > So we should be able to get rid of the include/wine/obj_*.h soon? Eventually. My objidl.h replacement only lets you get rid of the files currently referenced by it (obj_misc.h, obj_channel.h, obj_clientserver.h, obj_storage.h, obj_marshal.h, obj_moniker.h, obj_propertystorage.h, obj_dataobject.h), and indirectly obj_base.h, but many such files still remain and several more IDL files need to be written to replace those, for example oaidl.idl must be written before we can remove obj_oleaut.h, oleidl.idl is needed to get rid of yet a few more, and so on. I've already written an oaidl.idl, but not oleidl.idl (or any other of the remaining 53 IDL files in my copy of MSVC++).

Dec. 19, 2002

Re: HELP: RECT definition

by Vincent Béron

Dimitrie O. Paun a écrit: > Can someone please check the MS headers for the RECT definition? > > In our definition, we use INT, while the MinGW people use LONG. > Which one is correct? > LONG Vincent

Dec. 19, 2002

HELP: DEVMODE def

by Dimitrie O. Paun

Thanks for the help guys, Here is another one: the DEVMODE structure. Ours: typedef struct { BYTE dmDeviceName[CCHDEVICENAME]; WORD dmSpecVersion; WORD dmDriverVersion; WORD dmSize; WORD dmDriverExtra; DWORD dmFields; union { struct { SHORT dmOrientation; SHORT dmPaperSize; SHORT dmPaperLength; SHORT dmPaperWidth; } DUMMYSTRUCTNAME1; POINTL dmPosition; } DUMMYUNIONNAME1; SHORT dmScale; SHORT dmCopies; SHORT dmDefaultSource; SHORT dmPrintQuality; SHORT dmColor; SHORT dmDuplex; SHORT dmYResolution; SHORT dmTTOption; SHORT dmCollate; BYTE dmFormName[CCHFORMNAME]; WORD dmLogPixels; DWORD dmBitsPerPel; DWORD dmPelsWidth; DWORD dmPelsHeight; DWORD dmDisplayFlags; DWORD dmDisplayFrequency; DWORD dmICMMethod; DWORD dmICMIntent; DWORD dmMediaType; DWORD dmDitherType; DWORD dmReserved1; DWORD dmReserved2; DWORD dmPanningWidth; DWORD dmPanningHeight; } DEVMODEA, *PDEVMODEA, *LPDEVMODEA; MinGW: typedef struct _devicemodeA { BYTE dmDeviceName[CCHDEVICENAME]; WORD dmSpecVersion; WORD dmDriverVersion; WORD dmSize; WORD dmDriverExtra; DWORD dmFields; short dmOrientation; short dmPaperSize; short dmPaperLength; short dmPaperWidth; short dmScale; short dmCopies; short dmDefaultSource; short dmPrintQuality; short dmColor; short dmDuplex; short dmYResolution; short dmTTOption; short dmCollate; BYTE dmFormName[CCHFORMNAME]; WORD dmLogPixels; DWORD dmBitsPerPel; DWORD dmPelsWidth; DWORD dmPelsHeight; DWORD dmDisplayFlags; DWORD dmDisplayFrequency; DWORD dmICMMethod; DWORD dmICMIntent; DWORD dmMediaType; DWORD dmDitherType; DWORD dmICCManufacturer; DWORD dmICCModel; } DEVMODEA,*LPDEVMODEA,*PDEVMODEA; -- Dimi.

Dec. 19, 2002

Re: Update to patches sgml

by Joerg Mayer

On Thu, Dec 19, 2002 at 12:47:51PM -0600, Jeff Smith wrote: > Leading spaces are getting dropped when I inline and even when I attach > as a TXT file. The only way it will let all my patches through > unharmed is by leaving the extension as DIFF. I have several patches > in my queue, but have been reluctant to send them out until I get this > resolved. I don't think that resolving the problems should be a requirement to actually sned patches. Send them out now and just write a short note about currently not being able to "properly" attach them. The attachment requirement is intended to increase the speed of development, not slow it down. ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Dec. 19, 2002

Re: another wtypes addition

by Dimitrie O. Paun

On December 19, 2002 02:32 pm, Ove Kaaven wrote: > This is the last of the definition shuffling I had to do before my > (rewind) build tree compiled with a replaced objidl.h. So we should be able to get rid of the include/wine/obj_*.h soon? -- Dimi.

Dec. 19, 2002

HELP: RECT definition

by Dimitrie O. Paun

Can someone please check the MS headers for the RECT definition? In our definition, we use INT, while the MinGW people use LONG. Which one is correct? Ours: typedef struct tagRECT { INT left; INT top; INT right; INT bottom; } RECT, *PRECT, *LPRECT; MinGW: typedef struct tagRECT { LONG left; LONG top; LONG right; LONG bottom; } RECT,*PRECT,*LPRECT; -- Dimi.

Dec. 19, 2002

Re: Update to patches sgml

by Joerg Mayer

On Thu, Dec 19, 2002 at 10:36:14AM -0700, Tony Lambregts wrote: > Joerg Mayer wrote: > >Maybe you should include a step by step instruction for outlook users > >how to do that. It seems that outlook is the leading misattachment generator, > >so instead of just telling people what NOT to do, maybe you can tell > >people how to do it right. > > Well I suppose I could if I had those instructions. I jsut dug out the following mail: ---------------- Message-ID: <01f801c27fc4$3060c100$c4823bd5(a)dmitry> From: "Dmitry Timoshkov" <dmitry(a)baikal.ru> To: "Patrik Stridvall" <ps(a)leissner.se> Cc: <wine-devel(a)winehq.com> References: <9B72374533931944B8501EFE41A391E5A50CE2(a)knasen.leissner.se> Subject: Re: winapi update X-Spam-Level: "Patrik Stridvall" <ps(a)leissner.se> wrote: > > On October 29, 2002 11:27 am, Patrik Stridvall wrote: > > > Anyway, I can't inline my patches the because Microsoft > > Outlook wraps > > > the lines and I sure a lot of other people that use attachments have > > > similar problems. > > > > And can't be turned off?!? Hmmm, anyway, just attach them as > > text/plain. > > I have no idea how or if it is possible to do either. This is a part of my mail sent to Guy in order to help him to send patches using Outlook Express. I hope that it will be helpful for Outlook users too. <QUOTE> Since I was using OE to send patches, I have found a way to send diffs as attachments and without \n vs. \r\n problem. You need following two things to make it work. 1. Make sure that .diff files have \r\n line ends, because if OE detects that there is no \r\n line endings it switches to quoted-printable format attachments. 2. Using regedit add key "Content Type" with value "text/plain" to the .diff extension under HKEY_CLASSES_ROOT (same as for .txt extension). This tells OE to use Content-Type: text/plain instead of application/octet-stream. </QUOTE> Item #1 is important. After you hit "Send" button, go to "Outbox" and using "Properties" verify the message source to make sure that the mail has correct format. You might want to send several test e-mails to yourself too. -- Dmitry. ---------------- > However it seems out of scope for a style section. You are right, but only in theory. The reality is, that people easily do the "wrong" thing while trying to do the "right" thing. And that's not because they didsomething stupid, but because but because M$ products tend to know better what the users needs to do thatn the user himself :-/ > AFAIK just giving the patch a .txt > extention and attaching will solve the problem for most mailers > including outlook. Then this should be tested by people who have access to O and OE and added afterwards. Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Dec. 19, 2002

Re: Wine 0.9 TODO v0.7

by Steven Edwards

We still need to double check the latest import lib and winebuild changes on Mingw32. I am going to be swamped for the next week or two. --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > Hi folks, > > The next version of the 0.9 TODO is way past due, so I've > decided to release it today: > http://www.dssd.ca/wine/Wine-0.9-TODO-0.7.html > > ChangeLog > * Bill finished moving CVS docu from User Guide to Devel Guide (B3) > * Alexandre implemented import libraries (D3), finished winebuild (D4) > * I fixed header location (mostly done by Alexandre :)) (E9) > * Status update from Jaco (C2), and Ender (E7) > * Brand new Introduction > * New tasks added (D5, D6, D7) > > Check it out, it's fun! :) > > -- > Dimi. > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Dec. 19, 2002

Re: Update to patches sgml (one more time)

by Tony Lambregts

Dimitrie O. Paun wrote: >On December 19, 2002 01:56 am, Tony Lambregts wrote: > > >>Not a bad idea. how's this then. >> >> > >Better. Did you look at this: > http://www.winehq.com/hypermail/wine-devel/2002/09/0127.html > >The rules detailed in there are still valid: > -- unified diff only (required) > -- have a decent subject (recommended) > -- a long description (optional, if the change warrants it) > -- a meaningful ChangeLog entry (required) > -- new files, if any, included in patch, diffed against /dev/null (required) > -- patch inlined at the end of the message (recommended) > -- one changeset per message > Most of this is covered in the Patch format section and are in point form so I added most of what was missing there. > >What about including them in point-form for clarity, with some rationale >(as you did) for things like patch inlining, etc. Idea being that one >shouldn't have read the entire story if he/she only wants to see the rules. > >The story is good for first timers that want to understand why we have these >rules/recommendations, so we can easily point them to them instead of having >to answer it in long email every time... :) > > > The whole thing isn't much more that a couple hundred words and in point form. I think most developrers are capable of getting the idea without having to go back to it each time they send a patch <g> Change Log: update patches.sgml to include more information on style and format of patches Files: documentation/patches.sgml -- Tony Lambregts Index: patches.sgml =================================================================== RCS file: /home/wine/wine/documentation/patches.sgml,v retrieving revision 1.4 diff -u -r1.4 patches.sgml --- patches.sgml 17 Sep 2002 00:07:03 -0000 1.4 +++ patches.sgml 19 Dec 2002 18:36:29 -0000 @@ -14,18 +14,28 @@ <itemizedlist> <listitem> <para> - a description of what was wrong and what is now better - (and now broken :). + A meaningfull subject (very short description of patch) + </para> + </listitem> + <listitem> + <para> + A long (paragraph) description of what was wrong and what is now + better (and now broken :). (recomended) + </para> + </listitem> + <listitem> + <para> + Change Log: A short description of what was changed. </para> </listitem> <listitem> <para> - your contact information ( Name/Handle and e-mail ) + Your contact information ( Name/Handle and e-mail ) </para> </listitem> <listitem> <para> - the patch in <command>diff -u</command> format (it happens...) + The patch in <command>diff -u</command> format (it happens...) </para> </listitem> </itemizedlist> @@ -47,6 +57,82 @@ <para> For removals, list the files. </para> + <para> + Since wine is constantly changing due to development it is strongly + recomended that you use cvs for patches, if you cannot use cvs for + some reason, you can submit patches against the latest tarball. + To do this make a copy of the files that you will be modifying and + <command>diff -u</command> against the old file. I.E. + </para> + <screen> +diff -u file.old file.c > file.txt + </screen> + </sect1> + + <sect1 id="Style-notes"> + <title>Some notes about style</title> + + <para> + There are a few conventions that about coding style that have been + adopted over the years of development. The rational for these + <quote>rules</quote> is explained for each one. + </para> + <itemizedlist> + <listitem> + <para> + Only one change set per patch. Patches should address only one + bug/problem at a time. If a lot of changes need to be made then it + is perfered to break it into a series of patches. This makes it + easier to find regressions. + </para> + </listitem> + <listitem> + <para> + Tabs are not forbidden but are defined as 8 charaters and the usual + amount of indentation is 4 characters. + </para> + </listitem> + <listitem> + <para> + C++ style comments are discouraged since some compilers choke on + them. + </para> + </listitem> + <listitem> + <para> + Commenting out a block of code is usually done by enclosing it in + <command>#if 0 ... #endif</command> Statements. For example. + </para> + <screen> +/* note about reason for commenting block */ +#if 0 +code +code /* comments */ +code +#endif + </screen> + <para> + The reason for using this method is that it does not require that + you edit comments that may be inside the block of code. + </para> + </listitem> + <listitem> + <para> + Patches should be inlined (if you can configure your email client to + not wrap lines), or attached as plain text attachements so they can + be read inline. This may mean some more work for you. However it + allows others to review your patch easily and decreases the chances + of it being overlooked or forgotten. + </para> + </listitem> + <listitem> + <para> + Code is usually limited to 80 columns. This helps prevent mailers + mangling patches by line wrap. Also it generally makes code easier + to read. + </para> + </listitem> + </itemizedlist> </sect1> <sect1 id="patch-quality">

Dec. 19, 2002

Re: Update to patches sgml

by Jeff Smith

Hotmail better get their act together or I will have to go elsewhere. Leading spaces are getting dropped when I inline and even when I attach as a TXT file. The only way it will let all my patches through unharmed is by leaving the extension as DIFF. I have several patches in my queue, but have been reluctant to send them out until I get this resolved. -- Jeff S >From: Tony Lambregts <tony_lambregts(a)telusplanet.net> > >Joerg Mayer wrote: > >>On Thu, Dec 19, 2002 at 01:10:52AM -0500, Dimitrie O. Paun wrote: >> >> >>>This should read "Patches should be inlined (if you can configure your >>>email >>>client to not wrap lines), or attached as text/plain attachements...." >>> >>> >> >>Maybe you should include a step by step instruction for outlook users >>how to do that. It seems that outlook is the leading misattachment >>generator, >>so instead of just telling people what NOT to do, maybe you can tell >>people how to do it right. >> >> >> >Well I suppose I could if I had those instructions. However it seems out of >scope for a style section. AFAIK just giving the patch a .txt extention and >attaching will solve the problem for most mailers including outlook. > >-- > >Tony Lambregts _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

Dec. 19, 2002

Re: Wineconsole 'regression'

by Eric Pouech

> I looked at the wineconsole code and it does not seem that there is a > configure option or any other mean to have wineconsole act as before (ie to > use the slow but working USER driver). that's a feature (see previous discussion on wineconsole implementation) we could add an option for that, but it's better to fix actually the curses implementation *first* does this attached patch solves some issues ? (it won't solve all of the issues for ida) A+ -- Eric Pouech Index: curses.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/programs/wineconsole/curses.c,v retrieving revision 1.1 diff -u -r1.1 curses.c --- curses.c 13 Dec 2002 23:37:06 -0000 1.1 +++ curses.c 19 Dec 2002 18:29:25 -0000 @@ -136,22 +136,28 @@ { int x, y; CHAR_INFO* cell; - WORD color; + DWORD attr; for (y = tp; y <= bm; y++) { cell = &data->cells[y * data->curcfg.sb_width]; for (x = 0; x < data->curcfg.sb_width; x++) { - color = 0; - if (cell[x].Attributes & FOREGROUND_RED) color |= COLOR_RED; - if (cell[x].Attributes & FOREGROUND_BLUE) color |= COLOR_BLUE; - if (cell[x].Attributes & FOREGROUND_GREEN) color |= COLOR_GREEN; - if (cell[x].Attributes & BACKGROUND_RED) color |= COLOR_RED << 3; - if (cell[x].Attributes & BACKGROUND_BLUE) color |= COLOR_BLUE << 3; - if (cell[x].Attributes & BACKGROUND_GREEN) color |= COLOR_GREEN << 3; + if (cell[x].Char.UnicodeChar >= 0x20 && cell[x].Char.UnicodeChar <= 0xFF) + attr = LOBYTE(cell[x].Char.UnicodeChar); + else + attr = ' '; + + if (cell[x].Attributes & FOREGROUND_RED) attr |= COLOR_PAIR(COLOR_RED); + if (cell[x].Attributes & FOREGROUND_BLUE) attr |= COLOR_PAIR(COLOR_BLUE); + if (cell[x].Attributes & FOREGROUND_GREEN) attr |= COLOR_PAIR(COLOR_GREEN); + if (cell[x].Attributes & BACKGROUND_RED) attr |= COLOR_PAIR(COLOR_RED << 3); + if (cell[x].Attributes & BACKGROUND_BLUE) attr |= COLOR_PAIR(COLOR_BLUE << 3); + if (cell[x].Attributes & BACKGROUND_GREEN) attr |= COLOR_PAIR(COLOR_GREEN << 3); - PRIVATE(data)->line[x] = (unsigned char)cell[x].Char.UnicodeChar | COLOR_PAIR(color); + if (cell[x].Attributes & FOREGROUND_INTENSITY) attr |= A_BOLD; + + PRIVATE(data)->line[x] = attr; } mvwaddchnstr(PRIVATE(data)->pad, y, 0, PRIVATE(data)->line, data->curcfg.sb_width); } @@ -282,10 +288,9 @@ static COORD pos /* = {0, 0} */; MEVENT mevt; - BOOL ret = 0; if (getmouse(&mevt) == ERR) - return FALSE; + return FALSE; WINE_TRACE("[%u]: (%d, %d) %08lx\n", mevt.id, mevt.x, mevt.y, (unsigned long)mevt.bstate); @@ -296,7 +301,6 @@ #define BTN3_BIT FROM_LEFT_2ND_BUTTON_PRESSED #define BTN4_BIT 0 /* not done yet */ - /* FIXME: to be checked */ if (mevt.bstate & BUTTON1_PRESSED) bstate |= BTN1_BIT; if (mevt.bstate & BUTTON1_RELEASED) bstate &= ~BTN1_BIT; if (mevt.bstate & BUTTON2_PRESSED) bstate |= BTN2_BIT; @@ -304,28 +308,12 @@ if (mevt.bstate & BUTTON3_PRESSED) bstate |= BTN3_BIT; if (mevt.bstate & BUTTON3_RELEASED) bstate &= ~BTN3_BIT; - /* for the clicked & double click events, since we'll generate automatically - * the release event, we don't have to store the state - */ - if ((mevt.bstate & (BUTTON1_CLICKED|BUTTON1_DOUBLE_CLICKED)) && !(bstate & BTN1_BIT)) - { - ret = BTN1_BIT; - } - if ((mevt.bstate & (BUTTON2_CLICKED|BUTTON2_DOUBLE_CLICKED)) && !(bstate & BTN2_BIT)) - { - ret = BTN2_BIT; - } - if ((mevt.bstate & (BUTTON3_CLICKED|BUTTON3_DOUBLE_CLICKED)) && !(bstate & BTN3_BIT)) - { - ret = BTN3_BIT; - } - ir->EventType = MOUSE_EVENT; ir->Event.MouseEvent.dwMousePosition.X = mevt.x; ir->Event.MouseEvent.dwMousePosition.Y = mevt.y; - ir->Event.MouseEvent.dwButtonState = (bstate | ret); - + ir->Event.MouseEvent.dwButtonState = bstate; + /* partial conversion */ ir->Event.MouseEvent.dwControlKeyState = 0; if (mevt.bstate & BUTTON_SHIFT) ir->Event.MouseEvent.dwControlKeyState |= SHIFT_PRESSED; @@ -338,19 +326,23 @@ */ ir->Event.MouseEvent.dwEventFlags = 0; +#if 0 + /* won't work, we need to still generate the first click event */ if ((mevt.bstate & BUTTON1_DOUBLE_CLICKED) && ((bstate|ret) & BTN1_BIT)) ir->Event.MouseEvent.dwEventFlags |= DOUBLE_CLICK; if ((mevt.bstate & BUTTON2_DOUBLE_CLICKED) && ((bstate|ret) & BTN2_BIT)) ir->Event.MouseEvent.dwEventFlags |= DOUBLE_CLICK; if ((mevt.bstate & BUTTON3_DOUBLE_CLICKED) && ((bstate|ret) & BTN3_BIT)) ir->Event.MouseEvent.dwEventFlags |= DOUBLE_CLICK; - if (mevt.x != pos.X || mevt.y != pos.Y) +#endif + if (!(mevt.bstate & (BUTTON1_PRESSED|BUTTON1_RELEASED|BUTTON2_PRESSED|BUTTON2_RELEASED|BUTTON3_PRESSED|BUTTON3_RELEASED)) && + (mevt.x != pos.X || mevt.y != pos.Y)) { ir->Event.MouseEvent.dwEventFlags |= MOUSE_MOVED; } pos.X = mevt.x; pos.Y = mevt.y; - - return ret; + + return FALSE; } /****************************************************************** @@ -659,7 +651,8 @@ nodelay(stdscr, TRUE); keypad(stdscr, TRUE); mousemask(0xffffffff, &PRIVATE(data)->initial_mouse_mask); - + /* no click generation... (--hmmm man page says -1 to disable) */ + mouseinterval(0); return TRUE; }

Dec. 19, 2002

Wine 0.9 TODO v0.7

by Dimitrie O. Paun

Hi folks, The next version of the 0.9 TODO is way past due, so I've decided to release it today: http://www.dssd.ca/wine/Wine-0.9-TODO-0.7.html ChangeLog * Bill finished moving CVS docu from User Guide to Devel Guide (B3) * Alexandre implemented import libraries (D3), finished winebuild (D4) * I fixed header location (mostly done by Alexandre :)) (E9) * Status update from Jaco (C2), and Ender (E7) * Brand new Introduction * New tasks added (D5, D6, D7) Check it out, it's fun! :) -- Dimi.

Dec. 19, 2002

Re: Update to patches sgml

by Tony Lambregts

Joerg Mayer wrote: >On Thu, Dec 19, 2002 at 01:10:52AM -0500, Dimitrie O. Paun wrote: > > >>This should read "Patches should be inlined (if you can configure your email >>client to not wrap lines), or attached as text/plain attachements...." >> >> > >Maybe you should include a step by step instruction for outlook users >how to do that. It seems that outlook is the leading misattachment generator, >so instead of just telling people what NOT to do, maybe you can tell >people how to do it right. > > > Well I suppose I could if I had those instructions. However it seems out of scope for a style section. AFAIK just giving the patch a .txt extention and attaching will solve the problem for most mailers including outlook. -- Tony Lambregts

Dec. 19, 2002

Re: strcasecmp

by Dimitrie O. Paun

On December 19, 2002 09:26 am, Waldek Hebisch wrote: > If we are going to seriously support mingw then we need "mingw headers". > I am not sure if true mingw headres are different enuugh from normal > wine and msvcrt headers to warrant extra subdirectory, but logically > they form a separate set. I suggest to put conditionls (if needed) in > msvcrt headers corresponding to mingw headers, and make a separate > subdirectory for mingw headers which emulate Unix headers. Right. I haven't looked at the mingw headers, but I assume they are rather similar to the ones in glibc. If that's the case, we can reuse those (if you have gcc which you have to anyway if you want to use the mingwrap stuff): [dimi(a)dimi wine.src]$ sed -n 290,296p /usr/lib/gcc-lib/i386-redhat-linux/3.2/include/stddef.h #ifndef __WCHAR_TYPE__ #define __WCHAR_TYPE__ int #endif #ifndef __cplusplus typedef __WCHAR_TYPE__ wchar_t; #endif #endif Which means we can simply -D__WCHAR_TYPE__=unsigned\ short But we still can not link. For that, we need to reimplement all wchar_t using functions, and link those in before the glibc ones. Linking tricks are not my strenght, anyone know how we can do that? Does it work to just place a lib with those symbols first in the -l list? -- Dimi.

Dec. 19, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Zsolt Rizsanyi

On Thursday 19 December 2002 14:27, Fabian Cenedese wrote: > Considering the age of these two it's maybe understandable why they > don't have this feature. Tell me an editor in Windows and I may switch. There is windows version of Vim. Try that :)

Dec. 19, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by David Laight

On Thu, Dec 19, 2002 at 07:08:40AM -0500, Dimitrie O. Paun wrote: > On December 19, 2002 05:29 am, David Laight wrote: > > No, and I would use it if I did :-) ^^^ not Finger trouble... > http://www.vim.org Probably... David -- David Laight: david(a)l8s.co.uk

Dec. 19, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Zsolt Rizsanyi

On Thursday 19 December 2002 10:14, Fabian Cenedese wrote: > > > >/* note about reason for commenting block */ > > > >#if 0 > > > >code > > > >code /* comments */ > > > >code > > > >#endif > > > > > > Whereas this is the solution with the least work it's also hard to > > > > spot. If > > > > > using > > > a text editor with syntax coloring it all looks the same. But if a code > > > > isn't > > > > > effective I'd like to see that. > > > >Actually it could be considered as an editor fault if it changes color for > >commented out code but doesn't recognize the #if 0/#endif construct. > > I wouldn't say so. A comment is easily recognized by the chars /* */ or //. > But to get a #if 0 or #if _ANYTHING you really need a language dependant > preprocessor which goes beyond a normal text editor, even one with > syntax coloring. > Do you have such a text editor that finds #if's? Yes :) Vim parses #if 0. So #if 0 ... #endif is colored like a comment. Of course that does not mean that all #if -s will be parsed, but IMO only #if 0 should be colored like a comment since other #if -s are not comments. Eg. if you have something like #if defined(__linux__) ... #elif defined(__bsd__) ... #endif You dont want to comment any out any part of the code since all code will be compiled on some OS. Regards Zsolt

Dec. 19, 2002

Re: strcasecmp

by Waldek Hebisch

> On December 18, 2002 05:06 pm, Francois Gouget wrote: > > There is the same issue gethostname(). Visual C++ does not define it in > > the msvcrt headers so how does one compile wxWindows with visual C++? > > Because these are apps that compile under MinGW using their headers for > libc, not the crtdll/msvcrt ones. > > In theory, we should compile such apps using the native libc headers, > but that does not work. And it does not work because of -fwchar-short, > which is a must... > > So we are in a bit of a bind: we _have_ to use msvcrt, but the app > expects functions that are present only in the Unix/MinGW headers. > What do we do? > > -- > Dimi. If we are going to seriously support mingw then we need "mingw headers". I am not sure if true mingw headres are different enuugh from normal wine and msvcrt headers to warrant extra subdirectory, but logically they form a separate set. I suggest to put conditionls (if needed) in msvcrt headers corresponding to mingw headers, and make a separate subdirectory for mingw headers which emulate Unix headers. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

Dec. 19, 2002

Re: How long does it take *you* to build wine?

by P. Christeas

Build (after a cvs update, make depend) on an Athlon XP 1800 w 256 Mb DDR: 1038.43user 72.66system 19:41.06elapsed 94%CPU That is 18.5 min. (the process was 'niced', so elapsed is more..)

Dec. 19, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Fabian Cenedese

>Yes, the version of vim that came with (I believe) Red Hat 6.0 >has the definitions in its syntax file for proper "#if 0" >highlighting. As common a practice as this has become, any >syntax-highlighting editor with some degree of maturity that >did *not* have this in its default rulesets for C/C++ would >surprise me. > >What language-independent, syntax-highlighting text editor are >you using? > >-- Jeff S >> >>I wouldn't say so. A comment is easily recognized by the chars /* */ or //. >>But to get a #if 0 or #if _ANYTHING you really need a language dependant >>preprocessor which goes beyond a normal text editor, even one with >>syntax coloring. >>Do you have such a text editor that finds #if's? There goes the editor war again :) As Windows developer I'm mostly using MSVC, still version 6, About says it's from 98. I don't know about .net studio if this supports #if 0. For our own product we use an open-source editor for Windows called CodeMax. An expanded version is here http://www.ticz.com/homes/users/nlewis/index.html?target=download Considering the age of these two it's maybe understandable why they don't have this feature. Tell me an editor in Windows and I may switch. As said before they don't color all files the same, they get the language from the file extension and I guess vim does the same. Recognizing the #if 0 is the only difference (well, at least concerning coloring :) On Linux I used Kate so far. Hmm, Kate also supports #if 0, never noticed that... bye Fabi A: No, see http://www.netmeister.org/news/learn2quote.html Q: Should I include quotations after my reply ?

Dec. 19, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Jeff Smith

Yes, the version of vim that came with (I believe) Red Hat 6.0 has the definitions in its syntax file for proper "#if 0" highlighting. As common a practice as this has become, any syntax-highlighting editor with some degree of maturity that did *not* have this in its default rulesets for C/C++ would surprise me. What language-independent, syntax-highlighting text editor are you using? -- Jeff S >From: Fabian Cenedese <Cenedese(a)indel.ch> > >> > >/* note about reason for commenting block */ >> > >#if 0 >> > >code >> > >code /* comments */ >> > >code >> > >#endif >> > >> > Whereas this is the solution with the least work it's also hard to >>spot. If >> > using >> > a text editor with syntax coloring it all looks the same. But if a code >>isn't >> > effective I'd like to see that. >> >>Actually it could be considered as an editor fault if it changes color for >>commented out code but doesn't recognize the #if 0/#endif construct. > >I wouldn't say so. A comment is easily recognized by the chars /* */ or //. >But to get a #if 0 or #if _ANYTHING you really need a language dependant >preprocessor which goes beyond a normal text editor, even one with >syntax coloring. >Do you have such a text editor that finds #if's? > >bye Fabi _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

Dec. 19, 2002

Re: critical section timeout for the dsound_test

by Sylvain Petreolle

I posted a thread on nvidia forum. --- Enrico Horn <EnricoHorn(a)t-online.de> a écrit : > Hi, > On Wednesday 18 December 2002 12:23, Sylvain Petreolle wrote: > > I have same issue, but the debugger manages to start and "ends" in > the > > X video binary. > > > no debugger for me, just the message. > > > Could be a stupid question, but what is your VIDEO driver ? > > Mine is nVidia binary, and I have got some problems with it. > > I have reproductible crashes with it (like this test) for a long > time. > > Don't worry, I know this is a dsound test... :) > > > yes i use the nvidia binary driver too, mine is version 1.0-3123 > Which one do you use? > Did you try to use the included nv driver? > I get some crashes in libGL esp. when closing an app. > I have always ignored those since they seemed nvidia's fault to me. > > Ciao > Farmboy > farmboy1(a)subdimension.com > > > > ===== > > Sylvain Petreolle > > spetreolle(a)users.sourceforge.net > > Fight against Spam ! http://www.euro.cauce.org/en/index.html > > ICQ #170597259 > > > > "Don't think you are. Know you are." Morpheus in Matrix, chapter > 15. > > > > ___________________________________________________________ > > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > > Yahoo! Mail : http://fr.mail.yahoo.com > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Dec. 19, 2002

Re: Update to patches sgml

by Dimitrie O. Paun

On December 19, 2002 01:56 am, Tony Lambregts wrote: > Not a bad idea. how's this then. Better. Did you look at this: http://www.winehq.com/hypermail/wine-devel/2002/09/0127.html The rules detailed in there are still valid: -- unified diff only (required) -- have a decent subject (recommended) -- a long description (optional, if the change warrants it) -- a meaningful ChangeLog entry (required) -- new files, if any, included in patch, diffed against /dev/null (required) -- patch inlined at the end of the message (recommended) -- one changeset per message What about including them in point-form for clarity, with some rationale (as you did) for things like patch inlining, etc. Idea being that one shouldn't have read the entire story if he/she only wants to see the rules. The story is good for first timers that want to understand why we have these rules/recommendations, so we can easily point them to them instead of having to answer it in long email every time... :) -- Dimi.

Dec. 19, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Dimitrie O. Paun

On December 19, 2002 05:29 am, David Laight wrote: > No, and I would use it if I did :-) http://www.vim.org -- Dimi.

Dec. 19, 2002

Re: Update to patches sgml

by Joerg Mayer

On Thu, Dec 19, 2002 at 01:10:52AM -0500, Dimitrie O. Paun wrote: > This should read "Patches should be inlined (if you can configure your email > client to not wrap lines), or attached as text/plain attachements...." Maybe you should include a step by step instruction for outlook users how to do that. It seems that outlook is the leading misattachment generator, so instead of just telling people what NOT to do, maybe you can tell people how to do it right. Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Dec. 19, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by David Laight

> >Actually it could be considered as an editor fault if it changes color for > >commented out code but doesn't recognize the #if 0/#endif construct. I'd tend to agree... OTOH I don't like colour :-) > I wouldn't say so. A comment is easily recognized by the chars /* */ or //. No it isn't! You still have to know the language in order to get quoting right. Try editing an m4 source file! > But to get a #if 0 or #if _ANYTHING you really need a language dependant > preprocessor which goes beyond a normal text editor, even one with > syntax coloring. The only difficulty is knowing which half of the #if ... #else ... #endif to parse. Parsing both is wrong and will lead to miscoloration. > Do you have such a text editor that finds #if's? No, and I would use it if I did :-) David -- David Laight: david(a)l8s.co.uk

Dec. 19, 2002