November 2004 - Wine-Devel - list.winehq.org

Re: misc. crypt test mem leak fixes

by Dmitry Timoshkov

"James Hawkins" <truiken(a)gmail.com> wrote: > Changelog > * misc. crypt test mem leak fixes Apparently lines with LocalAlloc were added by mistake instead of LocalFree. -- Dmitry.

Nov. 30, 2004

Porting SmartWin a Windows API GUI library...

by Thomas Hansen

I'm the admin of http://smartwin.sourceforge.net and I've been thinking that if this library (SmartWin) could be ported to WineLib that would be really awesome... I would definitely take it right into the CVS (unless it breaks everything) and I'd make it a definitely focus trying to keep the compatibility towards WineLib in later releases... I assume it would be a nice project to do too. (not too much code, only about 15 000 lines with LOTS of comments) Not to mention the benefit it would give the community having a Windows API library being ported to Wine... Comments sombody...? Thomas Hansen -- http://smartwin.sourceforge.net THE template based C++ Windows API GUI Abstraction Library

Nov. 30, 2004

Re: gdi/mfdrv BS_PATTERN brushes

by Huw D M Davies

On Mon, Nov 29, 2004 at 09:16:49PM -0800, Walt Ogburn wrote: > > This fixes the problem that Emanuele Gisi reported last month in the Aloha > problem. With this patch BS_PATTERN brushes get created correctly and > don't cause a locking problem. > > Changelog: > Fix creation of BS_PATTERN brushes in mfdrv > > > Index: dlls/gdi/mfdrv/objects.c > =================================================================== > RCS file: /home/wine/wine/dlls/gdi/mfdrv/objects.c,v > retrieving revision 1.14 > diff -u -r1.14 objects.c > --- dlls/gdi/mfdrv/objects.c 22 Nov 2004 18:19:59 -0000 1.14 > +++ dlls/gdi/mfdrv/objects.c 30 Nov 2004 06:10:03 -0000 > - mr->rdFunction = META_DIBCREATEPATTERNBRUSH; > + mr->rdFunction = META_CREATEPATTERNBRUSH; Does a BS_PATTERN brush really create a META_CREATEPATTERNBRUSH record under Windows? Huw. -- Huw Davies huw(a)codeweavers.com

Nov. 30, 2004

Re: icmstream mem leak fix

by Mike McCormack

James Hawkins wrote: > I just want to make sure I've got this. Do we want to release even if > the call to QueryInterface suceeds? The old code sets ref=0, then just free's the memory. My method would set ref=1, then call Release() which decrements ref and free's memory. If QueryInterface succeeds, then it will increment the reference count again, so we'll only end up free'ing memory in Release if the QueryInterface fails. It's a more COM-ish way of doing things... the original code still works though. Mike

Nov. 30, 2004

Re: icmstream mem leak fix

by James Hawkins

On Tue, 30 Nov 2004 16:32:59 +0900, Mike McCormack <mike(a)codeweavers.com> wrote: > > > James Hawkins wrote: > > > Ignoring the change that I made, what is wrong with the current code? > > I kindof figured that pstream was tied into ppv, but I wanted to make > > sure. If that is the case, then my acmstream patch should be ignored > > as well. I thought to call LocalFree on pstream because it was > > allocated with LocalAlloc. Can you explain what should be written > > instead so I don't make the same mistake? > > Actually, the current code will work correctly. My nitpick is only that > you should use Release() instead of free() on an interface pointer. > > Mike > > > Index: dlls/avifil32/acmstream.c > =================================================================== > RCS file: /home/wine/wine/dlls/avifil32/acmstream.c,v > retrieving revision 1.14 > diff -u -r1.14 acmstream.c > --- dlls/avifil32/acmstream.c 5 Oct 2004 18:10:21 -0000 1.14 > +++ dlls/avifil32/acmstream.c 30 Nov 2004 08:21:29 -0000 > @@ -118,10 +118,10 @@ > return AVIERR_MEMORY; > > pstream->lpVtbl = &iacmst; > + pstream->ref = 1; > > hr = IAVIStream_QueryInterface((IAVIStream*)pstream, riid, ppv); > - if (FAILED(hr)) > - LocalFree((HLOCAL)pstream); > + IAVIStream_Release((IAVIStream*)pstream); > > return hr; > } > > > I just want to make sure I've got this. Do we want to release even if the call to QueryInterface suceeds? -- James Hawkins

