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

Wine Contrib v0.4
by Dimitrie O. Paun Dec. 24, 2002

Dec. 24, 2002

Hi folks, Tom Wickline took over the Wine Contrib page, and cleaned it up. He already went through 4 iterations, and asked me to post it on my site for your reviewing pleasure: http://www.dssd.ca/wine/Wine-Contrib-0.4.html Please take a look at it, and let us know what you think. The idea is to get it over with as soon as possible so that work on other pages can commence. -- Dimi.

1 0

winebuild -N generalization (take 2)
by Dimitrie O. Paun Dec. 24, 2002

Dec. 24, 2002

Of course, 99.99% percent of my previous message on this subject was just a bunch of crap, sorry to waste bandwidth, and kill neurons. I just want to note the DLLFileName has a very well defined semantics that should not get changed as I initially suggested. Mea culpa. What about this hack instead? Alexandre, if this is acceptable, I can update the man page and submit a patch. Motivation for having an option to force the DLLFileName is as before. Index: tools/winebuild/main.c =================================================================== RCS file: /var/cvs/wine/tools/winebuild/main.c,v retrieving revision 1.43 diff -u -r1.43 main.c --- tools/winebuild/main.c 12 Dec 2002 04:06:28 -0000 1.43 +++ tools/winebuild/main.c 23 Dec 2002 23:53:26 -0000 @@ -263,6 +263,7 @@ { strncpy( DLLName, arg, sizeof(DLLName) ); DLLName[sizeof(DLLName) - 1] = 0; + set_dll_file_name( arg ); } static void do_entry( const char *arg ) -- Dimi.

2 3

Re: wine/. configure.ac configure
by Michael Stefaniuc Dec. 24, 2002

Dec. 24, 2002

Hello, i don't think this patch is too correct. I get in the Makefiles following: INSTALL = $(TOPSRCDIR)//usr/bin/install -c $(INSTALL_FLAGS) and that obviously dosn't exist thus make install is failing. bye michael On Mon, Dec 23, 2002 at 06:35:19PM -0600, Alexandre Julliard wrote: > ChangeSet ID: 6794 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/12/23 18:35:19 > > Modified files: > . : configure.ac configure > > Log message: > Make sure INSTALL path is relative to the top dir when using the > script in tools/. > > Patch: http://cvs.winehq.com/patch.py?id=6794 > > Old revision New revision Changes Path > 1.112 1.113 +6 -1 wine/configure.ac > 1.380 1.381 +1993 -652 wine/configure -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Re: winebuild -N generalization
by Dimitrie O. Paun Dec. 23, 2002

Dec. 23, 2002

On December 23, 2002 03:10 pm, Dimitrie O. Paun wrote: > ChangeLog > Support the -N option in all modes. <blush>This doesn't work.</blush> -- Dimi.

1 0

Re: Winelib Apps v0.2
by Jeff Smith Dec. 23, 2002

Dec. 23, 2002

Dimi, Alexandre has implemented import libraries. Your page does not yet reflect this fact. -- Jeff S >From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > >Hi, > >It's been almost a month since the last release of the >Winelib page, and a _lot_ has changes since then: > http://www.dssd.ca/wine/Winelib-Apps-0.2.html > >The page has been reorganized, enhanced, etc. Too many >changes to list here. If you haven't followed the working >version, it's a good time to check it out. > >-- >Dimi. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail&xAPID=42&PS=47575&PI=7324&… http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_addphotos_…

2 1

making an so wrapper for a windows dll
by Patrick Michael Kane Dec. 23, 2002

Dec. 23, 2002

Hi: I have some business logic that is wrapped up inside of a 32-bit Windows DLL. Unfortunately, the source code to this DLL is not available and it is unlikely to be ported to Linux anytime soon. The good news is that the DLL is just a bunch of business logic. It doesn't try to access hardware directly, rely on 9000 other DLLs, etc. My goal here is to end up with a Linux shared library that wraps the DLL, so that I can then create wrappers to call the business logic from Perl and/or Python. winemaker seems to want to build an application, not a library. mplayer/aviplayer seem to do this sort of thing, but there's no documentation and it's all fairly obscure to a newcomer. Is there a quick and easy way to accomplish this? If not, is there a Wine developer who might be interested in a small consulting project to solve this problem? Best, -- Patrick Michael Kane <modus(a)pr.es.to>

1 0

Re: wineboot - Andy's version
by Andreas Mohr Dec. 23, 2002

Dec. 23, 2002

On Tue, Dec 17, 2002 at 09:17:48PM +0200, Shachar Shemesh wrote: > Changelog: > Andreas Mohr > > programs/wineboot > > * Initial implementation This is exactly my implementation AFAICS. I could easily have submitted it on my own, thank you very much. Instead, I thought that somebody should refine some parts before submitting. Also, GUI.txt was meant to be an internal note only. Hmm, well, maybe it's indeed best to have it committed now and then get some improvements real soon. (like e.g. to have it integrated into startup) Andreas Mohr

1 0

Winelib Apps v0.2
by Dimitrie O. Paun Dec. 23, 2002

Dec. 23, 2002

Hi, It's been almost a month since the last release of the Winelib page, and a _lot_ has changes since then: http://www.dssd.ca/wine/Winelib-Apps-0.2.html The page has been reorganized, enhanced, etc. Too many changes to list here. If you haven't followed the working version, it's a good time to check it out. -- Dimi.

1 0

DDE command 'ActivateProgMan'?
by Dan Kegel Dec. 23, 2002

Dec. 23, 2002

