wine-devel December 2002

wine-devel@winehq.org

132 participants
377 discussions

making an so wrapper for a windows dll
by Patrick Michael Kane 23 Dec '02

23 Dec '02

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 23 Dec '02

23 Dec '02

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 23 Dec '02

23 Dec '02

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 23 Dec '02

23 Dec '02

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 23 Dec '02

23 Dec '02

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 23 Dec '02

23 Dec '02

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 23 Dec '02

23 Dec '02

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 23 Dec '02

23 Dec '02

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 23 Dec '02

23 Dec '02

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 23 Dec '02

23 Dec '02

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

2 1

← Newer
1
...
6
7
8
9
10
11
12
...
38
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2002