- wine-devel - winehq.org

Re: Toolbar background error
by Alexandre Julliard 17 Aug '01

17 Aug '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > Now if I add immediately after : > > hdc = GetWindowDC(hwnd); > SendMessage(hwnd, WM_ERASEBKGND, (WPARAM) hdc, 0); > ReleaseDC(hwnd, hdc); > > I get a window that is completely white; maybe I am missing something but > I should see a small brown strip at the lower part of the window, corresponding > to the caption + menu height, no ? Yes; actually I realize now that my test app uses the CS_PARENTDC style, which is why I see that. The behavior that you observe is what happens without CS_PARENTDC; so it's actually more complex that I thought, we'll need to explicitly test the CS_PARENTDC flag. Sigh... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Problems building with extern inline functions in winebase.h
by Alexandre Julliard 17 Aug '01

17 Aug '01

Mike Bond <mbond(a)cox.rr.com> writes: > A couple days ago a number of inline functions were put into winebase.h. > Since then I have been unable to build, using gcc 2.96-81 (RedHat). Apparently > this version of gcc thinks that because there is an extern prefixing the > inline, even though the function does in fact have a body, that the > function really is external. Removing the extern, just having inline as > one would do in C++, does not appear to work correctly either, and causes > the function to appear as a exported symbol in all the object files that > header gets included with, thus resulting in multiple definitions. This patch should fix the build failure, though it doesn't explain why gcc doesn't inline such a simple function. Index: dlls/kernel/kernel32.spec =================================================================== RCS file: /opt/cvs-commit/wine/dlls/kernel/kernel32.spec,v retrieving revision 1.39 diff -u -r1.39 kernel32.spec --- dlls/kernel/kernel32.spec 2001/08/06 17:50:42 1.39 +++ dlls/kernel/kernel32.spec 2001/08/16 16:30:03 @@ -922,7 +922,9 @@ @ stub GetProcessPriorityBoost @ stdcall GetThreadPriorityBoost(long ptr) GetThreadPriorityBoost @ stdcall InterlockedCompareExchange (ptr long long) InterlockedCompareExchange +@ stdcall InterlockedCompareExchangePointer(ptr ptr ptr) InterlockedCompareExchangePointer @ stdcall InterlockedExchangeAdd (ptr long ) InterlockedExchangeAdd +@ stdcall InterlockedExchangePointer(ptr ptr) InterlockedExchangePointer @ stdcall IsProcessorFeaturePresent(long) IsProcessorFeaturePresent @ stdcall OpenWaitableTimerA(long long str) OpenWaitableTimerA @ stdcall OpenWaitableTimerW(long long wstr) OpenWaitableTimerW Index: scheduler/critsection.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/critsection.c,v retrieving revision 1.30 diff -u -r1.30 critsection.c --- scheduler/critsection.c 2001/08/09 21:21:13 1.30 +++ scheduler/critsection.c 2001/08/16 16:30:11 @@ -86,7 +86,7 @@ /*********************************************************************** * InterlockedCompareExchange (KERNEL32.@) */ -/* PVOID WINAPI InterlockedCompareExchange( PVOID *dest, PVOID xchg, PVOID compare ); */ +/* LONG WINAPI InterlockedCompareExchange( PLONG dest, LONG xchg, LONG compare ); */ __ASM_GLOBAL_FUNC(InterlockedCompareExchange, "movl 12(%esp),%eax\n\t" "movl 8(%esp),%ecx\n\t" @@ -95,10 +95,31 @@ "ret $12"); /*********************************************************************** + * InterlockedCompareExchangePointer (KERNEL32.@) + */ +/* PVOID WINAPI InterlockedCompareExchangePointer( PVOID *dest, PVOID xchg, PVOID compare ); */ +__ASM_GLOBAL_FUNC(InterlockedCompareExchangePointer, + "movl 12(%esp),%eax\n\t" + "movl 8(%esp),%ecx\n\t" + "movl 4(%esp),%edx\n\t" + "lock; cmpxchgl %ecx,(%edx)\n\t" + "ret $12"); + +/*********************************************************************** * InterlockedExchange (KERNEL32.@) */ /* LONG WINAPI InterlockedExchange( PLONG dest, LONG val ); */ __ASM_GLOBAL_FUNC(InterlockedExchange, + "movl 8(%esp),%eax\n\t" + "movl 4(%esp),%edx\n\t" + "lock; xchgl %eax,(%edx)\n\t" + "ret $8"); + +/*********************************************************************** + * InterlockedExchangePointer (KERNEL32.@) + */ +/* PVOID WINAPI InterlockedExchangePointer( PVOID *dest, PVOID val ); */ +__ASM_GLOBAL_FUNC(InterlockedExchangePointer, "movl 8(%esp),%eax\n\t" "movl 4(%esp),%edx\n\t" "lock; xchgl %eax,(%edx)\n\t" -- Alexandre Julliard julliard(a)winehq.com

4 5

Re: Toolbar background error
by Alexandre Julliard 17 Aug '01

17 Aug '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > By changing rgrc[0] when responding to WM_NCCALCSIZE. > It seems that it is only possible to erase properly the 'custom' nonclient > area by using GetWindowDC... So : > > --- defwnd.c.orig Sat Aug 11 10:23:18 2001 > +++ defwnd.c Fri Aug 17 19:47:17 2001 > @@ -462,8 +462,12 @@ > if (!hbr) return 0; > > /* GetClientRect used to be GetClipBox, but it is not what > - * Windows does, and it breaks badly with CS_PARENTDC */ > - GetClientRect( wndPtr->hwndSelf, &rect ); > + * Windows does, and it breaks badly with CS_PARENTDC > + * GetClientRect breaks too when we are called with a window > + * DC (!!) - what next ? */ > + rect.left = rect.top = 0; > + rect.right = wndPtr->rectWindow.right - wndPtr->rectWindow.left; > + rect.bottom = wndPtr->rectWindow.bottom - wndPtr->rectWindow.top; > DPtoLP( hdc, (LPPOINT)&rect, 2 ); > FillRect( hdc, &rect, hbr ); > return 1; > > What do you think ? That's not what Windows does. If you pass a window DC to WM_ERASEBKGND it only erases an area equivalent to the client area (shifted to be relative to the whole window), so GetClientRect is correct IMO. The non-client area should be painted upon WM_NCPAINT, not WM_ERASEBKGND. -- Alexandre Julliard julliard(a)winehq.com

1 0

err:module:map_image Could not map section .data, file probably truncated
by mdew 17 Aug '01

17 Aug '01

a number of apps that wouldve worked normally ..are now failing to load due to this error.. err:module:map_image Could not map section .data, file probably truncated /usr/local/bin/wine: can't exec './xxx.exe': error=21 -- id: 9DF3262C key fingerprint: B556 04DA CFD9 78DD 9215 A970 8196 FB6D 9DF3 262C

3 3

Re: Does Wine's winhlp work?
by Gerard Patel 17 Aug '01

17 Aug '01

At 02:43 PM 17/08/2001 +0200, you wrote: >I was about to ask the same question. My impression was that: >i) 'winhelp' is completely non-functional <snip> I think so - I have never found one help file that it can read. Gerard

1 0

Re: Toolbar background error
by Gerard Patel 17 Aug '01

17 Aug '01

At 05:10 PM 16/08/2001 GMT, you wrote: >It's the client rectangle in the toolbar (I believe). I've handed the >issue back to Guy. I think that's a general issue, not specific to toolbars. We are seeing it for toolbars because it's a trick that is used mainly for toolbars. What happens I think is that some apps are not satisfied with the standard toolbar look. They want to have a bigger border around the buttons. That is not provided by the standard control, at least when these apps were written (maybe it is now, I am not following these matters closely). What these apps are doing is playing with WM_NCCALCSIZE to restrict the client rectangle to something smaller than what remains when the system clips the true nonclient area. In the case of one of my test apps, this is done by subclassing (the Wine code is never called). Since GetWindowRect returns only the width and the height of the client area, and is setting the origin to 0 - 0, the custom client area appears higher that it is to WM_ERASEBKGND and the lower part of the window is not painted (toolbar in the case of the app I see) Now, I don't know yet how should be done the erasing of this custom nonclient area :-/ Gerard

2 1

Re: Does Wine's winhlp work?
by Waldek Hebisch 17 Aug '01

17 Aug '01

David D. Hagood wrote: >Is Wine's WinHelp program supposed to work? By that I mean, if I invoke >that program with a Windows help file, is it supposed to be able to >display the contents of the help file as Window's winhelp.exe would? I was about to ask the same question. My impression was that: i) 'winhelp' is completely non-functional ii) part reading help files only handles very old help files I implemented code to read somewhat newer help files, to degree that 'hlp2sgml' program is able to get some output, but since data structures used by graphical part are largly NOT filled, 'winhelp' itself has more reasons not to work (I have not sent patch to 'hlpfile.c' in case 'winhelp' actually can read some files). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

Does Wine's winhlp work?
by David D. Hagood 17 Aug '01

17 Aug '01