With current CVS wine, doing a minimum install of MSVC4 works fine (once you jump through the proper hoops), but at the very end, I get the dialog box Setup cannot execute the DDE command 'ActivateProgMan' Press Abort to to (sic) stop installing shortcuts and continue Setup. I googled for ActivateProgMan, but found nothing... For the moment, I'm just going to say "Press Abort" in my recipe for running msvc4 under Wine. I'd be willing to track this down further if someone feels like pointing me in the right direction. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

2 1

msvc4 success!
by Dan Kegel Dec. 23, 2002

Dec. 23, 2002

wine still needs some polish before it can install msvc4 nicely, but it can indeed install it, and the installed copy of msdev appears to work! I used the IDE to create a "hello, world" console app, and it compiled and ran perfectly! The UI seems snappy enough on my dual pentium 650, too. I'm sure I'll find many problems with this later, but for now, I think it's awesome that Wine can install and run msvc4 at all! - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

1 0

MSVC4, "install" button. Possible wine bug.
by Dan Kegel Dec. 23, 2002

Dec. 23, 2002

Big progress. Turns out the best way to trace these installer splash screens is wine --debugmsg +exec since all they do is exec other programs. The only problem with this button under Wine is that the current working directory MUST be /mnt/cdrom before starting setup.exe for the "install" button to work, else it doesn't find the subdirectory's setup.exe to launch. This is not true under Windows. This seems like an important little difference to track down. I guess something in Windows might implicitly change the working directory of a newly launched program, or...? I suppose I could write a little win32 program to mimic what setup.exe is doing, and see if it behaves differently on Windows and on Wine. I feel a regression test coming on... I might not have time to get to this for a bit, so I'm posting the output of wine --debugmsg +exec,+dosfs,+file d:setup.exe (click on "Install Visual C++" button) to http://kegel.com/msvc4/install.txt.gz in case someone else wants to look. Search for ShellExecute to find the interesting bits. The current directory is my Wine directory... disappointing the program, which expected it to be the root of the cd-rom. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

1 0

Re: Serious problem with / and mount points
by Jeff Smith Dec. 23, 2002

Dec. 23, 2002

What I have so far: in files/dos_fs.c:1343, drive is receiving the value -1. at line 1358, this is blindly added to 'A'. As you may know, in ASCII, 'A' - 1 = '@'. The next step is to determine why DRIVE_FindDriveRoot is returning -1. BTW, the same occurred in the reverse situation: (konsole) mount /mnt/cdrom (konsole) wcmd (wcmd) D: (wcmd) dir (konsole) umount /mnt/cdrom (wcmd) dir Now I am at @> If I remount and dir again, I am back to D> >From: Sylvain Petreolle <spetreolle(a)yahoo.fr> > >Trying to read a dvd rom that wasn't mounted, > >I did "dir" in wcmd. The label of the disc was displayed and "file not >found". >C>d: >D>dir >Volume in drive D is SPY_KIDS >Volume Serial Number is 1234-5678 > >File not found > > 0 bytes free >D> > >I then mounted the dvd and typed "dir" again. >D>dir >Volume in drive D is SPY_KIDS >Volume Serial Number is 1234-5678 > >Directory of D:\ > >01/01/1970 01:00:00 <DIR> a_imprim >01/01/1970 01:00:00 <DIR> audio_ts >... > 2 files 7,904 bytes > 7 directories 0 bytes free > >@> > >It appears that the '@' letter is normally inexistant and points to the >root of the system, '/' directory (my dvd is mounted under /mnt/dvd). > >@>cd >@:\mnt\dvd >@> > >When trying to do "cd ..", the command silently fails and does nothing. > >Comments ? _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus

3 3

A crash destroying imagelists
by Duane Clark Dec. 23, 2002

Dec. 23, 2002

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

2 3

[RFH] _FORCENAMELESSUNION
by Dimitrie O. Paun Dec. 23, 2002

Dec. 23, 2002

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.

3 6

Winemaker line 3041: "WRCFLAGS = -r -L" -> "WRCFLAGS = -r" ?
by Kjetil S. Matheussen Dec. 23, 2002

Dec. 23, 2002

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

2 1

Re: wineboot - Andy's version
by Shachar Shemesh Dec. 22, 2002

Dec. 22, 2002

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

3 3

Usage of strtolW in Setupapi install
by Uwe Bonnes Dec. 22, 2002

Dec. 22, 2002

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) ); }

1 0

Some strange winedbg regression...
by Lionel Ulmer Dec. 22, 2002

Dec. 22, 2002

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/

5 5

[RFC] wintab dll design: how to intergrate with current X11 code.
by Robert North Dec. 22, 2002

Dec. 22, 2002

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.

1 1

Conditional to support Solaris
by Robert Lunnon Dec. 22, 2002

Dec. 22, 2002

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

2 2

wine + eBay's auction-tool "MisterLister"
by KatjaundSiegfried.Haas＠t-online.de Dec. 21, 2002

Dec. 21, 2002

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

4 3

Re: Conformance tests failing
by chrismorgan＠rcn.com Dec. 21, 2002

Dec. 21, 2002

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

2 1

Fwd: Get rid of W->A calls: GetPrinterDriverDirectory
by Stefan Leichter Dec. 21, 2002

Dec. 21, 2002

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

1 0

Wine 0.9 TODO v0.7
by Dimitrie O. Paun Dec. 21, 2002

Dec. 21, 2002

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.

4 5

shlwapi/clist test error on NT4
by Francois Gouget Dec. 21, 2002

Dec. 21, 2002

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

1 0