Nov. 30, 2004

Re: Implement GetLayout

by Shachar Shemesh

Rémi Assailly wrote: > Shachar Shemesh wrote : > >> Thanks for spotting another one for my growing heap of BiDi TODOs.... >> >> http://bugs.winehq.org/show_bug.cgi?id=2584 >> >> Shachar >> > I know that there is no effect... I'm sorry if I came off cynical. There was no cynicism in that comment. I opened 2584 as a result of seeing your patch. I was not aware of this particular missing functionality. I'm aiming for http://bugs.winehq.org/show_bug.cgi?id=609 to be the ultimate documentation of all BiDi APIs in Windows. Opening 2584 is a good thing, as it documents things that are still to be done. > What is wrong ? It seems that this flag reverses the meaning of several common conventions (left/right etc.). The idea is probably so that applications that are natively right to left not have to change their design too much. I can't tell you exactly what it means, however, as I don't know myself. It will probably be a matter of comparing behaviors to the real Windows. I have some doubts about whether anyone is even using this flag at all. Maybe on localized Hebrew Windows, where the whole window decorations are reversed (Ughh. My GF has localized XP Home installed. This thing is horrible, but I didn't spot any non-Windows native applications that were affected by it). > Tell me and I will help you, if you want... I'll gladly accept all the help I can get. Basically, this particular unimplemented bit requires writing small test programs on Windows, and then running them on Wine until they produce the same results. The idea is that you read the MSDN page for the function (linked from the bug). That page also links to http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/wi…, which gives more details on what this flag is supposed to mean. If you check out 2584 again, you will see I added this new information there. The steps one takes is to read all the relevant manuals, and try to understand what this means. Next, you write a small test program that does stuff with and without this flag, showing where this flag takes effect on Windows. Next, you move this test program to Wine and start tweaking Wine until it behaves the same there. There is also a last step, which is to make this program into a test suite, returning success or failure. I'm not sure, however, how that is supposed to be done for programs where success and failure are measured with graphical output. Hope this helps you help me help everyone..... :-) Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Nov. 30, 2004

Re: icmstream mem leak fix

by Mike McCormack

James Hawkins wrote: > Ignoring the change that I made, what is wrong with the current code? > I kindof figured that pstream was tied into ppv, but I wanted to make > sure. If that is the case, then my acmstream patch should be ignored > as well. I thought to call LocalFree on pstream because it was > allocated with LocalAlloc. Can you explain what should be written > instead so I don't make the same mistake? Actually, the current code will work correctly. My nitpick is only that you should use Release() instead of free() on an interface pointer. Mike Index: dlls/avifil32/acmstream.c =================================================================== RCS file: /home/wine/wine/dlls/avifil32/acmstream.c,v retrieving revision 1.14 diff -u -r1.14 acmstream.c --- dlls/avifil32/acmstream.c 5 Oct 2004 18:10:21 -0000 1.14 +++ dlls/avifil32/acmstream.c 30 Nov 2004 08:21:29 -0000 @@ -118,10 +118,10 @@ return AVIERR_MEMORY; pstream->lpVtbl = &iacmst; + pstream->ref = 1; hr = IAVIStream_QueryInterface((IAVIStream*)pstream, riid, ppv); - if (FAILED(hr)) - LocalFree((HLOCAL)pstream); + IAVIStream_Release((IAVIStream*)pstream); return hr; }

Nov. 30, 2004

Re: Systray rewrite

by Grant Williamson