Is Wine's WinHelp program supposed to work? By that I mean, if I invoke that program with a Windows help file, is it supposed to be able to display the contents of the help file as Window's winhelp.exe would? I ask because 1) I have a program (DeLorme's AAA MapNGo) that uses WinHelp format documents for some of its normal operation, and 2) I have a WinHelp format file I'd dearly like to be able to access directly from Wine. When I try to launch Wine's Winhelp, it brings up a window, but the window is empty. If I go to File->Open and try to open a WinHelp file, I get the same result. Is there some setup I'm missing?

3 2

Refcounting in SelectObject
by Uwe Bonnes 17 Aug '01

17 Aug '01

Hallo, we discussed this January 2001 with no final outcome. Some application (gcprevue version 9) does 080673a0:Call gdi32.SelectObject(000011d4,000011d8) ret=5f485bb1 080673a0:Ret gdi32.SelectObject() retval=00000044 ret=5f485bb1 080673a0:Call gdi32.DeleteObject(000011d8) ret=5f487813 080673a0:Ret gdi32.DeleteObject() retval=00000001 ret=5f487813 080673a0:Call gdi32.BitBlt(000011d4,00000000,00000000,0000008c,000001a7,000009d0,00000000,00000000,00cc0020) ret=0048d1e6 and gets an XErrorEvent and fails to Debugbreak. Starting theapplication with winedbg still gets this error, but DebugBreak isn't executed and the application proceeds. The Windows Api explicitly tells for DeleteObject: Return Value: ... If the specified handle is not valid or is currently selected into a device context, the return value is FALSE. Windows Internals tells about some elements in GDIOBJHDR in debugbuild of windows and has pseudo code for incrementing some refrence counters in SelectObject. Appended patch tries to implement this scheme. The original discussion dissolved into nothing after Andi saw the need for such refcounting, but also mentioned possible resource leakage. Appended code tries to clean up better by: - Remembering an unsuccessfull DeleteObject by adding 0x8000 to the Refcount - Call DeleteObject in SelectObject when the RefCount of the released handle is 0x8000 - Decrementing the RefCount when a hBitmap is still selected into a DC when DeleteDC is called for that DC - Call DeleteObject in DeleteDC when RefCount is 0x8000 For some applications I tested, I always saw the delayed DeleteObject done after the refused DeleteObject in the first place. Is this approach better? Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing -- Index: wine/include/gdi.h =================================================================== RCS file: /home/wine/wine/include/gdi.h,v retrieving revision 1.50 diff -u -r1.50 gdi.h --- wine/include/gdi.h 2001/08/15 23:33:20 1.50 +++ wine/include/gdi.h 2001/08/16 23:23:12 @@ -45,6 +45,9 @@ HANDLE16 hNext; WORD wMagic; DWORD dwCount; + WORD wMetaList; + WORD wSelCount;/* only in debug builds of windows */ + WORD wObjTask;/* only in debug builds of windows */ } GDIOBJHDR; Index: wine/objects/gdiobj.c =================================================================== RCS file: /home/wine/wine/objects/gdiobj.c,v retrieving revision 1.54 diff -u -r1.54 gdiobj.c --- wine/objects/gdiobj.c 2001/08/16 19:13:52 1.54 +++ wine/objects/gdiobj.c 2001/08/16 23:23:13 @@ -374,6 +374,7 @@ obj->hNext = 0; obj->wMagic = magic|OBJECT_NOSYSTEM; obj->dwCount = ++count; + obj->wSelCount = 0; TRACE_SEC( *handle, "enter" ); return obj; @@ -545,6 +546,15 @@ GDI_ReleaseObj( obj ); return TRUE; } + + if(header->wSelCount) + { + TRACE("delayed for %04x because object in use, count %d\n", + obj,header->wSelCount); + header->wSelCount+=0x8000; /* mark for delete */ + GDI_ReleaseObj( obj ); + return FALSE; + } TRACE("%04x\n", obj ); @@ -814,12 +824,32 @@ HGDIOBJ WINAPI SelectObject( HDC hdc, HGDIOBJ handle ) { HGDIOBJ ret = 0; + GDIOBJHDR *header; + DC * dc = DC_GetDCUpdate( hdc ); if (!dc) return 0; TRACE("hdc=%04x %04x\n", hdc, handle ); if (dc->funcs->pSelectObject) ret = dc->funcs->pSelectObject( dc, handle ); GDI_ReleaseObj( hdc ); + if (ret) + { + if (!(header = GDI_GetObjPtr( handle, MAGIC_DONTCARE ))) return 0; + header->wSelCount++; + GDI_ReleaseObj(handle); + if (!(header = GDI_GetObjPtr( ret, MAGIC_DONTCARE ))) return 0; + if(header->wSelCount) + header->wSelCount--; + if(header->wSelCount == 0x8000) /* handle delayed DeleteObject*/ + { + header->wSelCount = 0; + GDI_ReleaseObj(ret); + TRACE("executing delayed DeleteObject for %04x\n",ret); + DeleteObject(ret); + } + else + GDI_ReleaseObj(ret); + } return ret; } Index: wine/objects/dc.c =================================================================== RCS file: /home/wine/wine/objects/dc.c,v retrieving revision 1.62 diff -u -r1.62 dc.c --- wine/objects/dc.c 2001/08/16 19:01:23 1.62 +++ wine/objects/dc.c 2001/08/16 23:23:14 @@ -766,6 +766,25 @@ if (dc->hGCClipRgn) DeleteObject( dc->hGCClipRgn ); if (dc->pAbortProc) THUNK_Free( (FARPROC)dc->pAbortProc ); if (dc->hookThunk) THUNK_Free( (FARPROC)dc->hookThunk ); + if (dc->hBitmap) + { + GDIOBJHDR * header; + if ((header = GDI_GetObjPtr( dc->hBitmap, MAGIC_DONTCARE ))) + { + if(header->wSelCount ) + header->wSelCount--; + if(header->wSelCount == 0x8000) + { + header->wSelCount = 0; + GDI_ReleaseObj(dc->hBitmap); + TRACE("executing delayed DeleteObject for %04x\n",dc->hBitmap); + DeleteObject(dc->hBitmap); + } + else + GDI_ReleaseObj(dc->hBitmap); + + } + } PATH_DestroyGdiPath(&dc->path); GDI_FreeObject( hdc, dc );

1 0

Re: DC lock in CreateDIBitmap
by Alexandre Julliard 16 Aug '01

16 Aug '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > CreateDIBitmap is called with the HDC lock hold, and when the (fColor) clause > is true, CreateDCA() checks that the lock is not hold. A laymans approach to > release hdc before CreateDCA() and reopen it afterwards resulted in this > report asr startup, with no visual output: I don't think we should be using CreateDC at all in CreateDIBitmap. Could you try this? Index: objects/dib.c =================================================================== RCS file: /opt/cvs-commit/wine/objects/dib.c,v retrieving revision 1.59 diff -u -r1.59 dib.c --- objects/dib.c 2001/08/15 23:33:20 1.59 +++ objects/dib.c 2001/08/16 21:08:12 @@ -875,12 +875,7 @@ /* Now create the bitmap */ - if (fColor) - { - HDC tmpdc = CreateDCA( "DISPLAY", NULL, NULL, NULL ); - handle = CreateCompatibleBitmap( tmpdc, width, height ); - DeleteDC( tmpdc ); - } + if (fColor) handle = CreateCompatibleBitmap( hdc, width, height ); else handle = CreateBitmap( width, height, 1, 1, NULL ); if (!handle) return 0; -- Alexandre Julliard julliard(a)winehq.com

2 1

Problems building with extern inline functions in winebase.h
by Mike Bond 16 Aug '01

16 Aug '01

A couple days ago a number of inline functions were put into winebase.h. Since then I have been unable to build, using gcc 2.96-81 (RedHat). Apparently this version of gcc thinks that because there is an extern prefixing the inline, even though the function does in fact have a body, that the function really is external. Removing the extern, just having inline as one would do in C++, does not appear to work correctly either, and causes the function to appear as a exported symbol in all the object files that header gets included with, thus resulting in multiple definitions. I'm not sure what the correct solution would be, other than using the older function call method for this version of gcc. Perhaps I'm just missing some variant on the use of inline? -- TTFN MikeB

5 5

Re: patch.py?id=997918367324549717828631
by Alexandre Julliard 16 Aug '01

16 Aug '01

lawson_whitney(a)juno.com writes: > I can't remember that I've ever seen the fixme that was here before, > but I'll check again when I send this. No, the CheckNotSysLevel calls were not done before. I added a few of them in GDI to find potential locking bugs; seems pretty successful so far ;-) I think this should fix your problem: Index: objects/dc.c =================================================================== RCS file: /opt/cvs-commit/wine/objects/dc.c,v retrieving revision 1.61 diff -u -r1.61 dc.c --- objects/dc.c 2001/08/15 23:33:20 1.61 +++ objects/dc.c 2001/08/16 17:34:45 @@ -524,7 +524,9 @@ success=FALSE; } GDI_ReleaseObj( hdcs ); + GDI_ReleaseObj( hdc ); DeleteDC( hdcs ); + if (!(dc = DC_GetDCPtr( hdc ))) return FALSE; } GDI_ReleaseObj( hdc ); return success; -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: [resend] Don't crash when CUPS is installed
by mm＠caldera.de 16 Aug '01

16 Aug '01

In article <997995321.1690.4.camel@bugg> you wrote: > Hi all, > Having CUPS installed and a printer in CUPS configured would crash an > application I'm looking at. The reason was that the printer would be > added with a NULL name. > - if (!AddPrinterA(NULL,2,(LPBYTE)&pinfo2a)) { > + if (!AddPrinterA(printers[i],2,(LPBYTE)&pinfo2a)) { This will just make the printer not added AT ALL, since there is the following code in AddPrinterW: if(pName != NULL) { ERR("pName = %s - unsupported\n", debugstr_w(pName)); SetLastError(ERROR_INVALID_PARAMETER); return 0; } Please do not apply. Ciao, Marcus

1 0

DC lock in CreateDIBitmap
by Uwe Bonnes 16 Aug '01

16 Aug '01

Hallo, with the new GDI_CheckNotLock() stuff, some application (gcprevue 9) fails with > err:win32:_CheckNotSysLevel Holding lock 0x4079b9e8 level 3 Backtrace is: Backtrace: =>0 0x400e21d1 (_CheckNotSysLevel+0x51(lock=0x4079b9e8) [syslevel.c:152] in libntdll.so) (ebp=405c6090) 1 0x4078261c (GDI_CheckNotLock+0x1c [gdiobj.c:510] in libgdi32.so) (ebp=405c60a0) 2 0x4077823d (CreateDCA+0x1d(driver=0x407909d3, device=0x0, output=0x0, initData=0x0, s=0x0, s=0x0, s=0x407909d3) [dc.c:558] in libgdi32.so) (ebp=405c61e8) 3 0x4077bbc6 (CreateDIBitmap+0x166(hdc=0xdec, header=0x41eadb50, init=0x0, bits=0x0, data=0x41eadb50, coloruse=0x0) [dib.c:881] in libgdi32.so) (ebp=405c6218) 4 0x409f9479 (X11DRV_DIB_CreateDIBSection+0x359(dc=0x404225f4, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0, ovr_pitch=0x0) [dib.c:3914] in libx11drv.so) (ebp=405c62a0) 5 0x4077bd75 (DIB_CreateDIBSection+0x65(hdc=0xdec, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0, ovr_pitch=0x0) [dib.c:944] in libgdi32.so) (ebp=405c62d4) 6 0x4077bdd1 (CreateDIBSection+0x31(hdc=0xdec, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0) [dib.c:961] in libgdi32.so) (ebp=405c6304) 7 0x00401fba (gcprevue.exe..text+0xfba in D:\cae\gcp9.0.0.8\gcprevue.exe) (ebp=ffffffff) CreateDIBitmap is called with the HDC lock hold, and when the (fColor) clause is true, CreateDCA() checks that the lock is not hold. A laymans approach to release hdc before CreateDCA() and reopen it afterwards resulted in this report asr startup, with no visual output: fixme:win32:PE_CreateModule Security directory ignored err:win32:_LeaveSysLevel (0x4079ba08, level 3): Invalid state: count 0 mutex (nil). err:ntdll:RtlpWaitForCriticalSection section 0x4010fb88 "rtl.c: peb_lock" wait timed out, retrying (60 sec) fs=030f err:ntdll:RtlpWaitForCriticalSection section 0x4010fb88 "rtl.c: peb_lock" wait timed out, retrying (60 sec) fs=031f err:ntdll:RtlpWaitForCriticalSection section 0x4079ba08 "gdiobj.c: GDI_level" wait timed out, retrying (60 sec) fs=008f How to cure this problem? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Stupid Winedbg question
by Bobby Bingham 16 Aug '01

16 Aug '01

Ok, I feel like an idiot for having to ask this, but it's my first time realing using the debugger. When wine starts the debugger on an exception, it opens it up in another xterm. Is there an easy way to copy it's output? The usual select and middle-click isn't working because it doesn't let me select the text to begin with. Thanks in advance for your patience. Bobby Bingham

3 2

Re: Extra space at bottom of toolbar
by Guy L. Albertelli 16 Aug '01

16 Aug '01

-----Original Message----- From: Bobby Bingham <uhmmmm(a)ameritech.net> To: Wine Devel <wine-devel(a)winehq.com> Date: Thursday, August 16, 2001 12:28 AM Subject: Extra space at bottom of toolbar >Has anyone else seen this... In WinZip 8.0 (I don't know about other >versions/software), there are about 6 extra pixels at the bottom of the >toolbar below the buttons. Does anyone know what's causing this? I can look >into it if I get some time, but I was wondering if anybody knew. > >Bobby Bingham > > The current CVS shows the following differences between the builtin control and the native one: 1. Button top-left corner is 2 pixels too high. 2. Button is 2 pixels too short. 3. Background bar is 2 pixels too wide. This gives the 6 pixels you noticed. Items 1 & 2 are definitely within the toolbar.c. Item 3 may be in either toolbar or rebar. I need to work on moving screenshots from Win to Linux for comparison. Guy

1 0

Re: Protocol for adding FIXMEs
by Alexandre Julliard 16 Aug '01

16 Aug '01

"Bill Medland" <medbi01(a)accpac.com> writes: > However I am occasionally frustrated by the number of times I see the same > FIXME (e.g. the pthread_rwlock* and the "kill other threads" one). I also > recognise from posts that these disconcert newbies whereas after a couple > of weeks one gets used to them. > > So maybe it is better to use FIXME comments where one knows that something > is wrong but it doesn't seem to matter. FIXME macros should be used in cases where we know something is wrong but we don't expect this part of the code to ever get used. This way if some app triggers the wrong code we can hear about it. It doesn't make sense to add FIXME output to parts of the code we know are going to be called, it just generates noise; a comment is much better in this case. > (For example the WM_NCCALCSIZE message uses wParam as a Boolean value and > if it is TRUE then the lParam no longer points to a simple rectangle but to > a structure whose first element is a rectangle. Very little if any code > handles that case explicitly.) I don't think this specific case is a FIXME at all. Apps are allowed to ignore the extra information if they don't have any use for it. -- Alexandre Julliard julliard(a)winehq.com

1 0

_CheckNotSysLevel (was: patch.py?id=997918367324549717828631)
by lawson_whitney＠juno.com 16 Aug '01

16 Aug '01

On Thu, 16 Aug 2001 whit(a)giftie.alien.org wrote: > Good day! > > I can't remember that I've ever seen the fixme that was here before, > but I'll check again when I send this. > Is that a new fixme? I reversed just this patch and there are more of this fixme than any other. Hope the backtrace I sent before is useful. Regards, Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: _CheckNotSysLevel Patch
by Alexandre Julliard 16 Aug '01

16 Aug '01

Bobby Bingham <uhmmmm(a)ameritech.net> writes: > winedbg winzip32 > ... > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > Stopped on breakpoint 1 at 0x004677fa (WINZIP32.EXE.EntryPoint in C:\Program > Files\WinZip\WINZIP32.EXE) If you run under winedbg directly the CheckNotSysLevel breakpoints are ignored, and it only stops at the program entry point; and the backtrace there is useless. Please run it under wine and let it start the debugger by itself when encountering the first CheckNotSysLevel, then you should get a proper backtrace. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: _CheckNotSysLevel Patch
by Alexandre Julliard 16 Aug '01

16 Aug '01

Bobby Bingham <uhmmmm(a)ameritech.net> writes: > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > err:seh:start_debugger Couldn't start debugger (winedbg 134640360 52) (2) > Read the Wine Developers Guide on how to set up winedbg or another debugger > > if the debugger is set up, I can continue, and and it works just fine. Before the continue, could you please do a backtrace and mail it to me? Thanks. -- Alexandre Julliard julliard(a)winehq.com

2 1

Protocol for adding FIXMEs
by Bill Medland 16 Aug '01

16 Aug '01

What do people think? I seem to have a knack for finding things that are probably going to need fixing at some point but for which I do not have time or knowledge currently. My first temptation is to add a FIXME macro in the code directly. However I am occasionally frustrated by the number of times I see the same FIXME (e.g. the pthread_rwlock* and the "kill other threads" one). I also recognise from posts that these disconcert newbies whereas after a couple of weeks one gets used to them. So maybe it is better to use FIXME comments where one knows that something is wrong but it doesn't seem to matter. (For example the WM_NCCALCSIZE message uses wParam as a Boolean value and if it is TRUE then the lParam no longer points to a simple rectangle but to a structure whose first element is a rectangle. Very little if any code handles that case explicitly.) I know that the manual (wine-devel 8.0) says to add FIXMEs I am concerned that this could lead to ridiculously large traces that hide the important stuff (to say nothing of upsetting timing) Any other views? Bill

1 0

RE: Toolbar background error
by Medland, Bill 16 Aug '01

16 Aug '01

I'll handle it. I have this horrible feeling its the compiler again (2.96-85; RedHat 7.1). (It seems to be a side-effect of DPtoLP!!??) Bill > -----Original Message----- > From: Guy L. Albertelli [SMTP:galberte@neo.lrun.com] > Sent: Wednesday, August 15, 2001 7:30 PM > To: Bill Medland > Cc: Wine Devel > Subject: Re: Toolbar background error > > > -----Original Message----- > From: Bill Medland <medbi01(a)accpac.com> > To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> > Date: Wednesday, August 15, 2001 4:39 PM > Subject: Re: Toolbar background error > > > >> > >> > >In case you haven't found it yet it is in windows/defwnd.c; the change > made > >between 1.57 and 1.58. Are you going to handle it? > > > >Bill > > > > > Bill, > > Great job in tracking it down. I probably won't get to having time till > Friday evening. If you see the problem and know the fix, by all means go > and > fix it. Otherwise I will look into this Friday. > > Thanks again, > Guy

3 2

patch.py?id=997918367324549717828631
by lawson_whitney＠juno.com 16 Aug '01

16 Aug '01

Good day! I guess native riched32.dll does something nasty to provoke the new DbgBreakPoint in _CheckNotSysLevel. Builtin riched32 doesn't, of course, but then the app won't start. I can't remember that I've ever seen the fixme that was here before, but I'll check again when I send this. I've attached a backtrace. I'd appreciate some guidance on what else might be useful, or maybe a pointer to some doco on critical sections in Wine, even it is in .sgml, .c or .h in case I have to debug it myself. Regards, Lawson

1 0

Wine call graph; wineserver; the "big picture"
by Phillip Schmitz 16 Aug '01

16 Aug '01

[I mistakenly posted this to comp.emulators.ms-windows.wine / wine-users rather than here. Thanks to eric pouech for his reply there. Sorry if you've already seen this there] Hi, I've been lurking for a while now with a view to starting work on wine - specifically COM and DCOM. I know some people have started some work and there might be some patent issues with COM at least - so maybe DCOM is a better bet (I had the possibly naive idea of implementing COM via DCOM - it would be almost transparent, slower but less "dangerous"). I've read most of the developer docs and some relevant source but I'm still having problems grokking the interrelationships between different parts of wine and the role(s) of wineserver. I have a general understanding of Win32 from a programatic point of view rather than wine's implementation details. While I'm quite willing to "read the source" there's rather a lot of it :) and rather deep dependencies (even with tags one jumps around for a while trying to understand what does what). Does anyone have a call graph for wine or a (decent, open-source) program for making one. I've considered Source-Navigator but it seems like the required database would be twice the size of the wine source! Since (D)COM affects many parts of function and message handling and process address space tampering I considered the less ambitious project of fixing up (Net)DDE first - at least then the all-important Hearts will run networked. Is anyone actively working on that (the source has sporadic updates)? I don't want to start hacking off on a tangent. The different behaviours of win9x and NT will also be a problem since I don't have a real NT installation Also, what do people use in terms of test-suites? custom win32 apps? free/shareware? While I have quite a few larger apps like Office etc I imagine it's better to try smaller, more specific apps at first. I want to do comparisons and communication with Win95/8 in VMWare and don't really want to _purchase more Win32 apps_ for testing! Thanks for any experience or insight you might share. Phillip

6 5

Extra space at bottom of toolbar
by Bobby Bingham 16 Aug '01

16 Aug '01

Has anyone else seen this... In WinZip 8.0 (I don't know about other versions/software), there are about 6 extra pixels at the bottom of the toolbar below the buttons. Does anyone know what's causing this? I can look into it if I get some time, but I was wondering if anybody knew. Bobby Bingham

2 1

_CheckNotSysLevel Patch
by Bobby Bingham 16 Aug '01

16 Aug '01

Ever since _CheckNotSysLevel was implemented in the CVS yesterday, I can't run any programs if the debugger isn't set up. I get: ... err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 err:seh:start_debugger Couldn't start debugger (winedbg 134640360 52) (2) Read the Wine Developers Guide on how to set up winedbg or another debugger if the debugger is set up, I can continue, and and it works just fine. Somehow I don't recall windows not running programs without setting up the debugger :-) Bobby Bingham

1 0

Re: Toolbar background error
by Guy L. Albertelli 16 Aug '01

16 Aug '01

-----Original Message----- From: Bill Medland <medbi01(a)accpac.com> To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> Date: Wednesday, August 15, 2001 4:39 PM Subject: Re: Toolbar background error >> >> >In case you haven't found it yet it is in windows/defwnd.c; the change made >between 1.57 and 1.58. Are you going to handle it? > >Bill > Bill, Great job in tracking it down. I probably won't get to having time till Friday evening. If you see the problem and know the fix, by all means go and fix it. Otherwise I will look into this Friday. Thanks again, Guy

1 0

Re: Toolbar background error
by Guy L. Albertelli 16 Aug '01

16 Aug '01

-----Original Message----- From: Bill Medland <medbi01(a)accpac.com> To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> Date: Wednesday, August 15, 2001 1:58 PM Subject: Re: Toolbar background error > >BTW since you are working on controls I thought I'd better let you know >this. > >I intend at some point working on the ListView control's handling of the >text in the large icon view unless someone gets there first. However it >will require corrections to DrawText/DrawTextEx's handling of the >EDIT_CONTROL style flag first (which affects the word wrapping/cutting of >long words in multiline stuff). In addition from a quick experiment I >think that quite a lot of work will be required within listview.c because >it appears to be unstably dependent on the fact that the size of the text >portion is currently constant; the clipping and repainting falls to pieces >when the size of the text depends on whether the icon is selected or not >etc. > >I thought I'd better let people know in case they get there before me. > Sounds great!! Have at it!! Guy

1 0

Re: toolbar
by Guy L. Albertelli 16 Aug '01

16 Aug '01

-----Original Message----- From: Mike McCormack <mike_mccormack(a)start.com.au> To: galberte(a)neo.lrun.com <galberte(a)neo.lrun.com> Date: Wednesday, August 15, 2001 8:11 PM Subject: Re: toolbar >Hey Guy, > >i updated from CVS thismorning, and saw some messages in wine-devel >about the toolbar, so did a quick test with WinZip 8. > >Everything seems to be fine! There are still some minor drawing >problems, but they were there before. They are: > >* button sometimes remains in the clicked state after i click it... >for example after clicking on the Open button in WinZip, the Open File >dialog appears, but the Open button is still in the clicked state. It >remains that way until i move the mouse over it again. Yes , I have seen this also. I am not sure what the problem is or even where. Possibilities: - WM_MOUSELEAVE not always getting generated. - Toolbar processing of WM_MOUSELEAVE is not 100% correct. - Something totally else. > >* sometimes after the tooltips disappear, the rectangle around the >edge of the button is not redrawn, so there is a "mark" where the >tooltip was. > I have not seen this, but I haven't looked for it. Thanks, Guy

1 0

Re: Toolbar background error
by Guy L. Albertelli 15 Aug '01

15 Aug '01

Bill, Can you try the current CVS and let me know how that works. I have been doing some work with Toolbar, Rebar, etc. and the background drawing was one of the problems. If it still has problems, let me know the application and I will work on it. Thanks, Guy -----Original Message----- From: Bill Medland <medbi01(a)accpac.com> To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> Date: Wednesday, August 15, 2001 11:12 AM Subject: Toolbar background error >Has anyone else noticed this? Is anyone already looking into this? > >Sometime during July something was changed that resulted on my setup >failing to draw the toolbar background properly (it leaves the bottom third >transparent). > >Since I have had previous problems with this setup (due to some sort of gcc >bug) I thought I'd check. > >Bill > > > > >

2 2

RE: Toolbar background error
by Medland, Bill 15 Aug '01

15 Aug '01

I am just compiling up today's Wine; it was certainly there yesterday. As far as I can tell it crept in between 20010726 and 20010731 (dates in the WINE cvs itself). I will send you a test executable that shows the problem. Let me know how it appears on yours. Bill > -----Original Message----- > From: Guy L. Albertelli [SMTP:galberte@neo.lrun.com] > Sent: Wednesday, August 15, 2001 10:01 AM > To: Bill Medland > Cc: Wine Devel > Subject: Re: Toolbar background error > > Bill, > > Can you try the current CVS and let me know how that works. I have been > doing some work with Toolbar, Rebar, etc. and the background drawing was > one > of the problems. > > If it still has problems, let me know the application and I will work on > it. > > Thanks, > > Guy > -----Original Message----- > From: Bill Medland <medbi01(a)accpac.com> > To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> > Date: Wednesday, August 15, 2001 11:12 AM > Subject: Toolbar background error > > > >Has anyone else noticed this? Is anyone already looking into this? > > > >Sometime during July something was changed that resulted on my setup > >failing to draw the toolbar background properly (it leaves the bottom > third > >transparent). > > > >Since I have had previous problems with this setup (due to some sort of > gcc > >bug) I thought I'd check. > > > >Bill > > > > > > > > > >

1 0

Transparent child windows
by Timo Kujala 15 Aug '01

15 Aug '01

Hi, Some time ago I posted a problem with M$ 32-bit terminal server client, as it did not paint it's window. Finally I got some time to look into this a bit more and found out following: The terminal server client creates (among other windows) two child windows, "Input Capture Window" and "Output Painter Window" (in that order). Input capture window is specified as transparent and it is laid over the output painter window so that the actual image is painted in the output painter window and input capture window just receives mouse clicks and keyboard input. The problem is that the input capture window is not really transparent. Output painter window is behind it and therefore output is never seen. (I was able to find this out by moving input capure window away from the view by modifying code in createwindow-call in win.c, but then mouse won't work in terminal server client) Any fixes for this?

1 0

Toolbar background error
by Bill Medland 15 Aug '01

15 Aug '01

Has anyone else noticed this? Is anyone already looking into this? Sometime during July something was changed that resulted on my setup failing to draw the toolbar background properly (it leaves the bottom third transparent). Since I have had previous problems with this setup (due to some sort of gcc bug) I thought I'd check. Bill

1 0

Re: printing AND memory
by Richard Canada 15 Aug '01

15 Aug '01

> Richard Canada wrote: > >>trace:psdrv:PSDRV_FindPrinterInfo 'Wine PostScript Driver' >>err:psdrv:PSDRV_FindPrinterInfo Error 2 getting PPD file name for >>printer 'Wine PostScript Driver' >>trace:psdrv:PSDRV_CreateDC (WINEPS Wine PostScript Driver LPT1: (nil)) >>trace:psdrv:PSDRV_FindPrinterInfo 'Wine PostScript Driver' >>err:psdrv:PSDRV_FindPrinterInfo Error 2 getting PPD file name for >>printer 'Wine PostScript Driver' >>trace:psdrv:PSDRV_CreateDC (WINEPS Wine PostScript Driver LPT1: (nil)) >>fixme:pthread_kill_other_threads_np >> >> > > It looks like you haven't specified a PPD file for your printer. The > right method for configuring this varies, depending on how you've > configured your printer, so I need to know how you set up your printer. > -- > ======================================================================== > Ian Pilcher ian.pilcher(a)home.com > ======================================================================== This is how I have my printer set up: (snip from my wine config file) [afmfiles] "file<n>" = "/usr/share/fonts/afms/adobe/pagd8a.afm" [psdrv] "ppdfile" = "/windows/wine/TEMP/ADOBE/HP/HP4PLUS6.PPD" [serialports] "Com1" = "/dev/ttyS0" "Com2" = "/dev/ttyS1" "Com3" = "/dev/ttyS2" "Com4" = "/dev/modem" [parallelports] "Lpt1" = "/dev/lp0" [ppdev] ;; key: io-base of the emulated port ;; value : parport-device{,timeout} ;; timeout for auto closing an open device ( not yet implemented) ;"378" = "/dev/parport0" ;"278" = "/dev/parport1" ;"3bc" = "/dev/parport2" [spooler] "FILE:" = "tmp.ps" "LPT1:" = "|lp -ddevelp -tRICHARD" "LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -" "LPT3:" = "/dev/lp3" I have set up the win.ini file correctly, here is the file: [devices] Wine PostScript Driver=WINEPS,LPT1: [windows] device=Wine PostScript Driver,WINEPS,LPT1: [PrinterPorts] Wine PostScript Driver=WINEPS,LPT1: BTW, I am using LPRng on my RedHat 7.1 box. I have no local printers, only network printers that I print to through a print server. Any more suggestions, I would appreciate it. Regards, Richard

1 0

wine server
by Mike McCormack 15 Aug '01

15 Aug '01

Hi Phillip, The wineserver does the job of the Windows NT kernel in wine. Here's a summary of what i've worked out about the wineserver: * the wineserver is responsible for all system level synchronization of wine processes, and maintaining integrity of handles * the wineserver is the sole repository for all HANDLE data in the wine process group. * wineserver communicates with each wine process thru a socket and shared memory. There is one socket and one shared memory area per wine process. * the main task of wineserver is a loop which polls on all the wine process sockets, and handles timeouts. * the wineserver processes requests one by one (it is a single thread). * each request is triggered by the wine process writing to its socket, and ended when the wineserver writes back to the socket. During the request, the wine process is effectively stopped. * request data may be read to or written from the shared memory, but the shared memory is not used for synchronization. Synchronization is maintained solely by socket reads and writes. * the wineserver should end each request before processing the next * the wineserver must never wait for or depend upon any wine processes. All wine processes must be assumed to be unstable and unreliable. (even if they're not) * the wineserver design is reliable, but rather slow due to all the context switching required by each request. David Howells made an effort to turn it into a Linux kernel module... he hasn't finished yet. hope that's accurate and helpful... Mike ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Unable to use RegisterClass(&WndClass);
by Craig Chandler 14 Aug '01

14 Aug '01

when i use the RegisterClass(&WndClass); under wine the call fails. I'm using it to sub class the button class. Does wine not support this? Interdynamics Web Page : http://www.interdynamics.com

2 8

printing AND memory
by Richard Canada 14 Aug '01

14 Aug '01

Does anyone know why I am getting an error message about "Insufficient memory" when I try to print from wine? I can see the printer is there, but I cannot print. I am running Lotus Notes 5.0.6. Thanks Richard

3 4

Re: Solaris X86 mmap...
by Alexandre Julliard 14 Aug '01

14 Aug '01

Robert Lunnon <bob(a)yarrabee.net.au> writes: > After that point I can't find any reference to this patch, it certainly > hasn't made it into the CVS yet ? > > Does anyone know the outcome of this work, or am I the only Solaris X86 > user out there :-) Last I heard it needed someone to test it on Solaris x86, but nobody ever did. So yes it seems you may be the only user out there... If you tested it and it works for you, please submit it to wine-patches. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Advice please. adding a MODULE_LoadLibraryExA argument
by Alexandre Julliard 14 Aug '01

14 Aug '01

"Bill Medland" <medbi01(a)accpac.com> writes: > The way I would prefer would be to add an argument to all the functions in > the recursion and use that to carry the name around. > MODULE_LoadLibraryExA > PE_LoadLibraryExA > ELF_LoadLibraryExA > PE_CreateModule > fixup_imports > > Any objections? This won't work for builtin dlls, you cannot pass an argument into dlopen(). This is not a problem for builtins themselves since they are not searched the same way, but it may break if a builtin imports a native dll. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: SNOOP: How to find out if an DLL entry is a DATA reference?
by Alexandre Julliard 14 Aug '01

14 Aug '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > However I like to ask if there are other methods of distinguishing DATA and > function references? Could the PE loader perhaps know? Or can we perhaps > protect our snoop entries from being read as data and catch those exceptions? > Any other idea? I don't think there's any way to make snoop 100% reliable, the PE file simply doesn't contain enough information. This is the reason we have to build special tables in the builtin dlls for relay debugging. -- Alexandre Julliard julliard(a)winehq.com

1 0

Advice please. adding a MODULE_LoadLibraryExA argument
by Bill Medland 14 Aug '01

14 Aug '01

I'd appreciate advice on this. I am looking at adding the handling of LoadLibraryExA (..LOAD_WITH_ALTERED_SEARCH_PATH) (which we use) and I am wondering about how to carry around the library directory during the recursion on MODULE_LoadLibraryExA. The easiest way is to put it in a static variable (ok, some allocated memory pointed to by a static variable) and depend upon the existing critical sections (which I don't understand particularly) to ensure it is only used by the currently loading tree of DLLS (i.e. set it up after the RtlAcquirePebLock in MODULE_LoadLibraryExA). However I dislike using static variables as a matter of principle. The way I would prefer would be to add an argument to all the functions in the recursion and use that to carry the name around. MODULE_LoadLibraryExA PE_LoadLibraryExA ELF_LoadLibraryExA PE_CreateModule fixup_imports Any objections? Bill

1 0

Solaris X86 mmap...
by Robert Lunnon 14 Aug '01

14 Aug '01

On Jan 10 2001 Ulrich Weigand submitted a patch to library/port.c to attempt to fix the linux mmap behaviour dependency for solaris systems. After that point I can't find any reference to this patch, it certainly hasn't made it into the CVS yet ? Does anyone know the outcome of this work, or am I the only Solaris X86 user out there :-)

1 0

SNOOP: How to find out if an DLL entry is a DATA reference?
by Uwe Bonnes 14 Aug '01

14 Aug '01

Hallo, e.g. with the MFC libraries the snoop option crashes quite often, while without snoop the programm proceeds some more. Digging deeper for the crash in msdev.exe, I saw that a library has exported DATA entries mixed into the codesegment. Our snoop loader only checks for DATA entries in the PE DATA section and so happyly overwrites data. It seems that most exported DATA entries have a decorated name ending in @A or @B and by handling entries with that ending as DATA, the crash with msdev.exe happens at the same place with or without snoop. Appended patch does this hacky search for DATA entries. However I like to ask if there are other methods of distinguishing DATA and function references? Could the PE loader perhaps know? Or can we perhaps protect our snoop entries from being read as data and catch those exceptions? Any other idea? Bye Changelog: relay32/snoop.c: SNOOP_GetProcAddress Don't snoop on names ending in "@A" and "@B", they seem to be DATA entries. Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing -- Index: wine/relay32/snoop.c =================================================================== RCS file: /home/wine/wine/relay32/snoop.c,v retrieving revision 1.45 diff -u -r1.45 snoop.c --- wine/relay32/snoop.c 24 Jul 2001 21:45:24 -0000 1.45 +++ wine/relay32/snoop.c 13 Aug 2001 19:51:42 -0000 @@ -158,7 +158,7 @@ SNOOP_GetProcAddress(HMODULE hmod,LPCSTR name,DWORD ordinal,FARPROC origfun) { SNOOP_DLL *dll = firstdll; SNOOP_FUN *fun; - int j; + int j,len; IMAGE_SECTION_HEADER *pe_seg = PE_SECTIONS(hmod); if (!TRACE_ON(snoop)) return origfun; @@ -182,7 +182,14 @@ !(pe_seg[j].Characteristics & IMAGE_SCN_CNT_CODE) ) return origfun; - + /* some heuristic to filter out DATA objects + decorated names end like "@A" and "@B" and some more */ + len=strlen(name); + if ((name [len-2] == '@') && ((name[len-1] == 'A') || (name[len-1] == 'B'))) + { + return origfun; + } + while (dll) { if (hmod == dll->hmod) break;