Hi Mike, patching is clean on 20041019, however .. fails with make[2]: Entering directory `/tmp/wine-20041019/dlls/shell32' ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./shell32.spec shell.spec.o shell.o authors.o autocomplete.o brsfolder.o changenotify.o classes.o clipboard.o control.o cpanelfolder.o dataobject.o debughlp.o dialogs.o dragdrophelper.o enumidlist.o folders.o iconcache.o memorystream.o pidl.o regsvr.o shell32_main.o shelllink.o shellole.o shellord.o shellpath.o shellreg.o shellstring.o shfldr_desktop.o shfldr_fs.o shfldr_mycomp.o shlexec.o shlfileop.o shlfolder.o shlfsbind.o shlmenu.o shlview.o shpolicy.o shv_bg_cmenu.o shv_item_cmenu.o systray.o shell32.dll.dbg.o shres.res version.res -o shell32.dll.so -L../../dlls -Wb,-dole32 -lshlwapi -lcomctl32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -L../../libs/wine -lwine -luuid -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port shell32_main.o(.text+0x23c6): In function `DllMain': /usr/src/redhat/BUILD/wine-20041019/dlls/shell32/shell32_main.c:962: undefined reference to `SYSTRAY_Init' collect2: ld returned 1 exit status winegcc: gcc failed. make[2]: *** [shell32.dll.so] Error 2 make[2]: Leaving directory `/tmp/wine-20041019/dlls/shell32' make[1]: *** [shell32] Error 2 make[1]: Leaving directory `/tmp/wine-20041019/dlls' make: *** [dlls] Error 2 Mike Hearn wrote: >Here it is, at last, just what the doctor ordered. All in a separate >wineshell process, and with cleaner code to boot. No thread safety >needed. Hopefully this is now satisfactory and can go in. > >The intention is that wineshell becomes a generic explorer-alike process >in terms of responsibility. For now, I have it being started >automatically by shell32 (to avoid the startup penalty), and shutting >down a few seconds after the last icon is gone like the wineserver. If >we start putting more stuff in there like a DDE server, we may have to >rethink that strategy. > >ChangeLog: >- Add a new wineshell process, and put system tray handling in there >- Rewrite the shell32 systray handling to be out of process >- Support the freedesktop.org XEMBED protocol > > > >

Nov. 30, 2004

Re: icmstream mem leak fix

by James Hawkins

Hey Mike, Ignoring the change that I made, what is wrong with the current code? I kindof figured that pstream was tied into ppv, but I wanted to make sure. If that is the case, then my acmstream patch should be ignored as well. I thought to call LocalFree on pstream because it was allocated with LocalAlloc. Can you explain what should be written instead so I don't make the same mistake? On Tue, 30 Nov 2004 16:07:18 +0900, Mike McCormack <mike(a)codeweavers.com> wrote: > > Hi James, > > That looks kind of wrong, both the before and after... > Interfaces should be released, not free'd... > > Secondly, freeing the interface if the Query works is almost definitely > wrong, because ppv will likely point to the same memory as pstream. > > Mike > > James Hawkins wrote: > > > hr = IAVIStream_QueryInterface((IAVIStream*)pstream, riid, ppv); > > - if (FAILED(hr)) > > - LocalFree((HLOCAL)pstream); > > + > > + LocalFree((HLOCAL)pstream); > > > > return hr; > > } > -- James Hawkins

Nov. 30, 2004

Re: icmstream mem leak fix

by Mike McCormack

Hi James, That looks kind of wrong, both the before and after... Interfaces should be released, not free'd... Secondly, freeing the interface if the Query works is almost definitely wrong, because ppv will likely point to the same memory as pstream. Mike James Hawkins wrote: > hr = IAVIStream_QueryInterface((IAVIStream*)pstream, riid, ppv); > - if (FAILED(hr)) > - LocalFree((HLOCAL)pstream); > + > + LocalFree((HLOCAL)pstream); > > return hr; > }

Nov. 30, 2004