2 1

IShellLinkA_fnSetIconLocation problem with Kid Pix 3?
by Dan Kegel 13 Aug '01

13 Aug '01

Kid Pix 3 doesn't install with Wine from cvs (with either August 6th's or today's cvs). The problem appears to be related to shortcut or icon creation, as the installer bombs with alert "Cannot create shortcuts." right after checking for the existence of "Picker.ico". Here is what seems to be the interesting 250-line section of the log, starting with the fnSetIconLocation and ending with the "Cannot create shortcuts". There is an iffy looking line near the bottom I've marked with !!!!!!!!!!!!!. I'd be grateful for any suggestions. Thanks, Dan trace:shell:IShellLinkA_fnSetIconLocation (0x418884bc)->(path=C:\Program Files\Broderbund\Kid Pix Deluxe 3\Picker.ico iicon=0) trace:shell:IShellLinkA_fnQueryInterface (0x418884bc)->( IID: {0000010b-0000-0000-c000-000000000046}) trace:shell:IPersistFile_fnAddRef (0x418884bc)->(count=1) trace:shell:IShellLinkA_fnAddRef (0x418884bc)->(count=1) trace:shell:IShellLinkA_fnQueryInterface -- Interface: (0x405d53fc)->(0x418884c8) 08077c28:Call kernel32.MultiByteToWideChar(00000000,00000000,405d51dc "C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk",ffffffff,405d4dc0,00000104) ret=100394e7 08077c28:Ret kernel32.MultiByteToWideChar() retval=00000034 ret=100394e7 trace:shell:IPersistFile_fnSave (0x418884bc)->(L"C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk") 08077c28:Call advapi32.RegOpenKeyExA(80000002,40879140 "Software\\Wine\\Wine\\Config\\Wine",00000000,000f003f,405d490c) ret=408563c4 08077c28:Call ntdll.RtlInitAnsiString(405d47dc,40879140 "Software\\Wine\\Wine\\Config\\Wine") ret=407afaa4 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407afaa4 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d47dc,00000000) ret=407afaad 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407afaad 08077c28:Call ntdll.NtOpenKey(405d490c,000f003f,405d47e4) ret=407afac0 trace:reg:NtOpenKey (0x80000002,L"Software\\Wine\\Wine\\Config\\Wine",f003f,0x405d490c) trace:reg:NtOpenKey <- 0x0034 08077c28:Ret ntdll.NtOpenKey() retval=00000000 ret=407afac0 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407afac6 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407afac6 08077c28:Ret advapi32.RegOpenKeyExA() retval=00000000 ret=408563c4 08077c28:Call advapi32.RegQueryValueExA(00000034,4087915f "ShellLinker",00000000,405d4904,405d4c90,405d4908) ret=408563fb trace:reg:RegQueryValueExA (0x34,"ShellLinker",(nil),0x405d4904,0x405d4c90,0x405d4908=260) 08077c28:Call ntdll.RtlInitAnsiString(405d46f4,4087915f "ShellLinker") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d46f4,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d46fc,00000100,405d46f0) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"ShellLinker",2,0x405d46fc,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=00000000 ret=407b0cc4 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4708 L"wineshelllink",0000000e,00000000,00000000,00000000,00000000) ret=407b0ddc 08077c28:Ret kernel32.WideCharToMultiByte() retval=0000000e ret=407b0ddc 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4708 L"wineshelllink",0000000e,405d4c90,0000000e,00000000,00000000) ret=407b0e1b 08077c28:Ret kernel32.WideCharToMultiByte() retval=0000000e ret=407b0e1b 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000000 ret=408563fb 08077c28:Call advapi32.RegCloseKey(00000034) ret=40856411 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=40856411 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4dc0 L"C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk",ffffffff,405d4c90,00000104,00000000,00000000) ret=40856482 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000034 ret=40856482 08077c28:Call kernel32.GetFullPathNameA(405d4c90 "C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk",00000104,405d4b80,00000000) ret=408564b0 trace:string:lstrcpynA (0x405d43dc, "C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk", 1024) trace:string:lstrcpynA (0x405d4b80, "C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk", 260) 08077c28:Ret kernel32.GetFullPathNameA() retval=00000033 ret=408564b0 trace:shell:SHGetSpecialFolderPathA 0x0000,0x405d4c90,csidl=7,0x0000 08077c28:Call advapi32.RegCreateKeyExA(80000001,4087bb20 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders",00000000,00000000,00000000,000f003f,00000000,405d4568,405d456c) ret=4085d37e 08077c28:Call ntdll.RtlInitAnsiString(405d443c,4087bb20 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders") ret=407af91e 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407af91e 08077c28:Call ntdll.RtlInitAnsiString(405d4434,00000000) ret=407af92d 08077c28:Ret ntdll.RtlInitAnsiString() retval=400bf8ac ret=407af92d 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d443c,00000000) ret=407af936 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af936 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(405d442c,405d4434,00000001) ret=407af94a 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af94a 08077c28:Call ntdll.NtCreateKey(405d4568,000f003f,405d4444,00000000,405d442c,00000000,405d456c) ret=407af968 trace:reg:NtCreateKey (0x80000001,L"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders",L"",0,f003f,0x405d4568) trace:reg:NtCreateKey <- 0x0034 08077c28:Ret ntdll.NtCreateKey() retval=00000000 ret=407af968 08077c28:Call ntdll.RtlFreeUnicodeString(405d442c) ret=407af970 08077c28:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=407af970 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407af976 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407af976 08077c28:Ret advapi32.RegCreateKeyExA() retval=00000000 ret=4085d37e 08077c28:Call advapi32.RegQueryValueExA(00000034,405d4790 "StartUp",00000000,405d4560,405d4c90,405d4564) ret=4085d3aa trace:reg:RegQueryValueExA (0x34,"StartUp",(nil),0x405d4560,0x405d4c90,0x405d4564=260) 08077c28:Call ntdll.RtlInitAnsiString(405d4374,405d4790 "StartUp") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d4374,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d437c,00000100,405d4370) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"StartUp",2,0x405d437c,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=c0000034 ret=407b0cc4 08077c28:Call ntdll.RtlNtStatusToDosError(c0000034) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000002 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000002 ret=4085d3aa 08077c28:Call advapi32.RegCloseKey(00000034) ret=4085d3bd 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=4085d3bd 08077c28:Call advapi32.RegCreateKeyExA(80000001,4087bac0 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders",00000000,00000000,00000000,000f003f,00000000,405d4568,405d456c) ret=4085d3e8 08077c28:Call ntdll.RtlInitAnsiString(405d443c,4087bac0 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders") ret=407af91e 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407af91e 08077c28:Call ntdll.RtlInitAnsiString(405d4434,00000000) ret=407af92d 08077c28:Ret ntdll.RtlInitAnsiString() retval=400bf8ac ret=407af92d 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d443c,00000000) ret=407af936 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af936 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(405d442c,405d4434,00000001) ret=407af94a 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af94a 08077c28:Call ntdll.NtCreateKey(405d4568,000f003f,405d4444,00000000,405d442c,00000000,405d456c) ret=407af968 trace:reg:NtCreateKey (0x80000001,L"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders",L"",0,f003f,0x405d4568) trace:reg:NtCreateKey <- 0x0034 08077c28:Ret ntdll.NtCreateKey() retval=00000000 ret=407af968 08077c28:Call ntdll.RtlFreeUnicodeString(405d442c) ret=407af970 08077c28:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=407af970 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407af976 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407af976 08077c28:Ret advapi32.RegCreateKeyExA() retval=00000000 ret=4085d3e8 08077c28:Call advapi32.RegQueryValueExA(00000034,405d4790 "StartUp",00000000,405d4560,405d4c90,405d4564) ret=4085d408 trace:reg:RegQueryValueExA (0x34,"StartUp",(nil),0x405d4560,0x405d4c90,0x405d4564=260) 08077c28:Call ntdll.RtlInitAnsiString(405d4374,405d4790 "StartUp") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d4374,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d437c,00000100,405d4370) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"StartUp",2,0x405d437c,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=00000000 ret=407b0cc4 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4388 L"C:\\WINDOWS\\Start Menu\\Programs\\Startup",00000027,00000000,00000000,00000000,00000000) ret=407b0ddc 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000027 ret=407b0ddc 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4388 L"C:\\WINDOWS\\Start Menu\\Programs\\Startup",00000027,405d4c90,00000027,00000000,00000000) ret=407b0e1b 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000027 ret=407b0e1b 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000000 ret=4085d408 08077c28:Call advapi32.RegCloseKey(00000034) ret=4085d579 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=4085d579 08077c28:Call shlwapi.PathFileExistsA(405d4c90 "C:\\WINDOWS\\Start Menu\\Programs\\Startup") ret=4085d7d6 trace:shell:PathFileExistsA C:\WINDOWS\Start Menu\Programs\Startup 08077c28:Call kernel32.GetFileAttributesA(405d4c90 "C:\\WINDOWS\\Start Menu\\Programs\\Startup") ret=408fd447 trace:string:lstrcpynA (0x405d3bfc, "/home/dank/.wine/fake_windows", 1024) 08077c28:Ret kernel32.GetFileAttributesA() retval=00000010 ret=408fd447 08077c28:Ret shlwapi.PathFileExistsA() retval=00000001 ret=4085d7d6 trace:shell:SHGetSpecialFolderPathA 0x0000,0x405d4c90,csidl=16,0x0000 08077c28:Call advapi32.RegCreateKeyExA(80000001,4087bb20 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders",00000000,00000000,00000000,000f003f,00000000,405d4568,405d456c) ret=4085d37e 08077c28:Call ntdll.RtlInitAnsiString(405d443c,4087bb20 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders") ret=407af91e 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407af91e 08077c28:Call ntdll.RtlInitAnsiString(405d4434,00000000) ret=407af92d 08077c28:Ret ntdll.RtlInitAnsiString() retval=400bf8ac ret=407af92d 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d443c,00000000) ret=407af936 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af936 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(405d442c,405d4434,00000001) ret=407af94a 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af94a 08077c28:Call ntdll.NtCreateKey(405d4568,000f003f,405d4444,00000000,405d442c,00000000,405d456c) ret=407af968 trace:reg:NtCreateKey (0x80000001,L"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders",L"",0,f003f,0x405d4568) trace:reg:NtCreateKey <- 0x0034 08077c28:Ret ntdll.NtCreateKey() retval=00000000 ret=407af968 08077c28:Call ntdll.RtlFreeUnicodeString(405d442c) ret=407af970 08077c28:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=407af970 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407af976 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407af976 08077c28:Ret advapi32.RegCreateKeyExA() retval=00000000 ret=4085d37e 08077c28:Call advapi32.RegQueryValueExA(00000034,405d4790 "Desktop",00000000,405d4560,405d4c90,405d4564) ret=4085d3aa trace:reg:RegQueryValueExA (0x34,"Desktop",(nil),0x405d4560,0x405d4c90,0x405d4564=260) 08077c28:Call ntdll.RtlInitAnsiString(405d4374,405d4790 "Desktop") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d4374,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d437c,00000100,405d4370) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"Desktop",2,0x405d437c,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=c0000034 ret=407b0cc4 08077c28:Call ntdll.RtlNtStatusToDosError(c0000034) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000002 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000002 ret=4085d3aa 08077c28:Call advapi32.RegCloseKey(00000034) ret=4085d3bd 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=4085d3bd 08077c28:Call advapi32.RegCreateKeyExA(80000001,4087bac0 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders",00000000,00000000,00000000,000f003f,00000000,405d4568,405d456c) ret=4085d3e8 08077c28:Call ntdll.RtlInitAnsiString(405d443c,4087bac0 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders") ret=407af91e 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407af91e 08077c28:Call ntdll.RtlInitAnsiString(405d4434,00000000) ret=407af92d 08077c28:Ret ntdll.RtlInitAnsiString() retval=400bf8ac ret=407af92d 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d443c,00000000) ret=407af936 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af936 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(405d442c,405d4434,00000001) ret=407af94a 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af94a 08077c28:Call ntdll.NtCreateKey(405d4568,000f003f,405d4444,00000000,405d442c,00000000,405d456c) ret=407af968 trace:reg:NtCreateKey (0x80000001,L"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders",L"",0,f003f,0x405d4568) trace:reg:NtCreateKey <- 0x0034 08077c28:Ret ntdll.NtCreateKey() retval=00000000 ret=407af968 08077c28:Call ntdll.RtlFreeUnicodeString(405d442c) ret=407af970 08077c28:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=407af970 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407af976 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407af976 08077c28:Ret advapi32.RegCreateKeyExA() retval=00000000 ret=4085d3e8 08077c28:Call advapi32.RegQueryValueExA(00000034,405d4790 "Desktop",00000000,405d4560,405d4c90,405d4564) ret=4085d408 trace:reg:RegQueryValueExA (0x34,"Desktop",(nil),0x405d4560,0x405d4c90,0x405d4564=260) 08077c28:Call ntdll.RtlInitAnsiString(405d4374,405d4790 "Desktop") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d4374,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d437c,00000100,405d4370) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"Desktop",2,0x405d437c,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=00000000 ret=407b0cc4 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4388 L"C:\\WINDOWS\\Desktop",00000013,00000000,00000000,00000000,00000000) ret=407b0ddc 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000013 ret=407b0ddc 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4388 L"C:\\WINDOWS\\Desktop",00000013,405d4c90,00000013,00000000,00000000) ret=407b0e1b 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000013 ret=407b0e1b 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000000 ret=4085d408 08077c28:Call advapi32.RegCloseKey(00000034) ret=4085d579 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=4085d579 08077c28:Call shlwapi.PathFileExistsA(405d4c90 "C:\\WINDOWS\\Desktop") ret=4085d7d6 trace:shell:PathFileExistsA C:\WINDOWS\Desktop 08077c28:Call kernel32.GetFileAttributesA(405d4c90 "C:\\WINDOWS\\Desktop") ret=408fd447 trace:string:lstrcpynA (0x405d3bfc, "/home/dank/.wine/fake_windows", 1024) 08077c28:Ret kernel32.GetFileAttributesA() retval=00000010 ret=408fd447 08077c28:Ret shlwapi.PathFileExistsA() retval=00000001 ret=4085d7d6 08077c28:Call kernel32.wine_get_unix_file_name(4187b708 "C:\\Program Files\\Broderbund\\Kid Pix Deluxe 3\\KPRUN.EXE",405d4a70,00000104) ret=4085669d trace:string:lstrcpynA (0x405d4004, "/home/dank/.wine/fake_windows", 1024) trace:string:lstrcpynA (0x405d4a70, "/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3/KPRUN.EXE", 260) 08077c28:Ret kernel32.wine_get_unix_file_name() retval=00000001 ret=4085669d 08077c28:Call kernel32.wine_get_unix_file_name(41888530 "C:\\Program Files\\Broderbund\\Kid Pix Deluxe 3",405d4960,00000104) ret=4085671c trace:string:lstrcpynA (0x405d4004, "/home/dank/.wine/fake_windows", 1024) trace:string:lstrcpynA (0x405d4960, "/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3", 260) 08077c28:Ret kernel32.wine_get_unix_file_name() retval=00000001 ret=4085671c 08077c28:Call kernel32.LoadLibraryExA(4188856c "C:\\Program Files\\Broderbund\\Kid Pix Deluxe 3\\Picker.ico",00000000,00000002) ret=40855d46 trace:string:lstrcpynA (0x405d3e70, "/home/dank/.wine/fake_windows", 1024) warn:dosfs:DOSFS_FindUnixName 'Picker.ico' not found in '/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3' trace:string:lstrcpynA (0x405d3e2c, "/home/dank/.wine/fake_windows", 1024) warn:dosfs:DOSFS_FindUnixName 'Picker.ico' not found in '/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3' trace:string:lstrcpynA (0x418886ec, "C:\\WINDOWS\\SYSTEM", 260) !!!!!!!!!!!!!!!!!!!! why is it trying to load C:\WINDOWS\SYSTEM?! !!!!!!!!!!!!!!!!! warn:module:MODULE_LoadLibraryExA Failed to load module 'C:\WINDOWS\SYSTEM'; error=0x00000002, 08077c28:Ret kernel32.LoadLibraryExA() retval=00000000 ret=40855d46 trace:shell:ExtractFromEXEDLL LoadLibraryExA (C:\Program Files\Broderbund\Kid Pix Deluxe 3\Picker.ico) failed, error 2 trace:shell:IPersistFile_fnSave linker app='wineshelllink' link='Shortcut to Kid Pix Deluxe 3' mode=desktop path='/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3/KPRUN.EXE' args=' Main' icon='/tmp/fileUlFDEJ' workdir='/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3' descr='' fixme:pthread_kill_other_threads_np trace:shell:IPersistFile_fnRelease (0x418884bc)->(count=2) trace:shell:IShellLinkA_fnRelease (0x418884bc)->(count=2) trace:shell:IShellLinkA_fnRelease (0x418884bc)->(count=1) trace:shell:IShellLinkA_fnRelease -- destroying IShellLink(0x418884bc) 08077c28:Call ole32.CoUninitialize() ret=10039541 08077c28:Call kernel32.FreeLibrary(40845000) ret=408b00fc 08077c28:Ret kernel32.FreeLibrary() retval=00000001 ret=408b00fc 08077c28:Ret ole32.CoUninitialize() retval=00000000 ret=10039541 08077c28:Call window proc 0x416979 (hwnd=000001c0,msg=WM_USER+000c,wp=00000000,lp=00000000) 08077c28:Ret window proc 0x416979 (hwnd=000001c0,msg=WM_USER+000c,wp=00000000,lp=00000000) retval=00000000 08077c28:Call kernel32.lstrlenA(0048636c "") ret=00417ef4 08077c28:Ret kernel32.lstrlenA() retval=00000000 ret=00417ef4 08077c28:Call kernel32.lstrcpyA(4185a0e7,0048636c "") ret=0041801e 08077c28:Ret kernel32.lstrcpyA() retval=4185a0e7 ret=0041801e 08077c28:Call kernel32.lstrcpyA(405d6144,40491e32 "MESSAGE_CANNOT_CREATE_ICONS") ret=0041832a 08077c28:Ret kernel32.lstrcpyA() retval=405d6144 ret=0041832a 08077c28:Call kernel32.lstrlenA(4043bcec "Cannot create shortcuts.") ret=0045714a -- "I have seen the future, and it licks itself clean." -- Bucky Katt

1 0

Re: Question about network stuff
by Bobby Bingham 12 Aug '01

12 Aug '01

I'm not sure of the answer to your problem (could you be a little more specific than "it basically told me it couldn't access the network.) This isn't the right list for this question. This list is for patches that have been submitted to WINE. You might try the wine-users mailing list, or, if you're really daring, the wine-devel list if no one on wine-users knows Bobby Bingham Microsoft Windows: Made for the internet The Internet: Made for UNIX On Sunday 12 August 2001 02:02 am, you wrote: > Hi there > > (am I even on the right list??) > > I've been trying to get some Internet playable games to work with Wine, > namely everquest. > > I started out by making the mistake of running wine from my home dir (like > wine /win/d/everquest/everquest.exe) and having it download the whole game > from the 'net to my home dir.. I stopped that in a hurry :-) > > When I moved to /win/d/everquest, and tried to do wine ./everquest, it > basically told me it couldn't access the network. > > Why? How do I fix this? > > Thanks a ton, > > Tim

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Alexandre Julliard 11 Aug '01

11 Aug '01

Patrik Stridvall <ps(a)leissner.se> writes: > So to the details of the marshalling API (the unmarshalling API can wait). > 1. Where should we put them? Suggestion: include/wine/messsage.h No, it should be private to the dlls that really need it. We shouldn't add a global Wine-specific interface, we already have too many of that. And please don't go around converting all SendMessage calls to some marshalling API; this should be reserved to the cases where there is really a need. This is why I suggested to add the inline function in the C file directly: if there is a file where there are a lot of WM_COMMANDs with ugly casts, you can add an inline function there. But if there is only one or two, or calls that don't need ugly typecasts (most of them don't), then you definitely don't want to use the inline, just do a normal SendMessage. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Patrik Stridvall 11 Aug '01

11 Aug '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > We can just do it like: > > #ifdef __GNUC__ > > extern inline void FORWARD_WM_COMMAND(HWND hwnd, int id, > HWND hwndCtl, UINT > > codeNotify, WNDPROC fn) > > { > > fn(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), (LPARAM) hwnd); > > } > > #else > > #define FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, fn) \ > > (void)(fn)((hwnd), WM_COMMAND, > > MAKEWPARAM((UINT)(id),(UINT)(codeNotify)), (LPARAM)(HWND)(hwndCtl)) > > #endif > > > > if you wish. And if you are worried about preprocessor abusing > > Winelib application we could do #if defined(__GNUC__) && > defined(__WINE__) > > instead or use some kind of macro wrap around protection of the > > kind that I proposed that you didn't like. > > If you want to wrap WM_COMMAND, do something like: > > inline void send_wm_command(HWND hwnd, int id, HWND hwndCtl, > UINT codeNotify) > { > SendMessageW(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), > (LPARAM)hwndCtl); > } > > This is a normal function, doing a normal SendMessage call, and it's > perfectly all right with me. And if you want to do a PostMessage then > write a separate post_wm_command() function. Of course this is not a > standard Windows API so you cannot put it in the standard header > files; but you can have it in some dll private headers, or even > directly in the C files that need it. Ironically that was approximately my original idea. But I didn't think you would accept it so I didn't bother investigating further. Then I realized that the windowsx.h macros did what I wanted so choosed that solution instead. But sure we have a marshalling/unmarshalling API of our own, if that is what you want. Unless of course you prefer the hack below for PostMessage (not likely :-). So to the details of the marshalling API (the unmarshalling API can wait). 1. Where should we put them? Suggestion: include/wine/messsage.h 2. What should we call them? Suggestion: {POST,SEND}_WM_COMMAND etc. We really should capitalize the message name because of people doing "grep WM_COMMAND". And not capitalizing the POST/SEND would look silly if the suffix is capitalized. Sure they look like macros but then they could easily be made to be as an alterative implemention like #define SEND_WM_COMMAND(hwnd, id, hwndCtl, codeNotify) \ FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, SendMessage) 3. Do you want the macro wrapper (against the FORWARD API) above for the non GNU C case? 4. Should have have {POST,SEND}_WM_COMMAND{A,W} for calling {Post,Send}Message{A,W} or should we always the W variant like in your example above. > > To sum it up: > > 1. The FORWARD_* API and the HANDLE_* API really are normal > functions not > > macros (preprocessor abuses). The fact Micrsoft > implemented them as macros > > because of lack of compiler support for inline functions > or because of > > incompetence is irrelevant, we can do it right in a 100% > compatible way. > > No we can't; SendMessage and PostMessage don't have the same > prototype, so the preprocessor abuse is necessary to avoid > warnings. It seems you are right. PostMessage returns BOOL. Anyway there are not so many PostMessage calls that can be converted. $ find . -name \*.c | xargs grep PostMessage | grep WM_ | wc -l 35 The type compatible ones on the other hand are $ find . -name \*.c | xargs egrep 'Def.*Proc' | grep WM_ | wc -l 33 $ find . -name \*.c | xargs grep SendMessage | grep WM_ | wc -l 420 The Def.*Proc ones doesn't seem of closer examination to require marshalling of parameters so let skip them. Total 420 compared to 35. So we either decide not to use the the FORWARD_ API for such cases or we do: BOOL bResult = (BOOL) FORWARD_WM_COMMAND(/* ... */, (WNDPROC) PostMessageW); The use above is type correct regardless of whether FORWARD_WM_COMMAND is a macro or a inline function. A little ugly yes, but then it isn't nessary to convert the few PostMessage that exists to the FORWARD_* API at all.

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Alexandre Julliard 11 Aug '01

11 Aug '01

Patrik Stridvall <ps(a)leissner.se> writes: > We can just do it like: > #ifdef __GNUC__ > extern inline void FORWARD_WM_COMMAND(HWND hwnd, int id, HWND hwndCtl, UINT > codeNotify, WNDPROC fn) > { > fn(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), (LPARAM) hwnd); > } > #else > #define FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, fn) \ > (void)(fn)((hwnd), WM_COMMAND, > MAKEWPARAM((UINT)(id),(UINT)(codeNotify)), (LPARAM)(HWND)(hwndCtl)) > #endif > > if you wish. And if you are worried about preprocessor abusing > Winelib application we could do #if defined(__GNUC__) && defined(__WINE__) > instead or use some kind of macro wrap around protection of the > kind that I proposed that you didn't like. If you want to wrap WM_COMMAND, do something like: inline void send_wm_command(HWND hwnd, int id, HWND hwndCtl, UINT codeNotify) { SendMessageW(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), (LPARAM)hwndCtl); } This is a normal function, doing a normal SendMessage call, and it's perfectly all right with me. And if you want to do a PostMessage then write a separate post_wm_command() function. Of course this is not a standard Windows API so you cannot put it in the standard header files; but you can have it in some dll private headers, or even directly in the C files that need it. > To sum it up: > 1. The FORWARD_* API and the HANDLE_* API really are normal functions not > macros (preprocessor abuses). The fact Micrsoft implemented them as macros > because of lack of compiler support for inline functions or because of > incompetence is irrelevant, we can do it right in a 100% compatible way. No we can't; SendMessage and PostMessage don't have the same prototype, so the preprocessor abuse is necessary to avoid warnings. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Patrik Stridvall 11 Aug '01

11 Aug '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Microsoft introduced the windowsx.h macros for a reason and > > while without inline functions the current implementation > > of the FORWARD_* macros was the best they could do, it > > was at least better than nothing since it at least handled > > the parameter marshalling even if it wasn't 100% type safe. > > I wouldn't rely on Microsoft choices to judge an API design ;-) Point taken. :-) However not everything Microsoft does is bad, eventhough I admit that being sceptical is a good start. > > Another things to think about: > > What is the difference between calling {Set,Get}WindowText > > functions and calling the FORWARD_WM_{GET,SET}TEXT macros? > > It's a matter of taste. Calling a normal function is perfectly all > right; But they are normal functions. It is just not that apparent that they really are. Whether this is by design or by accident I leave unsaid. :-) Anyway, see below. > but I find that using a macro (or worse an inline function > masquerading as a macro) and having to pass it the name of the > function you want to call is ugly and offensive. If you want to call > SendMessage, then call SendMessage, don't hide it inside a macro. It is not hidden in the macro. Which function to call is provided as the last parameter of the macro. > Just because you can do all kinds of abuses of the preprocessor in C > doesn't mean you should. Well actually, the so called abuses of the preprocesor was for 100% compabillity with Winelib applications, if they abuse the fact that FORWARD_* might not always be macros (like doing undef on them). It is possible do it cleaner that the crude example I provide as well. Anyway, with the exception of preprocessor abusing application, which Wine easily can be made not to be. We can just do it like: #ifdef __GNUC__ extern inline void FORWARD_WM_COMMAND(HWND hwnd, int id, HWND hwndCtl, UINT codeNotify, WNDPROC fn) { fn(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), (LPARAM) hwnd); } #else #define FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, fn) \ (void)(fn)((hwnd), WM_COMMAND, MAKEWPARAM((UINT)(id),(UINT)(codeNotify)), (LPARAM)(HWND)(hwndCtl)) #endif if you wish. And if you are worried about preprocessor abusing Winelib application we could do #if defined(__GNUC__) && defined(__WINE__) instead or use some kind of macro wrap around protection of the kind that I proposed that you didn't like. Note that the above inline function "abuses" that fact that C autocasts between functions and pointer to functions, but then it standard well documented and often used "abuse", so calling it an abuse isn't really fair (not that you did since my example contained an unnessary &)). To sum it up: 1. The FORWARD_* API and the HANDLE_* API really are normal functions not macros (preprocessor abuses). The fact Micrsoft implemented them as macros because of lack of compiler support for inline functions or because of incompetence is irrelevant, we can do it right in a 100% compatible way. 2. The FORWARD_* API provides marshalling of parameters and the HANDLE_* API provides unmarshalling of parameters. 3. The FORWARD_* API provides type safe sending of parameters and the HANDLE_* API provides type safe recieving of parameters. Note that the fact that marshalling and unmarshalling of parameters are hidden makes that code much more readable and yes, I say it again, the FORWARD_* API and HANDLE_* API really are normal functions, there is no hidden traps for the unwary user. Just a nice wrapper for type safe marshalling and unmarshalling of parameters. PS. We could easily rewrite the HANDLE_* API as inline functions as well, I don't think it gives us anything though. They are good as they are AFAICS. But if you don't like macros, sure I can rewrite them as inline functions well. It just a lot of work to no gain AFAICS. It wouldn't hurt either though.

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Alexandre Julliard 10 Aug '01

10 Aug '01

Patrik Stridvall <ps(a)leissner.se> writes: > Microsoft introduced the windowsx.h macros for a reason and > while without inline functions the current implementation > of the FORWARD_* macros was the best they could do, it > was at least better than nothing since it at least handled > the parameter marshalling even if it wasn't 100% type safe. I wouldn't rely on Microsoft choices to judge an API design ;-) > Another things to think about: > What is the difference between calling {Set,Get}WindowText > functions and calling the FORWARD_WM_{GET,SET}TEXT macros? It's a matter of taste. Calling a normal function is perfectly all right; but I find that using a macro (or worse an inline function masquerading as a macro) and having to pass it the name of the function you want to call is ugly and offensive. If you want to call SendMessage, then call SendMessage, don't hide it inside a macro. Just because you can do all kinds of abuses of the preprocessor in C doesn't mean you should. -- Alexandre Julliard julliard(a)winehq.com

1 0

2025

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