June 2006 - Wine-Devel - list.winehq.org

Re: FW: RE: My 1.0 wish list

by EA Durbin

I have compiled a list of applications that are affected by the bug in which the query in ready_media_for_file() in MSI returns the wrong results, it returns LastSequence less than the file->Sequence being passed. Here is a detailed analysis of the multiple types of errors this bugs causes. Common debug outputs of this bug are: Error #1: err:msi:ACTION_InstallFiles compressed file wasn't extracted This error is usually caused by the results of the query returning a LastSequence number of Less than that of the working install media and the installer is trying to extract the file from the wrong install medium. Error #2: err:msi:extract_cabinet_file FDICopy failed err:msi:ACTION_InstallFiles Unable to ready media There is a zero in LastSequence Value of the Media table and the query in ready_media_for_file() returns it. For some reason the msi file has a zero in the LastSequence but its really a dummy cabinet file and doesn't exist. The file sequence being passed for the first file is most likely 1, and the query of >= 1 is returning 0 falsely causing this error. This problem in MSI spans a multitude of bugs. America's Army - bug #5139 J2SE - bug # 4280 Half Life 2 - bug # 5004, 4533 Dawn of War Demo - bug # 3749 E-Sword 6.5 - bug # 4251 Rush for Berlin demo - bug #5187 ATI demo(Rendering With Natural Light ) - bug # 4712? There are probably other bugs resulting from this, but the log doesn't detail it well enough, alot of them just have the debug dump at the end and not the pertainent msi err lines. I only included applications where it was obvious from the log, or I tested personally. >From: Mike McCormack <mike(a)codeweavers.com> >To: EA Durbin <ead1234(a)hotmail.com> >Subject: Re: FW: RE: My 1.0 wish list >Date: Sun, 04 Jun 2006 00:30:41 +0900 > > >You can send me as many mails as you like, but I'm not doing anything until >there's a test case showing the problem. > >Mike I wrote a test showing the results of the query in the wine installer and included the source code and resulting logs which clearly displays the problem. That's the best I can do. I'm not up to snuff on my C programming, nor am I familiary with how the official test case for wine is supposed to be layed out. If someone else wants to work on it then thats fine, but I layed out the problem, and debugged it, and I've proven this with code and resulting logs. This problem affects a multitude of applications in wine. If your not willing to work on it then either someone else can, or it can remain broken.

June 3, 2006

Re: DAZ Studio

by Vitaliy Margolen

Saturday, June 3, 2006, 6:14:14 AM, Andrew Neil Ramage wrote: > After running winecfg and setting winver for DAZStudio.exe to XP, I get > the following. > andrew(a)apollo:~/Download/Windows> wine > /home/andrew/.wine/drive_c/Program\ Files/DAZ/Studio/DAZStudio.exe > fixme:imm:ImmReleaseContext (0x10020, 0x403cde30): stub [skip] Please open a bug in bugzilla and report this problem there. (Attach your terminal output, don't paste). This list is not for such reports. Thank you . Vitaliy

June 3, 2006

Re: mapi32: Write-strings warnings fix

by Peter Oberndorfer

On Saturday 03 June 2006 16:33, Andrew Talbot wrote: > Changelog: > mapi32: Write-strings warnings fix. > > diff -urN a/dlls/mapi32/sendmail.c b/dlls/mapi32/sendmail.c > --- a/dlls/mapi32/sendmail.c 2006-05-23 17:24:40.000000000 +0100 > +++ b/dlls/mapi32/sendmail.c 2006-06-03 14:44:21.000000000 +0100 > @@ -113,8 +113,8 @@ > } > if (message->nFileCount) FIXME("Ignoring attachments\n"); > > - subject = message->lpszSubject ? message->lpszSubject : ""; > - body = message->lpszNoteText ? message->lpszNoteText : ""; > + subject = message->lpszSubject ? message->lpszSubject : NULL; > + body = message->lpszNoteText ? message->lpszNoteText : NULL; I think this is wrong, as it makes the whole "? :" construct unnecessary. (for non NULL it evaluates to "message->lpszNoteText" and for NULL it becomes NULL; > > TRACE( "Subject: %s\n", debugstr_a(subject) ); > TRACE( "Body: %s\n", debugstr_a(body) ); > > > Greetings Peter

June 3, 2006

RE: My 1.0 wish list

by EA Durbin

I just tested the latest Kidspiration install. The self extracting .exe extracts the Trial.exe file into windows/temp, and then complains about not having a program associated with Kid's Trial.exe. After traversing into the .wine/drive_c/windows/temp folder and typing Wine Kid's Trial.exe the program installed and ran just fine. >From: "Dan Kegel" <dank(a)kegel.com> >To: wine-devel <wine-devel(a)winehq.org> >Subject: My 1.0 wish list >Date: Fri, 2 Jun 2006 21:55:43 -0700 > >... is now at http://wiki.winehq.org/DanKegel > >I'm willing to focus some effort on these tasks, too, >so it's not just pie-in-the-sky wishing. > >

June 3, 2006

Re: DAZ Studio

by Andrew Neil Ramage

When I run the command, I get a Crash Detected dialog with the following text: DAZStudio.exe caused an EXCEPTION_ACCESS_VIOLATION in module <UNKNOWN> at 0073:42A66FF5 Andrew When the dragons grow too mighty To slay with pen or sword I grow weary of the battle And the storm I walk toward Madrigal by Rush (A Farewell to Kings, 1974) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jeff Latimer wrote: > Andrew, so far the uniscribe part looks like pretty much like I would > expect. What is the problem you are experiencing? > > Jeff > > Andrew Neil Ramage wrote: > >> After running winecfg and setting winver for DAZStudio.exe to XP, I >> get the following. >> >> andrew(a)apollo:~/Download/Windows> wine >> /home/andrew/.wine/drive_c/Program\ Files/DAZ/Studio/DAZStudio.exe >> fixme:imm:ImmReleaseContext (0x10020, 0x403cde30): stub >> fixme:imm:ImmReleaseContext (0xa00a2, 0x403cde30): stub >> fixme:imm:ImmReleaseContext (0x200aa, 0x403cde30): stub >> fixme:uniscribe:ScriptItemize L"DAZ|Studio can search for directories >> that\2028may contain content from other programs\2028that DAZ|Studio >> can read. Please indicate\2028which drives you want DAZ|Studio to >> search.\2028NOTE: On large drives or network drives\2028this operation >> can take several >> minutes.\4291",249,255,(nil),(nil),0x415ae8a4,0x415af0b0: semi-stub >> fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db70, 10, 10, >> 0x4232d1ac): semi-stub >> fixme:uniscribe:ScriptShape (0xac0, 0x4232a600, 0x4291db70, 10, 10, >> 0x4232d1ac): semi-stub >> fixme:uniscribe:ScriptPlace (0xac0, 0x4232a600, 0x4232ba40, >> L"'$=_6WXGLR", 10, 0x4232cea8, 0x4232d1ac, 0x4232bd2c): semi-stub >> fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db84, 1, 1, >> 0x4232d1d4): semi-stub >> fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba54, L"\0003", >> 1, 0x4232cebc, 0x4232d1d4, 0x4232bd54): semi-stub >> fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db86, 3, 3, >> 0x4232d1fc): semi-stub >> fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba56, L"FDQ", 3, >> 0x4232cebe, 0x4232d1fc, 0x4232bd58): semi-stub >> fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8c, 1, 1, >> 0x4232d224): semi-stub >> fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5c, L"\0003", >> 1, 0x4232cec4, 0x4232d224, 0x4232bd64): semi-stub >> fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8e, 6, 6, >> 0x4232d24c): semi-stub >> fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5e, L"VHDUFK", >> 6, 0x4232cec6, 0x4232d24c, 0x4232bd68): semi-stub >> fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9a, 1, 1, >> 0x4232d274): semi-stub >> fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6a, L"\0003", >> 1, 0x4232ced2, 0x4232d274, 0x4232bd80): semi-stub >> fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9c, 3, 3, >> 0x4232d29c): semi-stub >> fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6c, L"IRU", 3, >> 0x4232ced4, 0x4232d29c, 0x4232bd84): semi-stub >> fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba2, 1, 1, >> 0x4232d2c4): semi-stub >> fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba72, L"\0003", >> 1, 0x4232ceda, 0x4232d2c4, 0x4232bd90): semi-stub >> fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba4, 11, 11, >> 0x4232d2ec): semi-stub >> fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba74, >> L"GLUHFWRULHV", 11, 0x4232cedc, 0x4232d2ec, 0x4232bd94): semi-stub >> fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbba, 1, 1, >> 0x4232d314): semi-stub >> fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8a, L"\0003", >> 1, 0x4232cef2, 0x4232d314, 0x4232bdc0): semi-stub >> fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbbc, 4, 4, >> 0x4232d33c): semi-stub >> fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8c, L"WKDW", >> 4, 0x4232cef4, 0x4232d33c, 0x4232bdc4): semi-stub >> fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbc4, 1, 1, >> 0x4232d364): semi-stub >> fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba94, L"", 1, >> 0x4232cefc, 0x4232d364, 0x4232bdd4): semi-stub >> fixme:win:SetWindowTextA setting text "EAX=00006078 EBX=42A6810C >> ECX=415AF1D8 EDX=403DFDE0 ESI=4232BA94\nEDI=403DF9D8 EBP=415AF15C >> ESP=415AF144 EIP=42A66FF5 FLG=00210246\nCS=0073 DS=007B SS=007B >> ES=007B FS=1007 GS=0033" of other process window (nil) should not >> use SendMessage >> > > >

June 3, 2006

Re: Built-in iexplore

by Jonathan Ernst

Le vendredi 02 juin 2006 à 13:42 -0700, Brandon a écrit : > Daniel Skorka wrote: > > Oleksii Krykun <krikun(a)academy.kiev.ua.nospam> wrote: > > > $ wine iexplore > > > fixme:shdocvw:IEWinMain "" 1 > > > fixme:ole:CoResumeClassObjects stub > > > Could not load Mozilla. HTML rendering will be disabled. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > Where is aq problem? > > > > Guess. > > I get the same thing even though I have mozilla installed. I'm using > wine in 64-bit linux, though, so that probably has something to do with > it. You don't need mozilla, but the Mozilla activex control : http://source.winehq.org/mozactivex I don't know why shdocvw doesn't prompt the user to install it in this case though (so I'm CCing wine-devel and Jacek to see if something has to be changed in nsembed.c). Best regards. Jonathan Ernst

June 3, 2006

Re: Re: Re: Wine 1.0 Tasks

by fenix＠club-internet.fr

----Message d'origine---- >Date: Fri, 2 Jun 2006 21:27:53 +0200 >De: Lionel Ulmer <lionel.ulmer(a)free.fr> >A: Dan Kegel <dank(a)kegel.com> >Copie à: wine-devel(a)winehq.org, >Sujet: Re: Re: Wine 1.0 Tasks > >On Tue, May 30, 2006 at 05:32:26PM -0700, Dan Kegel wrote: >> On 5/30/06, Scott Ritchie <scott(a)open-vote.org> wrote: >> > > It might be, but the heavy hitters I know of who have taken a look at >> > > it in detail have concluded that an X change really is needed.] >> > >> > Is this really a problem? Another version of X is due out in about 4 >> > months (probably the earliest we could possibly see Wine 1.0), so why >> > can't we just help write an X extension to tackle the bug? >> >> Not really a problem. It'll just take some time to trickle out to the world. >> We may also have to get Nvidia and ATI on board so they can implement >> the extension in their drivers. > >And for it to be taken, I guess we would need to not only write the >extension, but a 'reference implementation' (I would guess in DRI / Mesa) >and get it approved by the FD.o people. > >But ohsix's idea to use 'real' X windows 'overlaid' over the single Wine X >window would be the easiest idea to investigate (because it would not only >fixes this issue but also the mutiple windows with multiple pixel formats >problem that the former 'extension' solution does not). > i thought the same idea. But investigation modifications in x11drv to permit wine x pixmaps access for wined3d/opengl will fix many problems (but not hthe multiple pixel formats) Anyway we must move some code of wined3d and opengl32 (GLX code, etc...) to x11drv as it permit : - to handle this problems without hacks (ie many ExtEscape) - to help macos-X to port wined3d and opengl (all specific cost must be on x11drv/qwartwdrv) > Lionel (in 'not even time to read wine-devel' mode :-) ) > Well, at least i take time for it :) (and reviewing the flood of d3d patches) Waiting for you for coding :p Regards, Raphael

June 3, 2006

Re: DAZ Studio

by Jeff Latimer

Andrew, so far the uniscribe part looks like pretty much like I would expect. What is the problem you are experiencing? Jeff Andrew Neil Ramage wrote: > After running winecfg and setting winver for DAZStudio.exe to XP, I > get the following. > > andrew(a)apollo:~/Download/Windows> wine > /home/andrew/.wine/drive_c/Program\ Files/DAZ/Studio/DAZStudio.exe > fixme:imm:ImmReleaseContext (0x10020, 0x403cde30): stub > fixme:imm:ImmReleaseContext (0xa00a2, 0x403cde30): stub > fixme:imm:ImmReleaseContext (0x200aa, 0x403cde30): stub > fixme:uniscribe:ScriptItemize L"DAZ|Studio can search for directories > that\2028may contain content from other programs\2028that DAZ|Studio > can read. Please indicate\2028which drives you want DAZ|Studio to > search.\2028NOTE: On large drives or network drives\2028this operation > can take several > minutes.\4291",249,255,(nil),(nil),0x415ae8a4,0x415af0b0: semi-stub > fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db70, 10, 10, > 0x4232d1ac): semi-stub > fixme:uniscribe:ScriptShape (0xac0, 0x4232a600, 0x4291db70, 10, 10, > 0x4232d1ac): semi-stub > fixme:uniscribe:ScriptPlace (0xac0, 0x4232a600, 0x4232ba40, > L"'$=_6WXGLR", 10, 0x4232cea8, 0x4232d1ac, 0x4232bd2c): semi-stub > fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db84, 1, 1, > 0x4232d1d4): semi-stub > fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba54, L"\0003", > 1, 0x4232cebc, 0x4232d1d4, 0x4232bd54): semi-stub > fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db86, 3, 3, > 0x4232d1fc): semi-stub > fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba56, L"FDQ", 3, > 0x4232cebe, 0x4232d1fc, 0x4232bd58): semi-stub > fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8c, 1, 1, > 0x4232d224): semi-stub > fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5c, L"\0003", > 1, 0x4232cec4, 0x4232d224, 0x4232bd64): semi-stub > fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8e, 6, 6, > 0x4232d24c): semi-stub > fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5e, L"VHDUFK", > 6, 0x4232cec6, 0x4232d24c, 0x4232bd68): semi-stub > fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9a, 1, 1, > 0x4232d274): semi-stub > fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6a, L"\0003", > 1, 0x4232ced2, 0x4232d274, 0x4232bd80): semi-stub > fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9c, 3, 3, > 0x4232d29c): semi-stub > fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6c, L"IRU", 3, > 0x4232ced4, 0x4232d29c, 0x4232bd84): semi-stub > fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba2, 1, 1, > 0x4232d2c4): semi-stub > fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba72, L"\0003", > 1, 0x4232ceda, 0x4232d2c4, 0x4232bd90): semi-stub > fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba4, 11, 11, > 0x4232d2ec): semi-stub > fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba74, > L"GLUHFWRULHV", 11, 0x4232cedc, 0x4232d2ec, 0x4232bd94): semi-stub > fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbba, 1, 1, > 0x4232d314): semi-stub > fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8a, L"\0003", > 1, 0x4232cef2, 0x4232d314, 0x4232bdc0): semi-stub > fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbbc, 4, 4, > 0x4232d33c): semi-stub > fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8c, L"WKDW", > 4, 0x4232cef4, 0x4232d33c, 0x4232bdc4): semi-stub > fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbc4, 1, 1, > 0x4232d364): semi-stub > fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba94, L"", 1, > 0x4232cefc, 0x4232d364, 0x4232bdd4): semi-stub > fixme:win:SetWindowTextA setting text "EAX=00006078 EBX=42A6810C > ECX=415AF1D8 EDX=403DFDE0 ESI=4232BA94\nEDI=403DF9D8 EBP=415AF15C > ESP=415AF144 EIP=42A66FF5 FLG=00210246\nCS=0073 DS=007B SS=007B > ES=007B FS=1007 GS=0033" of other process window (nil) should not > use SendMessage >

June 3, 2006

DAZ Studio

by Andrew Neil Ramage

After running winecfg and setting winver for DAZStudio.exe to XP, I get the following. andrew(a)apollo:~/Download/Windows> wine /home/andrew/.wine/drive_c/Program\ Files/DAZ/Studio/DAZStudio.exe fixme:imm:ImmReleaseContext (0x10020, 0x403cde30): stub fixme:imm:ImmReleaseContext (0xa00a2, 0x403cde30): stub fixme:imm:ImmReleaseContext (0x200aa, 0x403cde30): stub fixme:uniscribe:ScriptItemize L"DAZ|Studio can search for directories that\2028may contain content from other programs\2028that DAZ|Studio can read. Please indicate\2028which drives you want DAZ|Studio to search.\2028NOTE: On large drives or network drives\2028this operation can take several minutes.\4291",249,255,(nil),(nil),0x415ae8a4,0x415af0b0: semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db70, 10, 10, 0x4232d1ac): semi-stub fixme:uniscribe:ScriptShape (0xac0, 0x4232a600, 0x4291db70, 10, 10, 0x4232d1ac): semi-stub fixme:uniscribe:ScriptPlace (0xac0, 0x4232a600, 0x4232ba40, L"'$=_6WXGLR", 10, 0x4232cea8, 0x4232d1ac, 0x4232bd2c): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db84, 1, 1, 0x4232d1d4): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba54, L"\0003", 1, 0x4232cebc, 0x4232d1d4, 0x4232bd54): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db86, 3, 3, 0x4232d1fc): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba56, L"FDQ", 3, 0x4232cebe, 0x4232d1fc, 0x4232bd58): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8c, 1, 1, 0x4232d224): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5c, L"\0003", 1, 0x4232cec4, 0x4232d224, 0x4232bd64): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8e, 6, 6, 0x4232d24c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5e, L"VHDUFK", 6, 0x4232cec6, 0x4232d24c, 0x4232bd68): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9a, 1, 1, 0x4232d274): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6a, L"\0003", 1, 0x4232ced2, 0x4232d274, 0x4232bd80): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9c, 3, 3, 0x4232d29c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6c, L"IRU", 3, 0x4232ced4, 0x4232d29c, 0x4232bd84): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba2, 1, 1, 0x4232d2c4): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba72, L"\0003", 1, 0x4232ceda, 0x4232d2c4, 0x4232bd90): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba4, 11, 11, 0x4232d2ec): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba74, L"GLUHFWRULHV", 11, 0x4232cedc, 0x4232d2ec, 0x4232bd94): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbba, 1, 1, 0x4232d314): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8a, L"\0003", 1, 0x4232cef2, 0x4232d314, 0x4232bdc0): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbbc, 4, 4, 0x4232d33c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8c, L"WKDW", 4, 0x4232cef4, 0x4232d33c, 0x4232bdc4): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbc4, 1, 1, 0x4232d364): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba94, L"", 1, 0x4232cefc, 0x4232d364, 0x4232bdd4): semi-stub fixme:win:SetWindowTextA setting text "EAX=00006078 EBX=42A6810C ECX=415AF1D8 EDX=403DFDE0 ESI=4232BA94\nEDI=403DF9D8 EBP=415AF15C ESP=415AF144 EIP=42A66FF5 FLG=00210246\nCS=0073 DS=007B SS=007B ES=007B FS=1007 GS=0033" of other process window (nil) should not use SendMessage -- Andrew When the dragons grow too mighty To slay with pen or sword I grow weary of the battle And the storm I walk toward Madrigal by Rush (A Farewell to Kings, 1974) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

June 3, 2006

Re: To K&R or not

by Peter Beutner

James Hawkins schrieb: > On 6/2/06, Aneurin Price <wine(a)shadovald.dyndns.org> wrote: >> >> How about setting a standard that will be used in the repository, and >> providing the indent commands to set it that way, then indenting *every >> file* in the repository to that standard. Then every developer can use >> indent or whatever equivalent they prefer when they checkout, if they >> don't like the chosen style. >> > > Our coding standard is that there shall be no coding standard. As was > stated before, whoever creates the file, their style is the style that > should be used when anyone makes changes to that file. The question is in how far that really works in reality. Even when leaving such (imho) minor things like K&R or not, spaces after if or not,etc aside. Just look at the tabs vs. space issue: I don't really have a problem with both of them but mixing them is imo the worst thing that could happen. And things like this: (tabs = underscore, space = dots) ...if() { ______int foo; ______if() { ______.....do_something(); ......_____for() ......_____....do_somethingelse(); ______} ....} (and yes you really find things like this) are just UGLY and if you don't have the exact same tabsize settings like the author you get complete "garbage". Granted, I probably haven't even seen the majority of the source code and maybe I just found one of the few negative examples, but imho some kind of consensus here would be definitly a good thing. 4-space indention and using spaces instead of tabs already seems to be most used setting, so why not enforce it for everybody?

June 3, 2006

Re: How are we doing?

by Alexandre Julliard

Peter Beutner <p.beutner(a)gmx.net> writes: >> BTW Alexandre, can we preserve references to bug numbers in patch comments? > Indeed that would be nice. I'm not opposed to having bug number in the comments, but it has to be in addition to a proper explanation; the log must be understandable on its own without making reference to an external database. -- Alexandre Julliard julliard(a)winehq.org

June 3, 2006

Re: How are we doing?

by Peter Beutner

Vitaliy Margolen schrieb: > Friday, June 2, 2006, 6:27:18 AM, EA Durbin wrote: >>> There is precious little "Why" in the comments of a lot of projects - Why >>> does this function exist, why would I call it, why does it return what it >>> does, etc. >>> >>> BS comments like those within the function don't help, obviously - but >>> sometimes a comment block describing WHY a given chunk of code does what it >>> does would be nice. >>> > I don't see any problems here. If anyone needs to know _why_ some function does > X - they should look on msdn. Only that there is no guarantee that the information in MSDN will stay forever ;) > BTW Alexandre, can we preserve references to bug numbers in patch comments? Indeed that would be nice.

June 3, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > How 'bout we also implement remote thread creation, and create > a temporary service thread to service a remote memory allocation request? > That would give the thread context you say is required. Yes that's a possibility, we need support for creating remote threads in any case. But of course creating a remote thread correctly is a non-trivial problem too... -- Alexandre Julliard julliard(a)winehq.org

June 3, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > Are you willing to accept a patch which makes some common use > cases work well, but does not address others? If it's a solution that can be expanded later on to cover the other cases, yes, but not if it's a dead-end. -- Alexandre Julliard julliard(a)winehq.org

June 3, 2006

Re: How are we doing?

by n0dalus

On 6/3/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > I don't see any problems here. If anyone needs to know _why_ some function does > X - they should look on msdn. Also it would really help look at the patch itself > that _does_ explain what the patch is for. And might even link to the bug #. > I think it's good to have seperate documentation to msdn. MSDN has a lot of inaccurate information and regularly discards information about older functions. What better place to put this seperate information, provided it is not too wordy, than in the source code? n0dalus.

June 3, 2006

Re: How are we doing?

by Vitaliy Margolen

Friday, June 2, 2006, 12:20:58 PM, EA Durbin wrote: >>From: Juan Lang <juan_lang(a)yahoo.com> >>To: EA Durbin <ead1234(a)hotmail.com> >>CC: wine-devel(a)winehq.org >>Subject: Re: How are we doing? >>Date: Fri, 2 Jun 2006 10:56:15 -0700 (PDT) >> >> > Especially the code that is responded to as , I know it's a mess to >> > look at, but I didn't write it. >> >>Can you give us examples? >> >>Mostly Wine attempts to follow how Windows works, so MSDN provides a lot >>of the documentation. This is becoming increasingly true, with kernel32 >>being implemented on top of ntdll. >> >>There are bits that are hard to understand, certainly, and some areas >>could use some comments. Unfortunately sometimes the lack of comments >>demonstrates a lack of understanding, but the code works for someone, >>somewhere, so we're mostly afraid to touch it until some brave soul comes >>along. >> >>For example, SHFileOperation was a complete mess until James fixed it up. >> >>Another example is user32. It's impossible to document (in English) what >>it's supposed to be doing. For this, and many other cases, a good >>regression test suite is the best documentation: it tells you what's >>expected, so if you go mucking around you have checks against introducing >>regressions. >> >>I know you've been working with msi lately. The fact that you've figured >>out where the problem is indicates to me that it's adequately commented, >>even if the learning curve is still a bit steep. >> >>Patches to add API comments for the Wine API guide >>(http://source.winehq.org/WineAPI/ ) are always welcome. Patches to >>document dodgy bits of code may or may not be accepted, but regression >>tests to justify dodgy bits of code are happily accepted too. >>http://source.winehq.org/WineAPI/ >> >>--Juan >> >>__________________________________________________ >>Do You Yahoo!? >>Tired of spam? Yahoo! Mail has the best spam protection around >>http://mail.yahoo.com > I'm just nitpicky I guess. If I use K & R style, or not enough white space, > or don't align things perfectly at work my boss will kindly print off a copy > of the companies acceptable coding standards policy and bring it over. I > guess I'm just used to having things that way, and the shifting coding style > and lack of comments in places in wine makes the learning curve steeper than > it needs to be for beginning wine developers. > Just my 2 cents as a beginning wine developer. Oh yeah I see your pain right here... Even hard to respond in the well accepted format, not in a business ignorant style - "My comments more important so I'll put then on top." Vitaliy

June 3, 2006

Re: How are we doing?

by Vitaliy Margolen

Friday, June 2, 2006, 6:27:18 AM, EA Durbin wrote: >>There is precious little "Why" in the comments of a lot of projects - Why >>does this function exist, why would I call it, why does it return what it >>does, etc. >> >>BS comments like those within the function don't help, obviously - but >>sometimes a comment block describing WHY a given chunk of code does what it >>does would be nice. >> I don't see any problems here. If anyone needs to know _why_ some function does X - they should look on msdn. Also it would really help look at the patch itself that _does_ explain what the patch is for. And might even link to the bug #. BTW Alexandre, can we preserve references to bug numbers in patch comments? That would be an ultimate explanation to what most questionable code does. > Exactly my point. > As in the case of wine, you must try to figure out what a block of code > does, then that block of code calls existing wine functions that you've > never seen before in your life. So then you have to trace that back to find > out what the already implemented function does, and look through the code to > it, because there is no documentation for it either, then it calls another > function, so go ahead and trace back through the code for it too to find out And how that would be different from reading comments to each function? Or do you expect to have description of what each function with variation of the any other function can do? Vitaliy

June 3, 2006

RE: My 1.0 wish list

by EA Durbin

I guess it's not installing after all, the installer menu says install completed, but the log code says differently. fixme:msi:ACTION_HandleStandardAction unhandled standard action L"RemoveFolders"err:cabinet:FDICopy PFDI_OPEN returned zero for c:\Program Files\Common Files\Java\Update\Base Images\jdk1.5.0.b64\patch-jdk1.5.0_07.b03\\jo150000.cab. err:msi:extract_cabinet_file FDICopy failed err:msi:ACTION_InstallFiles Unable to ready media That message looks eerily familiar, seems the same bug that plagues the America's Army installer also plagues that of J2SE. Caused by the query in ready_media_for_file in files.c returning the wrong results from the query "SELECT * FROM Media WHERE LastSequence >= file-Sequence ORDER BY LastSequence". Fix this bug and we'll kill 2 birds with one stone. >From: "EA Durbin" <ead1234(a)hotmail.com> >To: dank(a)kegel.com >CC: wine-devel(a)winehq.org >Subject: RE: My 1.0 wish list >Date: Sat, 03 Jun 2006 00:54:31 -0500 > >I just tested J2SE update 7 offline installation from sun and it installed >with no problems. Are we trying to install netbeans or something too that's >crashing? >I'm using the latest cvs version of wine. > >>From: "Dan Kegel" <dank(a)kegel.com> >>To: wine-devel <wine-devel(a)winehq.org> >>Subject: My 1.0 wish list >>Date: Fri, 2 Jun 2006 21:55:43 -0700 >> >>... is now at http://wiki.winehq.org/DanKegel >> >>I'm willing to focus some effort on these tasks, too, >>so it's not just pie-in-the-sky wishing. >> >> > > > >

June 3, 2006

RE: My 1.0 wish list

by EA Durbin

I just tested J2SE update 7 offline installation from sun and it installed with no problems. Are we trying to install netbeans or something too that's crashing? I'm using the latest cvs version of wine. >From: "Dan Kegel" <dank(a)kegel.com> >To: wine-devel <wine-devel(a)winehq.org> >Subject: My 1.0 wish list >Date: Fri, 2 Jun 2006 21:55:43 -0700 > >... is now at http://wiki.winehq.org/DanKegel > >I'm willing to focus some effort on these tasks, too, >so it's not just pie-in-the-sky wishing. > >

June 3, 2006

Re: How are we doing?

by Dmitry Timoshkov

"Jeremy White" <jwhite(a)codeweavers.com> wrote: >> grep Bestefich documentation/ChangeLog.ALPHA | wc -l >> 0 >> >> grep Bestefich ChangeLog | wc -l >> 0 >> > > And this is exactly the kind of comment and attitude > that pushes people away from being Wine developers. > > This was a thread that asked the question: > What would get more developers interested in Wine? > > A number of people said: > "The code is too hard to read because it's > completely unmovitated and uncommented." > > Dismissing their input because they've never contributed > code is exactly the wrong approach; if we're talking > about getting new developers, then their impressions > are particularly valuable. I'd suggest to return and carefully reread the whole paragraph I've quoted and replied to. It has nothing to do with a constructive talk about commenting the code, instead it's full of insults and hits. I'm not even talking about using the word "foreigners" for the contributors to the open source international project. I'd call the foreigners that kind of people who sends messages like the one I replied to, clearly that people absolutely don't understand what they are talking about. I apologize for my harsh wording, but I just can't stay aside when I see accusations like that one. When people are interested to contribute code they ask *technical* questions. -- Dmitry.

June 3, 2006

RE: My 1.0 wish list

by EA Durbin

What is broken in MingW installer?, Upon testing I was able to install 5.0.2 Mingw just fine, and selected all of the components and it installed fine. I also was able to install gdb, as the bug suggests you're not able. >From: "Dan Kegel" <dank(a)kegel.com> >To: wine-devel <wine-devel(a)winehq.org> >Subject: My 1.0 wish list >Date: Fri, 2 Jun 2006 21:55:43 -0700 > >... is now at http://wiki.winehq.org/DanKegel > >I'm willing to focus some effort on these tasks, too, >so it's not just pie-in-the-sky wishing. > >

June 3, 2006

RE: My 1.0 wish list

by EA Durbin

I can help debug some of these, and maybe contribute to the code/test cases. I haven't coded much in C in the last few years, I took some in college, but I've never used it yet in my career path, but I'm working on refreshing my memory, and working on trying to understand the most commonly used functions called in wine. >From: "Dan Kegel" <dank(a)kegel.com> >To: wine-devel <wine-devel(a)winehq.org> >Subject: My 1.0 wish list >Date: Fri, 2 Jun 2006 21:55:43 -0700 > >... is now at http://wiki.winehq.org/DanKegel > >I'm willing to focus some effort on these tasks, too, >so it's not just pie-in-the-sky wishing. > >

June 3, 2006

My 1.0 wish list

by Dan Kegel

... is now at http://wiki.winehq.org/DanKegel I'm willing to focus some effort on these tasks, too, so it's not just pie-in-the-sky wishing.

June 2, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Vitaliy Margolen

Friday, June 2, 2006, 9:33:30 PM, Dan Kegel wrote: > On 6/2/06, Dan Kegel <dank(a)kegel.com> wrote: >> > You need to have a thread waiting one way or another, since you need >> > to perform operations on the client side that require a thread >> > context. No, it's not an easy problem to solve, that's why it has not >> > been done yet... >> >> Are you willing to accept a patch which makes some common use >> cases work well, but does not address others? > Oh, heck, I guess we can keep thinking about it even if you do insist > on a full-on solution. > How 'bout we also implement remote thread creation, and create > a temporary service thread to service a remote memory allocation request? > That would give the thread context you say is required. > - Dan That would be wonderful actually. It seems that some new stile copy-protection technics include use of injected threads. Also that would help properly implementing braking any process for debugging. So the real use of this would be to support all sorts of debuggers - they all use all these functions on other processes. Vitaliy

June 2, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Dan Kegel

On 6/2/06, Dan Kegel <dank(a)kegel.com> wrote: > > You need to have a thread waiting one way or another, since you need > > to perform operations on the client side that require a thread > > context. No, it's not an easy problem to solve, that's why it has not > > been done yet... > > Are you willing to accept a patch which makes some common use > cases work well, but does not address others? Oh, heck, I guess we can keep thinking about it even if you do insist on a full-on solution. How 'bout we also implement remote thread creation, and create a temporary service thread to service a remote memory allocation request? That would give the thread context you say is required. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 2, 2006

Re: How are we doing?

by Jeff Latimer

Matt Finnicum wrote: > > Also, sometimes it's not obvious why a function is called. A comment > like "Call funcResetStatusVariables because the above code triggers a > redraw which can break them" would save a new developer twenty minutes > of "But why update them THERE?! Does my code have to do that?". > We seem to have a policy of not accepting comments in exisiting code. If I add comments to existing code that clear up a mystery I have found they are nicely deleted. A pity as the comments would help me next time I am in the area if no one else. Jeff

June 2, 2006

Re: How are we doing?

by Matt Finnicum

>From the viewpoint of a new developer (Summer of Code), having a few "The purpose of this function" comments would have been / still would be very useful! It's painfully having to figure out what exactly a function does, that calls five other functions that you have to look into, which each call another cryptically named function. Also, sometimes it's not obvious why a function is called. A comment like "Call funcResetStatusVariables because the above code triggers a redraw which can break them" would save a new developer twenty minutes of "But why update them THERE?! Does my code have to do that?". --Matt

June 2, 2006

Re: [Darwine] Quartz driver

by anarkhos＠vfemail.net

At 10:48 PM +0200 5/31/06, Emmanuel Maillard wrote: >Hi all, > >Quartz driver is up to date on Darwine CVS. Ah, so you managed to get bitmaps working. I attempted it, but was getting confused with the undocumented setbitmap behavior in WINE (the bitmaps were being loaded correctly, but weren't being copied to the frame buffer). >Winemine is playable on both PPC and x86 but it look fine only on PPC, x86 driver suffer strange rendering bugs. I had weird rendering bugs related to endian issues--displaying little endian bitmaps on my PPC mac. I didn't pursue it further because I assumed it would be cleared up when running on x86. >See wiki for building the driver : http://wiki.opendarwin.org/index.php/Darwine:quartzdrv >I will update wiki soon with issues and todo for Quartz driver. I'll check this out later hopefully. Do the Win32 title bar buttons respond? IIRC there is a callback function which could easily trigger the analogous OS X events (well, at least minimize).

June 2, 2006

Re: To K&R or not

by James Hawkins

On 6/2/06, Aneurin Price <wine(a)shadovald.dyndns.org> wrote: > > How about setting a standard that will be used in the repository, and > providing the indent commands to set it that way, then indenting *every > file* in the repository to that standard. Then every developer can use > indent or whatever equivalent they prefer when they checkout, if they > don't like the chosen style. > Our coding standard is that there shall be no coding standard. As was stated before, whoever creates the file, their style is the style that should be used when anyone makes changes to that file. Concerning the automatic source indenter, I know I would be peeved if i checked my code back out and it was changed to a style I don't like. There are way too many different styles of coding out there, and each developer has a right to like his or her own style, and we shouldn't force one specific style on anyone. http://www.winehq.org/site/docs/winedev-guide/style-notes -- James Hawkins

June 2, 2006

Re: To K&R or not

by Aneurin Price

> That said, I don't care what people do, I can read both... > In my perfect world though, my SCM client would convert source code to > my preferred format on checkout, and to whatever universal format the > repository uses on checkin. Ho hum... > > (Personally I hate K&R because I want to be able to see the braces line up vertically, else I find it hard to read. Of course, that's an aside since, not being a Wine developer, it's a little pointless saying my opinion; I just happen to like doing so anyway :P) Anyway, the point: How about setting a standard that will be used in the repository, and providing the indent commands to set it that way, then indenting *every file* in the repository to that standard. Then every developer can use indent or whatever equivalent they prefer when they checkout, if they don't like the chosen style. By specifying a standard used by the repository it means that submitters can reformat their patches at submission time to avoid vast amounts of no-op changes caused by different formatting styles. This could be done automatically via an aliased `cvs diff` command, or whatever. Alternatively each patch could be considered by a script (which really wouldn't have to be at all complex) which tries applying it, reformats it appropriately, generates a more appropriate patch, then unapplies it. This would make the process transparent to most developers, with the cost of more processing needing to be done at submission time - perhaps that would be unacceptable; I've no idea what kind of resources are available compared to what it would take. Okay, I don't really expect this suggestion to be taken seriously since it involves modifying every file in the repository once, and potentially every patch, but I seriously think that it's an issue worth considering. Does anybody else think that it would be a feature that might really be used if it were implemented in <SCM of choice>?

June 2, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Dan Kegel

On 6/2/06, Alexandre Julliard <julliard(a)winehq.org> wrote: > > How about this: we combine the original sychronous approach > > with the small preallocated cache as a fallback for when > > no threads are waiting? > > You need to have a thread waiting one way or another, since you need > to perform operations on the client side that require a thread > context. No, it's not an easy problem to solve, that's why it has not > been done yet... Are you willing to accept a patch which makes some common use cases work well, but does not address others? If so, we can continue. Otherwise we'll have to wash our hands and walk away screaming. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 2, 2006

Re: How are we doing?

by Uwe Bonnes

>>>>> "Michael" == Michael Stefaniuc <mstefani(a)redhat.com> writes: Michael> P.S.: Let the flame war begin. ;) Isn't it already raginh ;-) -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

June 2, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > How about this: we combine the original sychronous approach > with the small preallocated cache as a fallback for when > no threads are waiting? You need to have a thread waiting one way or another, since you need to perform operations on the client side that require a thread context. No, it's not an easy problem to solve, that's why it has not been done yet... -- Alexandre Julliard julliard(a)winehq.org

June 2, 2006

Re: Wine 1.0 Tasks

by Alexandre Julliard

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > But ohsix's idea to use 'real' X windows 'overlaid' over the single Wine X > window would be the easiest idea to investigate (because it would not only > fixes this issue but also the mutiple windows with multiple pixel formats > problem that the former 'extension' solution does not). That can't work, unless you want to go back to the old window management implementation; but then you'll have to volunteer to solve all the painting bugs yourself, I'm not doing this a second time ;-) -- Alexandre Julliard julliard(a)winehq.org

June 2, 2006

Re: Shell integration idea

by Mikołaj Zalewski

Alexandre Julliard wrote: >I think using COM for that sort of thing is overkill. > If we want to allow multiple implementations then using a structure with callback functions is probably the easiest way. If we are using structures with callback functions then why not to make it COM interfaces - IMHO the overhead of adding the QueryInterface, AddRef, Release is relatively small and we obtain structures with which probably most of developpers are more of less familliar. > Besides, you >most likely want to put all of that in the explorer process, and >communicate with shell32 using the same protocol that Microsoft is >using, like we do already for the system tray. > > For the Trash I don't know if there is any protocol. I've placed a DELETE security audit on a file and it was the application trashing the file that triggered it - so it seems Windows also doesn't need to communicate with the explorer. For things like file associations, to maintain compatibility we will need to keep the settings in the registry. What we can do is to mirror the changes to the Linux database. That's a feature that is not present in Windows so we can choose a protocol. Mikolaj Zalewski

June 2, 2006

Freetype configure checks are backward

by Gerald Pfeifer

I believe the Freetype configure checks are backward. First we check for the library being present, and only then do we check for the freetype-config problem: AC_SUBST(FREETYPELIBS,"") AC_SUBST(FREETYPEINCL,"") AC_CHECK_LIB(freetype,FT_Init_FreeType,ft_lib=yes,ft_lib=no,$X_LIBS) if test "$ft_lib" = "no" then wine_cv_msg_freetype=no else AC_CHECK_PROG(ft_devel,freetype-config,freetype-config,no) This fails to work when Freetype is installed somewhere outside of /usr/ such as /usr/local/ with /usr/local/bin in the path. freetype-config would of course know where to look for the library, but we perform the check for the library first, without taking the output of freetype-config into concern. Wouldn't it make sense to revert these two changes? Gerald

June 2, 2006

Re: Missing LeaveCriticalSection on error paths (found by Smatch).

by Michael Stefaniuc

Michael Stefaniuc wrote: > can somebody more familiar with this code confirm that on the error > paths the CriticalSection should be released? I'm not sure about it as > the function is supposed to keep the lock held when exiting without > error; there is a d3ddevice_unlock_update() function that releases the > lock. Asked Lionel Ulmer on irc and the patch is correct. But according to Stefan Dösinger that code will be replaced by his code "in the next couple of days". bye michael > --- > > dlls/ddraw/device_opengl.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > dd0b9b20d26984ae408c1a7727323a08d44e0d95 > diff --git a/dlls/ddraw/device_opengl.c b/dlls/ddraw/device_opengl.c > index d19996e..4c663a6 100644 > --- a/dlls/ddraw/device_opengl.c > +++ b/dlls/ddraw/device_opengl.c > @@ -3775,10 +3775,12 @@ static void d3ddevice_lock_update(IDirec > buffer_color = GL_BGRA; > } else { > ERR(" unsupported pixel format at device locking.\n"); > + LeaveCriticalSection(&(d3d_dev->crit)); > return; > } > } else { > ERR(" unsupported pixel format at device locking - alpha on frame buffer.\n"); > + LeaveCriticalSection(&(d3d_dev->crit)); > return; > } > > > > ------------------------------------------------------------------------ > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

June 2, 2006

Re: Re: Wine 1.0 Tasks

by Wino Rojo

Lionel, Where can I learn more about ohsix's idea (i.e. thread in which mail list)? Thanks, W. >From: Lionel Ulmer <lionel.ulmer(a)free.fr> >To: Dan Kegel <dank(a)kegel.com> >CC: wine-devel(a)winehq.org, "fenix(a)club-internet.fr" ><fenix(a)club-internet.fr>,scott(a)open-vote.org >Subject: Re: Re: Wine 1.0 Tasks >Date: Fri, 2 Jun 2006 21:27:53 +0200 > >But ohsix's idea to use 'real' X windows 'overlaid' over the single Wine X >window would be the easiest idea to investigate (because it would not only >fixes this issue but also the mutiple windows with multiple pixel formats >problem that the former 'extension' solution does not). > > Lionel (in 'not even time to read wine-devel' mode :-) ) > >-- > Lionel Ulmer - http://www.bbrox.org/ > > _________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

June 2, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Dan Kegel

On 6/2/06, Alexandre Julliard <julliard(a)winehq.org> wrote: > > OK, new plan: how about we preallocate a memory > > area just big enough for the common case, with the > > structures all set up, and let the server hand it > > out to the first process to ask for it? I don't think > > it needs to be very big. > > Well, that may work for your specific problem, but it's clearly not an > acceptable general solution. How about this: we combine the original sychronous approach with the small preallocated cache as a fallback for when no threads are waiting? If that's not good enough, what (short of a Linux kernel module) might do? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 2, 2006

Re: Re: Wine 1.0 Tasks

by Lionel Ulmer

On Tue, May 30, 2006 at 05:32:26PM -0700, Dan Kegel wrote: > On 5/30/06, Scott Ritchie <scott(a)open-vote.org> wrote: > > > It might be, but the heavy hitters I know of who have taken a look at > > > it in detail have concluded that an X change really is needed.] > > > > Is this really a problem? Another version of X is due out in about 4 > > months (probably the earliest we could possibly see Wine 1.0), so why > > can't we just help write an X extension to tackle the bug? > > Not really a problem. It'll just take some time to trickle out to the world. > We may also have to get Nvidia and ATI on board so they can implement > the extension in their drivers. And for it to be taken, I guess we would need to not only write the extension, but a 'reference implementation' (I would guess in DRI / Mesa) and get it approved by the FD.o people. But ohsix's idea to use 'real' X windows 'overlaid' over the single Wine X window would be the easiest idea to investigate (because it would not only fixes this issue but also the mutiple windows with multiple pixel formats problem that the former 'extension' solution does not). Lionel (in 'not even time to read wine-devel' mode :-) ) -- Lionel Ulmer - http://www.bbrox.org/

June 2, 2006

Re: How are we doing?

by Michael Stefaniuc

EA Durbin wrote: >> K&R style brack placements > > > was what i was referring to when I commented about coding style. They > are an eyesore and make things difficult to read. Oh, NO NO NO. K&R style IS the one and only true pure C style. As mutch as GNU did good work for OSS they did very wrong with the GNU coding standard. Especialy with the placement of the braces. Just read the Chapter 3 "Placing Braces" from the Linux Kernel CodingStyle. I quote: "Also, note that this brace-placement also minimizes the number of empty (or almost empty) lines, without any loss of readability. Thus, as the supply of new-lines on your screen is not a renewable resource (think 25-line terminal screens here), you have more empty lines to put comments on." ^^^ See more place for comments and we all agreed that more comments are good! bye michael P.S.: Let the flame war begin. ;) > >> A number of people said: >> "The code is too hard to read because it's >> completely unmovitated and uncommented." -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

June 2, 2006

Re: How are we doing? (documentation + regression tests)

by Detlef Riekenberg

Am Freitag, den 02.06.2006, 08:03 -0500 schrieb Jeremy White: > But there are plenty of places in Wine where the code does > something screwball or out of the ordinary (hell, the API > itself is screwball), and those places deserve more comments. IMHO, more comment's help to teach someone, who read the code, what a Function does. Many of my Patches add the missing WineAPI - Documentation, but the overall API Documentation - Status is still to low. We can of course add the same Type of documentation for internal Functions. Example: http://source.winehq.org/source/dlls/winspool.drv/info.c#L214 Another big Place to teach someone what a Function does, are the regression tests. We are missing a lot of tests. Example: After a comment by Alexandre about my recent patch, i read again our WineAPI-Guide and MSDN. Both document's say the same, but our implementation is different. The affected Function is called only 3 times in our regression tests (WideCharToMultiByte). -- By By ... ... Detlef

June 2, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > OK, new plan: how about we preallocate a memory > area just big enough for the common case, with the > structures all set up, and let the server hand it > out to the first process to ask for it? I don't think > it needs to be very big. Well, that may work for your specific problem, but it's clearly not an acceptable general solution. -- Alexandre Julliard julliard(a)winehq.org

June 2, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Dan Kegel

On 6/2/06, Alexandre Julliard <julliard(a)winehq.org> wrote: > > Why isn't a call to mmap enough? > > You need to build the proper structures on the client side, just like > a normal VirtualAlloc would, otherwise the process won't know about > that memory area. OK, new plan: how about we preallocate a memory area just big enough for the common case, with the structures all set up, and let the server hand it out to the first process to ask for it? I don't think it needs to be very big. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 2, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > On 6/2/06, Alexandre Julliard <julliard(a)winehq.org> wrote: >> The problem here is that you don't control at what point you interrupt >> the process, so you can't do anything in it except system calls, and >> that won't be enough. > > Why isn't a call to mmap enough? You need to build the proper structures on the client side, just like a normal VirtualAlloc would, otherwise the process won't know about that memory area. -- Alexandre Julliard julliard(a)winehq.org

June 2, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Dan Kegel

On 6/2/06, Alexandre Julliard <julliard(a)winehq.org> wrote: > The problem here is that you don't control at what point you interrupt > the process, so you can't do anything in it except system calls, and > that won't be enough. Why isn't a call to mmap enough? (We're trying to support techniques like the one documented in http://msdn.microsoft.com/library/en-us/dnwinforms/html/autowforms.asp for retrieving control names and captions from another process, if that helps.) > Another problem is that you make the server wait > on the client to execute the code, and that's a big no-no, the server > can't trust the client. Fine, he can move the wait to the client, that's no problem. - Dan

June 2, 2006

Re: How are we doing?

by Juan Lang

--- EA Durbin <ead1234(a)hotmail.com> wrote: > If I use K & R style, or not enough white space, > or don't align things perfectly at work my boss will kindly print off a > copy of the companies acceptable coding standards policy and bring it > over. Ah, so it's the lack of a defined style guideline that's the problem? That got me too back in the beginning. The Official Wine Code Style is something like this: 1. New file: whatever the author wants 2. Existing file: whatever others did This takes some getting used to, and since 2. isn't strictly enforced, we sometimes end up with colliding styles. Only one time that I remember did we manage to sneak in a bunch of formatting changes (into shell32, which was a real mess of conflicting styles.) I guess that could be documented better, though a quick google turns up statements to that effect: http://www.kerneltraffic.org/wine/wn20010305_85.html#4 http://www.winehq.org/pipermail/wine-devel/2004-July/028483.html It's also in the developer guide, though a bit buried: http://winehq.org/site/docs/winedev-guide/style-notes The fact that I couldn't find the darn thing quickly is a problem ;) --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

June 2, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Alexandre Julliard

tkho(a)ucla.edu writes: > I ran across the need to do memory allocations across processes and came upon > Alexander Yaworsky's patch at > http://www.winehq.org/pipermail/wine-devel/2004-September/029953.html and took > a different approach. Instead of waiting for the target process to check a fd, > I changed the implementation to use ptrace to interrupt the target process and > execute code in kernel32 that does an mmap/munmap. The problem here is that you don't control at what point you interrupt the process, so you can't do anything in it except system calls, and that won't be enough. Another problem is that you make the server wait on the client to execute the code, and that's a big no-no, the server can't trust the client. -- Alexandre Julliard julliard(a)winehq.org

June 2, 2006

Re: test case for MSI problem in America's Army installer

by Dan Kegel

I think you can just compile and run it with visual C++ as a standalone app, with the right commandline options to the compiler. Let's see: try the instructions here: http://www.winehq.com/hypermail/wine-devel/2005/05/0865.html You can also build with the wine build system and then run the executable with a single commandline option giving the name of the test to run. Better ask on wine-devel, I have to run. On 6/2/06, EA Durbin <ead1234(a)hotmail.com> wrote: > How does one use the test application in the msi/tests folder? > > I know you run it with wine, but without looking through all of the code in > the application to determine this could you maybe advise me what it expects > for arguments, or how to work with it? > > Do you pass it an misdatabase, and a DB argument, or how does this utility > work? > > I don't usually hack in C, but im somewhat capable. I could write a mean > Hello World Application back in college. My day usually consists of parsing > data with PERL, but that doesn't mean I can't pick up C again. > > I'd appreciate it if you focused some energy on it, but I would also like to > know how it works so I can contribute in the future. > > > >From: "Dan Kegel" <dank(a)kegel.com> > >To: wine-devel <wine-devel(a)winehq.org> > >Subject: re: test case for MSI problem in America's Army installer > >Date: Fri, 2 Jun 2006 07:06:30 -0700 > > > >Mike M. wrote: > >>>>[America's Army install crashes, see > >>>>http://bugs.winehq.org/show_bug.cgi?id=5139 ] > >>> > >>>This is as close as I will be able to come to including a test case, as > >>>this is how I obtained my results. > >> > >>If you want me to fix the problem, please submit a regression test to > >>wine-patches with a todo_wine{} around the code that doesn't work. > > > >If that's too hard for EA (he admits he's not a C hacker), maybe > >I can focus some energy on it... > >- Dan > > > > > > > -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 2, 2006

Re: Shell integration idea

by Alexandre Julliard

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > The main idea is not to hard-code one implementation of things like > the Trash into shell32 - not everything is standardized by the > freedesktop and even if it would this might not work on other systems > like MacOS X. We should allow for many implementations. The correct > one is loaded depending on a registry settings (so that a winecfg > entry can be added). My implementation uses COM objects as it's > standard dlls provides support for such tasks. Currently there is one > interface (IWineShellIntegration) that acts as a factory for > specialized objects. That could also be implemented using COM > Aggregation - when we do that we could use QueryInterface instead of > GetIntegrationObejct. I think using COM for that sort of thing is overkill. Besides, you most likely want to put all of that in the explorer process, and communicate with shell32 using the same protocol that Microsoft is using, like we do already for the system tray. -- Alexandre Julliard julliard(a)winehq.org

June 2, 2006

Re: winedbg: newbie question (sorry...)

by Robert Shearman

Molle Bestefich wrote: > Hello > > Carsten Niehaus (cniehaus(a)gmx.de) over on wine-users gets a page fault > when he tries to print with this app: > http://www.learn-line.nrw.de/angebote/gefahrstoffdb/Gefahrstoffe.zip > > He's posted a backtrace: > >> fixme:commdlg:PRINTDLG_SetUpPrinterListComboA Can't find '(null)' in >> printer list so trying to find default >> wine: Unhandled page fault on write access to 0x0000002e at address >> 0x7f6a2540 (thread 0009), starting debugger... >> Backtrace: >> =>1 0x7f6a2540 PRINTDLG_WMCommandA+0x619 in comdlg32 (0x7f6a2540) >> 2 0x7f6a2fb6 in comdlg32 (+0x32fb6) (0x7f6a2fb6) > > [snip!] > >> 0x7f6a2540 PRINTDLG_WMCommandA+0x619 in comdlg32: movw %ax,0x2e(%edx) > > > I'm slightly cli-debugger-clueless, so could one of you guys please > tell me how to convert this: > > PRINTDLG_WMCommandA+0x619 > > into a proper line number reference to the source file? If you don't strip comdlg32 then winedbg will pick up the debug information from the .dll.so and give you a filename and line number. So tell the user to install a build with debug information. -- Rob Shearman

June 2, 2006

Re: How are we doing?

by EA Durbin

I'm just nitpicky I guess. If I use K & R style, or not enough white space, or don't align things perfectly at work my boss will kindly print off a copy of the companies acceptable coding standards policy and bring it over. I guess I'm just used to having things that way, and the shifting coding style and lack of comments in places in wine makes the learning curve steeper than it needs to be for beginning wine developers. Just my 2 cents as a beginning wine developer. >From: Juan Lang <juan_lang(a)yahoo.com> >To: EA Durbin <ead1234(a)hotmail.com> >CC: wine-devel(a)winehq.org >Subject: Re: How are we doing? >Date: Fri, 2 Jun 2006 10:56:15 -0700 (PDT) > > > Especially the code that is responded to as , I know it's a mess to > > look at, but I didn't write it. > >Can you give us examples? > >Mostly Wine attempts to follow how Windows works, so MSDN provides a lot >of the documentation. This is becoming increasingly true, with kernel32 >being implemented on top of ntdll. > >There are bits that are hard to understand, certainly, and some areas >could use some comments. Unfortunately sometimes the lack of comments >demonstrates a lack of understanding, but the code works for someone, >somewhere, so we're mostly afraid to touch it until some brave soul comes >along. > >For example, SHFileOperation was a complete mess until James fixed it up. > >Another example is user32. It's impossible to document (in English) what >it's supposed to be doing. For this, and many other cases, a good >regression test suite is the best documentation: it tells you what's >expected, so if you go mucking around you have checks against introducing >regressions. > >I know you've been working with msi lately. The fact that you've figured >out where the problem is indicates to me that it's adequately commented, >even if the learning curve is still a bit steep. > >Patches to add API comments for the Wine API guide >(http://source.winehq.org/WineAPI/ ) are always welcome. Patches to >document dodgy bits of code may or may not be accepted, but regression >tests to justify dodgy bits of code are happily accepted too. >http://source.winehq.org/WineAPI/ > >--Juan > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com

June 2, 2006

Re: Shell integration idea

by Mikołaj Zalewski

>I think the general approach is good. > >The way you handle the built in implementation seems odd to me. I think >setting the registry key to make the freedesktop.org version as the default >would be good enough. > > If we don't have built-in trash etc. objects then when we add a new object we will require all the implementations have it, with no backward compatibility. However this should not be a big problem as the freedesktop.org implementation can be kept up-to-date with shell32 and the other implementation can fallback to it if they don't support a specific object. >I'm not convinced we need IWineShellIntegration. I think it would be >cleaner to directly create an IWineTrash object. > > If we integrate more closely with the desktop environments we may need to have one central object that will know that e.g. KDE 3.4 uses the freedesktop.org Trash but KDE 3.3 has it's own Trash implementation. If we read the Trash CLSID from the registry such an implementation would require creating proxy classes or hacks in the class factory. Also by storing only one CLSID we don't have a problem which implementation to use if a new kind of objects is introduced. Of course when we use COM aggregation instead of a factory pattern we will have all the interfaces visible under one CLSID so we will be able to construct a IWineTrash directly with the main object hidden behind the scene. Mikolaj Zalewski

June 2, 2006

winedbg: newbie question (sorry...)

by Molle Bestefich

Hello Carsten Niehaus (cniehaus(a)gmx.de) over on wine-users gets a page fault when he tries to print with this app: http://www.learn-line.nrw.de/angebote/gefahrstoffdb/Gefahrstoffe.zip He's posted a backtrace: > fixme:commdlg:PRINTDLG_SetUpPrinterListComboA Can't find '(null)' in printer list so trying to find default > wine: Unhandled page fault on write access to 0x0000002e at address 0x7f6a2540 (thread 0009), starting debugger... > Backtrace: > =>1 0x7f6a2540 PRINTDLG_WMCommandA+0x619 in comdlg32 (0x7f6a2540) > 2 0x7f6a2fb6 in comdlg32 (+0x32fb6) (0x7f6a2fb6) [snip!] > 0x7f6a2540 PRINTDLG_WMCommandA+0x619 in comdlg32: movw %ax,0x2e(%edx) I'm slightly cli-debugger-clueless, so could one of you guys please tell me how to convert this: PRINTDLG_WMCommandA+0x619 into a proper line number reference to the source file?

June 2, 2006

Re: How are we doing?

by Juan Lang

> Especially the code that is responded to as , I know it's a mess to > look at, but I didn't write it. Can you give us examples? Mostly Wine attempts to follow how Windows works, so MSDN provides a lot of the documentation. This is becoming increasingly true, with kernel32 being implemented on top of ntdll. There are bits that are hard to understand, certainly, and some areas could use some comments. Unfortunately sometimes the lack of comments demonstrates a lack of understanding, but the code works for someone, somewhere, so we're mostly afraid to touch it until some brave soul comes along. For example, SHFileOperation was a complete mess until James fixed it up. Another example is user32. It's impossible to document (in English) what it's supposed to be doing. For this, and many other cases, a good regression test suite is the best documentation: it tells you what's expected, so if you go mucking around you have checks against introducing regressions. I know you've been working with msi lately. The fact that you've figured out where the problem is indicates to me that it's adequately commented, even if the learning curve is still a bit steep. Patches to add API comments for the Wine API guide (http://source.winehq.org/WineAPI/ ) are always welcome. Patches to document dodgy bits of code may or may not be accepted, but regression tests to justify dodgy bits of code are happily accepted too. http://source.winehq.org/WineAPI/ --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

June 2, 2006

To K&R or not

by Molle Bestefich

EA Durbin wrote: > >K&R style brack placements > > They are an eyesore and make things difficult to read. Highly subjective. I think K&R has distinct advantages, namely it unites the scope begin token with the relevant control statement. For me, this makes code easier and faster to read, since I can follow the indentation and arrive immediately at the relevant control statement. Also I think that K&R is nice in that it saves screen real estate, which again for me makes code easier to read because I can see more of it at once. I personally consider non-K&R style an eyesore because of this. CMIIW, but the only thing that non-K&R has going for it is that you can visually make out whether you've made the correct number of opening versus closing braces. I don't think that's much of an advantage, especially considering that any modern source code editor will highlight the starting brace or relevant control statement for you. That said, I don't care what people do, I can read both... In my perfect world though, my SCM client would convert source code to my preferred format on checkout, and to whatever universal format the repository uses on checkin. Ho hum...

June 2, 2006

Re: How are we doing?

by EA Durbin

>K&R style brack placements was what i was referring to when I commented about coding style. They are an eyesore and make things difficult to read. >A number of people said: > "The code is too hard to read because it's >completely unmovitated and uncommented." Especially the code that is responded to as , I know it's a mess to look at, but I didn't write it. These portions of code could use a comment or two to explain what is going on, not every line, but explain what happens in that chunk of code. >From: Jeremy White <jwhite(a)codeweavers.com> >To: Dmitry Timoshkov <dmitry(a)codeweavers.com> >CC: Mike McCormack <mike(a)codeweavers.com>, wine-devel(a)winehq.org >Subject: Re: How are we doing? >Date: Fri, 02 Jun 2006 11:24:06 -0500 > > > grep Bestefich documentation/ChangeLog.ALPHA | wc -l > > 0 > > > > grep Bestefich ChangeLog | wc -l > > 0 > > > >And this is exactly the kind of comment and attitude >that pushes people away from being Wine developers. > >This was a thread that asked the question: > What would get more developers interested in Wine? > >A number of people said: > "The code is too hard to read because it's >completely unmovitated and uncommented." > >Dismissing their input because they've never contributed >code is exactly the wrong approach; if we're talking >about getting new developers, then their impressions >are particularly valuable. > >With that said, and all joking aside, I have never >seen Alexandre reject a patch with comments or strip >a single comment out. > >To get material comments in the code would require >the imposition of a kind of standard that is far >beyond anything we could reasonably expect. >Heck, we can't even standardize indenting or do away >with those abominable K&R style brack placements <g>. > >I just hope that the bulk of the anti comment pogrom >is mostly posturing and jest (which is what I suspect), and that >folks do try to comment tricky and inobvious bits. > >Cheers, > >Jeremy > >

June 2, 2006

Re: How are we doing?

by Jeremy White

> grep Bestefich documentation/ChangeLog.ALPHA | wc -l > 0 > > grep Bestefich ChangeLog | wc -l > 0 > And this is exactly the kind of comment and attitude that pushes people away from being Wine developers. This was a thread that asked the question: What would get more developers interested in Wine? A number of people said: "The code is too hard to read because it's completely unmovitated and uncommented." Dismissing their input because they've never contributed code is exactly the wrong approach; if we're talking about getting new developers, then their impressions are particularly valuable. With that said, and all joking aside, I have never seen Alexandre reject a patch with comments or strip a single comment out. To get material comments in the code would require the imposition of a kind of standard that is far beyond anything we could reasonably expect. Heck, we can't even standardize indenting or do away with those abominable K&R style brack placements <g>. I just hope that the bulk of the anti comment pogrom is mostly posturing and jest (which is what I suspect), and that folks do try to comment tricky and inobvious bits. Cheers, Jeremy

June 2, 2006

Re: [Darwine] RFC - wine-macos mailing list

by David Bialac

That being the case, why not clear up the name? Call the list wine-ppc(a)WineHQ. This makes clear it is for the ppc version, not the Intel version. The currently proposed name makes me think that the project refers to both Intel and PPC. Dave --- Jim White <jim(a)pagesmiths.com> wrote: > Joshua Root wrote: > > > C.W. Betts wrote: > > > >>If you could have it so that wine-macos is > instantly sent to > >>darwine-devel, and vice-versa. > > > > That seems rather redundant. Might as well just > migrate all the > > darwine-devel subscribers over to wine-macos and > discontinue the former, > > rather than have two lists with the same content. > > I'll repeat myself, because the message still is > getting missed. > > The goal of the Darwine Project is to run Wine on > *PowerPC* Mac OS X. > > We know that is definitely *not* the goal of WineHQ > because Wine Is Not > an Emulator. > > The point of this wine-macos @ WineHQ discussion is > because Alexandre & > Jeremy want Wine development work for *Intel* Mac OS > X to be focused at > wine-devel, and I want darwine-devel to focus on > Wine + QEMU development > work for *PowerPC* Mac OS X. > > Jim White > > > > _______________________________________________ > Darwine-devel mailing list > Darwine-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/darwine-devel > -- David Bialac dbialac(a)yahoo.com

June 2, 2006

Re: comctl32: Fix loading string from resources (take 2)

by Dmitry Timoshkov

"Thomas Weidenmueller" <wine-patches(a)reactsoft.com> wrote: > LoadString() cannot be used to measure the length of a string resource. > It will not return the length of the string if no buffer is provided, > instead it will return 0! This patch fixes the broken property sheet code. It would be appropriate to provide a test case showing correct LoadString behaviour and fix LoadString in Wine if it confirms the statement above since Wine clearly returns the size of the string resource if the passed buffer is NULL. -- Dmitry.

June 2, 2006

Re: Shell integration idea

by Ulrich Czekalla

I think the general approach is good. The way you handle the built in implementation seems odd to me. I think setting the registry key to make the freedesktop.org version as the default would be good enough. I'm not convinced we need IWineShellIntegration. I think it would be cleaner to directly create an IWineTrash object. /Ulrich On Thu, Jun 01, 2006 at 10:12:12PM +0200, Miko??aj Zalewski wrote: > As a SoC project I'll try to improve the integration of wine with the > Unix shells. My first step will be to implement the freedesktop.org > Trash. I've written some code that doesn't add any new features but > shows how I want to add it. I'd like to know if this is a good design? > The main idea is not to hard-code one implementation of things like > the Trash into shell32 - not everything is standardized by the > freedesktop and even if it would this might not work on other systems > like MacOS X. We should allow for many implementations. The correct one > is loaded depending on a registry settings (so that a winecfg entry can > be added). My implementation uses COM objects as it's standard dlls > provides support for such tasks. Currently there is one interface > (IWineShellIntegration) that acts as a factory for specialized objects. > That could also be implemented using COM Aggregation - when we do that > we could use QueryInterface instead of GetIntegrationObejct. > Some COM objects can run in the address space of the calling process - > e.g. the trash can be implemented like that. For others it would be a > waist of resources (e.g. there is no need for every process to watch is > the file associations have changed) - it's enough to load them only > once. The explorer seems to be a good candidate to create such objects. > In the attached patch there is one specialized interface - the > IWineTrash. The SHELL_DeleteFile[AW] is patched to use it - it shows a > different icon if the file can be trashed (these are not the correct > icons as wine's shell32 uses a message box instead of a special dialog) > and calls the trash method then. Currently there is only one built-in > trash that can't trash anything. (note that SHELL_DeleteFile is called > in the folders that are decendents of My Computer. If choose delete on a > file that is a decendent of the '/', it will be deleted without a warning). > > Mikolaj Zalewski >

June 2, 2006

Re: How are we doing?

by Molle Bestefich

Mike McCormack wrote: > Add all the great comments you like, but you still actually have to read > the code and understand it to figure out how to fix it. Often the goal is not to fix it, the goal is to understand it in order to fix something else. > So, IMO, you're better off striving for the Utopian goal of well > structured code that trying to make everybody understand what your > reason or intention was when you were writing the code, as in the end > you must understand the code and all it's subtleties anyway. As per above, often you're trying to figure out the big picture, not fix the particular function you're looking at. Increasing the speed of that process would be truly great.

June 2, 2006

Re: Wine VM86 exception handling bug?

by Dan Kegel

On 6/2/06, Andrey Turkin <pancha(a)mail.nnov.ru> wrote: > > How about writing a conformance test that demonstrates > > the problem? > > I would be happy to do it. Unfortunely, I cannot imagine how to > implement such test: > 1) DOS code needed - it would need binary or some sort of source to be > compiled prior to test or some temporary file with a binary You can embed a trivial DOS executable as data in the .c file > 2) method to catch failure inside of ntdll I'm sure you can work something out. At the very least, you can check that the DOS executable runs ok. > It is just not seems to be possible to do all this inside of some .c file. > > Hmm, is there any test for kernel or winedos at all? If not, there sure ought to be... - Dan

June 2, 2006

Re: Wine 1.0 tasks: installers

by EA Durbin

Thats a good one, since its on the Top 25 of the App DB, ranked #2 i believe, and freely available. The sudden of influx of people testing Americas Army in wine came from the America's Army community, after America's Army announced they would no longer support a linux port for the client, which is what brought me to wine. There's much discussion about wine on the America's Army forums. >From: "Dan Kegel" <dank(a)kegel.com> >To: wine-devel <wine-devel(a)winehq.org> >Subject: Re: Wine 1.0 tasks: installers >Date: Fri, 2 Jun 2006 07:35:36 -0700 > >On 6/2/06, Dan Kegel <dank(a)kegel.com> wrote: >>http://bugs.winehq.org/show_bug.cgi?id=3590 ActiveState python msi (see >>5237?) >>http://bugs.winehq.org/show_bug.cgi?id=3972 .NET framework 2.0 >>http://bugs.winehq.org/show_bug.cgi?id=4227 QuickTest Pro >>http://bugs.winehq.org/show_bug.cgi?id=4280 J2SE 1.5 >>http://bugs.winehq.org/show_bug.cgi?id=4492 MinGW installer stalls >>http://bugs.winehq.org/show_bug.cgi?id=4569 Oregon Trail 5 wants DX8 >>http://bugs.winehq.org/show_bug.cgi?id=4802 Oracle client library (munich) >>http://bugs.winehq.org/show_bug.cgi?id=4700 spss demo (munich) >>http://bugs.winehq.org/show_bug.cgi?id=4860 java plugin >>http://bugs.winehq.org/show_bug.cgi?id=5296 Kidspiration install window >>hidden? >>http://bugs.winehq.org/show_bug.cgi?id=5237 wsh (and ActiveState perl msi) >>http://bugs.winehq.org/show_bug.cgi?id=5275 google earth >>http://bugs.winehq.org/show_bug.cgi?id=5325 art2kmin.exe (munich, UK >>EPBD-NCM) >>http://bugs.winehq.org/show_bug.cgi?id=5322 VB6 / VC++6 installers fail >>early > >Oh, I forgot one: >http://bugs.winehq.org/show_bug.cgi?id=5139 America's Army msi bug > >- Dan > >

June 2, 2006

Re: Wine VM86 exception handling bug?

by Andrey Turkin

Dan Kegel wrote: > Andrey wrote: >> My opinion is that NtSetContextThread call is wrong; __wine_enter_vm86 >> would restore vm86 registers correctly. I think i know what is the >> problem; however, I lack experience to fix it myself :) >> I need help; any hints would be appreciated. > > How about writing a conformance test that demonstrates > the problem? That will help focus discussion and energy > on it, and keep it from coming back. > > Thanks! > - Dan > I would be happy to do it. Unfortunely, I cannot imagine how to implement such test: 1) DOS code needed - it would need binary or some sort of source to be compiled prior to test or some temporary file with a binary 2) method to catch failure inside of ntdll 3) maybe something else... It is just not seems to be possible to do all this inside of some .c file. Hmm, is there any test for kernel or winedos at all?

June 2, 2006

Re: How are we doing?

by Dmitry Timoshkov

"Molle Bestefich" <molle.bestefich(a)gmail.com> wrote: > Teaching people to write good comments is infinitely easier - it's a > simple case of banging 'em on the head and forcing them to write a > comment every time they've done a piece of code that they know > required cunning skill for whatever reason. You may need to perfect > the english phrasing from some of the foreigners around here once they > learn to actually write the comments, but that's a minor nit. Teaching people to write good comments is definitely much easier than writing real code. grep McCormack documentation/ChangeLog.ALPHA | wc -l 1084 grep McCormack ChangeLog | wc -l 220 grep Bestefich documentation/ChangeLog.ALPHA | wc -l 0 grep Bestefich ChangeLog | wc -l 0 -- Dmitry.

June 2, 2006

Re: RFC - device notifications idea

by Robert Shearman

Damjan Jovanovic wrote: >I was disappointed to see that "dynamic drive >configuration" >(http://www.winehq.org/?issue=313#Dynamic%20Drive%20Configuration) >amounts to a few HAL functions in wine's explorer. > >Windows has been using device notifications for at >least 11 years now (since Windows 95), and neither >wine nor ReactOS have even begun this feature. > >I would be interested in implementing it by using >dbus/HAL in wineserver, and translating HAL device >notifications into equivalent WM_DEVICECHANGE messages >which then get broadcast to all windows. > > WM_DEVICECHANGE is sent from explorer, but only for new drives. What's wrong with doing this in explorer still, but expanding the number of devices that are notified? >Is any work being done in this area? If not, would >this work? Are long-running functions requiring I/O >(hal_device_get_property_...()) allowed in wineserver >(which seems to be event-driven)? Any other comments? > Absolutely not. Any long-running functions will cause all of the user's winelib applications to freeze until the server unblocks. Also, note that there is an exception handler in explorer around some hal functions because they assert on some platforms. You won't be able to port that to wineserver and it would be really bad news if an assert fired there. -- Rob Shearman

June 2, 2006

Re: Wine 1.0 tasks: installers

by Dan Kegel

June 2, 2006

re: Wine VM86 exception handling bug?

by Dan Kegel

Andrey wrote: > My opinion is that NtSetContextThread call is wrong; __wine_enter_vm86 > would restore vm86 registers correctly. I think i know what is the > problem; however, I lack experience to fix it myself :) > I need help; any hints would be appreciated. How about writing a conformance test that demonstrates the problem? That will help focus discussion and energy on it, and keep it from coming back. Thanks! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 2, 2006

Wine 1.0 tasks: installers

by Dan Kegel

James Hawkins and I think we should come up with a list of installers that need to run before we release Wine 1.0. Looking at http://www.winehq.org/pipermail/wine-devel/2006-March/045634.html and http://bugs.winehq.org/buglist.cgi?short_desc_type=allwordssubstr&short_des… I made a list biased towards freely downloadable apps, programming tools, things Munich wants, stuff that has been passionately discussed of late (e.g. America's Army), educational apps, and anything that smacks of long-unfinished business. Here's what I ended up with: http://bugs.winehq.org/show_bug.cgi?id=3590 ActiveState python msi (see 5237?) http://bugs.winehq.org/show_bug.cgi?id=3972 .NET framework 2.0 http://bugs.winehq.org/show_bug.cgi?id=4227 QuickTest Pro http://bugs.winehq.org/show_bug.cgi?id=4280 J2SE 1.5 http://bugs.winehq.org/show_bug.cgi?id=4492 MinGW installer stalls http://bugs.winehq.org/show_bug.cgi?id=4569 Oregon Trail 5 wants DX8 http://bugs.winehq.org/show_bug.cgi?id=4802 Oracle client library (munich) http://bugs.winehq.org/show_bug.cgi?id=4700 spss demo (munich) http://bugs.winehq.org/show_bug.cgi?id=4860 java plugin http://bugs.winehq.org/show_bug.cgi?id=5296 Kidspiration install window hidden? http://bugs.winehq.org/show_bug.cgi?id=5237 wsh (and ActiveState perl msi) http://bugs.winehq.org/show_bug.cgi?id=5275 google earth http://bugs.winehq.org/show_bug.cgi?id=5325 art2kmin.exe (munich, UK EPBD-NCM) http://bugs.winehq.org/show_bug.cgi?id=5322 VB6 / VC++6 installers fail early Some of those might already be fixed, hopefull we can just close out a couple. And a couple might be too hard for 1.0 (.net, say), it's ok to defer them to 1.1 later if we have to. Ideally we'd also have cxtest scripts for all of these installers, so Codeweavers can use them to validate new releases. How's that sound? - Dan

June 2, 2006

Re: RFC - device notifications idea

by Alexandre Julliard

Damjan Jovanovic <dj015(a)yahoo.com> writes: > I was disappointed to see that "dynamic drive > configuration" > (http://www.winehq.org/?issue=313#Dynamic%20Drive%20Configuration) > amounts to a few HAL functions in wine's explorer. What's disappointing about that? > I would be interested in implementing it by using > dbus/HAL in wineserver, and translating HAL device > notifications into equivalent WM_DEVICECHANGE messages > which then get broadcast to all windows. That's exactly what the current code in explorer does... -- Alexandre Julliard julliard(a)winehq.org

June 2, 2006

RFC - device notifications idea

by Damjan Jovanovic

I was disappointed to see that "dynamic drive configuration" (http://www.winehq.org/?issue=313#Dynamic%20Drive%20Configuration) amounts to a few HAL functions in wine's explorer. Windows has been using device notifications for at least 11 years now (since Windows 95), and neither wine nor ReactOS have even begun this feature. I would be interested in implementing it by using dbus/HAL in wineserver, and translating HAL device notifications into equivalent WM_DEVICECHANGE messages which then get broadcast to all windows. Is any work being done in this area? If not, would this work? Are long-running functions requiring I/O (hal_device_get_property_...()) allowed in wineserver (which seems to be event-driven)? Any other comments? Thank you Damjan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

June 2, 2006

Wine VM86 exception handling bug?

by Andrey Turkin

Hi all! I think i found a bug in VM86 exception handling (must be regression, i guess). Short Wine function flow: On privileged instruction __wine_enter_vm86 saves vm86 registers in CONTEXT and starts raise_segv_exception. raise_segv_exception routes exception to the INSTR_EmulateInstruction and then to winedos I/O emulator, then tries to use NtSetContextThread(GetCurrentThread(), CONTEXT). NtSetContextThread obviously fails because of VM86 segment values in CONTEXT. My opinion is that NtSetContextThread call is wrong; __wine_enter_vm86 would restore vm86 registers correctly. I think i know what is the problem; however, I lack experience to fix it myself :) I need help; any hints would be appreciated.

June 2, 2006

Re: How are we doing?

by Mike McCormack

Molle Bestefich wrote: > Sure, that would help with understanding the call structure. > But your angle of attack is utopian, since making up function names > perfect enough to convey all needed information in the context of all > callers, and always structuring code perfectly - especially when the > code has to work exactly like Windows code - is practically > impossible. And getting everybody to do it is even worse. > > Teaching people to write good comments is infinitely easier - it's a > simple case of banging 'em on the head and forcing them to write a > comment every time they've done a piece of code that they know > required cunning skill for whatever reason. You may need to perfect > the english phrasing from some of the foreigners around here once they > learn to actually write the comments, but that's a minor nit. Teaching people to write well structured code is definitely much harder, as sloppy programmers can be easily trained to write better comments about their badly structured code. Add all the great comments you like, but you still actually have to read the code and understand it to figure out how to fix it. So, IMO, you're better off striving for the Utopian goal of well structured code that trying to make everybody understand what your reason or intention was when you were writing the code, as in the end you must understand the code and all it's subtleties anyway. Mike

June 2, 2006

re: test case for MSI problem in America's Army installer

by Dan Kegel

Mike M. wrote: >>> [America's Army install crashes, see >>> http://bugs.winehq.org/show_bug.cgi?id=5139 ] >> >> This is as close as I will be able to come to including a test case, as >> this is how I obtained my results. > > If you want me to fix the problem, please submit a regression test to > wine-patches with a todo_wine{} around the code that doesn't work. If that's too hard for EA (he admits he's not a C hacker), maybe I can focus some energy on it... - Dan

June 2, 2006

Re: How are we doing?

by David D. Hagood

Mike McCormack wrote: > If what you really want is code that's easier to understand we're better > off scrapping all comments... And we can encourage safe driving by removing airbags and seatbelts, and installing big shiny sharp metal spikes on the steering wheel, and executing anybody who has an accident and survives. Code CANNOT explain "why" - there simply is no way to encode that into the source EXCEPT comments. The solution is to review code and to reject patches that contain "Fixme - this is busted" without a more detailed explanation.

June 2, 2006

Re: How are we doing?

by Molle Bestefich

Mike McCormack wrote: > /* My tests reveal that it's done this way */ > /* FIXME: this is broken */ > /* go forward in the array */ > Then you've got the whole issue of maintaining the > comments in synchronization with the code. You've gravely misunderstood what good code commenting is? Good comments tell what the _purpose_ of a block of code or a whole function is. The purpose of comments is to let strangers get approximately acquainted with how the code works in abstract, what the call structure is, etc. - NOT to document what individual lines of code do. Comments that simply state what the code right in front of you effectively does are of course useless. That goes both for dumb oneline comments like the ones you stated earlier, but also for comments that just describe what effects come from nesting a block of code like this and that. > If what you really want is code that's easier to understand we're better > off scrapping all comments, then enforcing good coding style, so that > the code is readable without comments. You're missing the point. > If the functions are kept small, things are well named, > and the complexity confined (eg. no 7 level indent), > you'll be able to understand the code without the auth Sure, that would help with understanding the call structure. But your angle of attack is utopian, since making up function names perfect enough to convey all needed information in the context of all callers, and always structuring code perfectly - especially when the code has to work exactly like Windows code - is practically impossible. And getting everybody to do it is even worse. Teaching people to write good comments is infinitely easier - it's a simple case of banging 'em on the head and forcing them to write a comment every time they've done a piece of code that they know required cunning skill for whatever reason. You may need to perfect the english phrasing from some of the foreigners around here once they learn to actually write the comments, but that's a minor nit.

June 2, 2006

Re: How are we doing?

by Jeremy White

> If what you really want is code that's easier to understand we're better > off scrapping all comments, then enforcing good coding style, so that > the code is readable without comments. If the functions are kept small, > things are well named, and the complexity confined (eg. no 7 level > indent), you'll be able to understand the code without the auth > > If you need to comment your code so others can understand it, it's > probably badly structured and unclear. I think that above argument, and the gripe about: i++; /* increment i */ are both overrated and overused to get away with laziness and to excuse a lack of discipline that would create better code. Yes, obviously written code to perform an obvious function needs few, if any, comments. And I think I would agree that the Wine server is commented about right; it is, imho, a beautiful piece of code. But there are plenty of places in Wine where the code does something screwball or out of the ordinary (hell, the API itself is screwball), and those places deserve more comments. I think David hit the nail on the head. I don't need a comment to tell me what the code is doing, I agree that the code itself is more clear. I need a comment to tell me why the @#$ you decided to do that. And the problem is that that prevailing attitude discourages people from being thoughtful about where a comment *would* do some good. I'd far rather discard a bunch of /* increment i */ comments but still have some comments as to an authors state of mind than have no comments at all (what we have now). But that's too bad, because Alexandre feels exactly the opposite; and so long as he's in charge (and I very much want him to continue being in charge), that's the way it's gonna be. @#$!@$@#$ Wine Maintainer... <grin> Cheers, Jeremy

June 2, 2006

Re: [Darwine] RFC - wine-macos mailing list

by Jim White

Joshua Root wrote: > C.W. Betts wrote: > >>If you could have it so that wine-macos is instantly sent to >>darwine-devel, and vice-versa. > > That seems rather redundant. Might as well just migrate all the > darwine-devel subscribers over to wine-macos and discontinue the former, > rather than have two lists with the same content. I'll repeat myself, because the message still is getting missed. The goal of the Darwine Project is to run Wine on *PowerPC* Mac OS X. We know that is definitely *not* the goal of WineHQ because Wine Is Not an Emulator. The point of this wine-macos @ WineHQ discussion is because Alexandre & Jeremy want Wine development work for *Intel* Mac OS X to be focused at wine-devel, and I want darwine-devel to focus on Wine + QEMU development work for *PowerPC* Mac OS X. Jim White

June 2, 2006

Re: winspool: [3/3] Add GetPrintProcessorDirectoryA

by Detlef Riekenberg

Am Freitag, den 02.06.2006, 11:30 +0200 schrieb Alexandre Julliard: > Detlef Riekenberg <wine.dev(a)web.de> writes: > > > + if (ret) { > > + needed = WideCharToMultiByte( CP_ACP, 0, InfoW, -1, (LPSTR)Info, cbBuf, NULL, NULL); > > + if (pcbNeeded) *pcbNeeded = needed; > > + ret = (needed > cbBuf) ? FALSE : TRUE; > > This check is wrong, WideCharToMultiByte will return 0 if the buffer > is too small. Hm. Our documentation and MSDN states for WC2MB: Success: If dstlen > 0, the number of characters written to dst. http://source.winehq.org/WineAPI/WideCharToMultiByte.html I took the code from GetPrinterDriverDirectoryA. The UNICODE-Buffer was allocated with: HeapAlloc(GetProcessHeap(), 0, cbBuf * sizeof(WCHAR)); The only Situation for WC2MB to run out of space here is, that the ANSI-String has MultiByte-Characters in it. Since our WC2MB returns 0, when the Destination-Buffer is to small, something is wrong. This situation is not tested in dlls/kernel/tests/* I investigate in this. -- By By ... ... Detlef

June 2, 2006

Re: How are we doing?

by Marcus Meissner

On Fri, Jun 02, 2006 at 07:27:18AM -0500, EA Durbin wrote: > >There is precious little "Why" in the comments of a lot of projects - Why > >does this function exist, why would I call it, why does it return what it > >does, etc. > > > >BS comments like those within the function don't help, obviously - but > >sometimes a comment block describing WHY a given chunk of code does what > >it does would be nice. > > > > > > Exactly my point. > > As in the case of wine, you must try to figure out what a block of code > does, then that block of code calls existing wine functions that you've > never seen before in your life. So then you have to trace that back to find > out what the already implemented function does, and look through the code > to it, because there is no documentation for it either, then it calls > another function, so go ahead and trace back through the code for it too to > find out what it does. Kind of like why i switched to gentoo, I didn't > like the rpm dependency hell of fedora, and this is eerily similar. As a > new developer, one is not familiar with all of the functions being used in > wine, a block of comment explaining what a function does would be nice, > instead of having to trace back through various parts of wine code, just to > find out what one function is doing. If you find something missing, patches or even comments pointing to such problems are welcome. Ciao, Marcus

June 2, 2006

Re: How are we doing?

by EA Durbin

>There is precious little "Why" in the comments of a lot of projects - Why >does this function exist, why would I call it, why does it return what it >does, etc. > >BS comments like those within the function don't help, obviously - but >sometimes a comment block describing WHY a given chunk of code does what it >does would be nice. > > Exactly my point. As in the case of wine, you must try to figure out what a block of code does, then that block of code calls existing wine functions that you've never seen before in your life. So then you have to trace that back to find out what the already implemented function does, and look through the code to it, because there is no documentation for it either, then it calls another function, so go ahead and trace back through the code for it too to find out what it does. Kind of like why i switched to gentoo, I didn't like the rpm dependency hell of fedora, and this is eerily similar. As a new developer, one is not familiar with all of the functions being used in wine, a block of comment explaining what a function does would be nice, instead of having to trace back through various parts of wine code, just to find out what one function is doing.

June 2, 2006

Re: How are we doing?

by Mike McCormack

David D. Hagood wrote: > ARRRRRRRG! This whole thing is just a bullshit strawman. Indeed. However my strawman demonstrates that it's difficult to enforce code commenting, as you'll just end up with a bunch of bs. You also can't comment somebody else's code properly, obvious things don't need commenting, and non-obvious things either have a comment, or you won't see them. You can't force other people to add comments, and you can't add them for yourself. So if you like comments, you can jump up and down and say there should be more, but that changes nothing. My pet hate comments are stuff like: /* My tests reveal that it's done this way */ ofcourse, those tests aren't in the test suite. /* FIXME: this is broken */ With no explanation of why. /* go forward in the array */ i--; Then you've got the whole issue of maintaining the comments in synchronization with the code. If what you really want is code that's easier to understand we're better off scrapping all comments, then enforcing good coding style, so that the code is readable without comments. If the functions are kept small, things are well named, and the complexity confined (eg. no 7 level indent), you'll be able to understand the code without the auth If you need to comment your code so others can understand it, it's probably badly structured and unclear. Mike

June 2, 2006

Re: How are we doing?

by Neil Skrypuch

On Friday, June 02, 2006 07:25, Mike McCormack wrote: > >> lack of comments in the code > > > > +1, I think it's horrifying. > > void the_function_that_adds_one_to_i(int i) > { > /* this adds one to i */ > i = i + 1; > > /* this returns i to the caller */ > return i; > } > > Horrifying, yes :) > > Mike Particularly horrifying is the return i in a void function! Is there a test for what native does in this case? - Neil

June 2, 2006

Re: How are we doing?

by David D. Hagood

Huw Davies wrote: > > There's a bug in this code, let's try this: > > /* change by Huw Davies 02-Jun-2006, to fix the return type of the function */ > int the_function_that_adds_one_to_i(int i) > { > /* this adds one to i */ > i = i + 1; > > /* this returns i to the caller */ > return i; > } > > That's so much better ;-) > Huw. ARRRRRRRG! This whole thing is just a bullshit strawman. The real complaint about the lack of comments is not this kind of trivial comment, but more like: /* the_function_that_adds_one_to_i - return 1+value This function is necessary because of a compiler bug in FooC 0.8, wherein just incrementing the loop variable in WinGenCryptokeyAllHailBillOurDarkLord will generate incorrect code. */ int the_function_that_adds_one_to_i(int i) { /* this adds one to i */ i = i + 1; /* this returns i to the caller */ return i; } There is precious little "Why" in the comments of a lot of projects - Why does this function exist, why would I call it, why does it return what it does, etc. BS comments like those within the function don't help, obviously - but sometimes a comment block describing WHY a given chunk of code does what it does would be nice.

June 2, 2006

Re: How are we doing?

by Huw Davies

On Fri, Jun 02, 2006 at 08:25:42PM +0900, Mike McCormack wrote: > > >>lack of comments in the code > > > >+1, I think it's horrifying. > > void the_function_that_adds_one_to_i(int i) > { > /* this adds one to i */ > i = i + 1; > > /* this returns i to the caller */ > return i; > } There's a bug in this code, let's try this: /* change by Huw Davies 02-Jun-2006, to fix the return type of the function */ int the_function_that_adds_one_to_i(int i) { /* this adds one to i */ i = i + 1; /* this returns i to the caller */ return i; } That's so much better ;-) Huw. -- Huw Davies huw(a)codeweavers.com

June 2, 2006

intermediate fontconfig 2.3.94 problems

by Marcus Meissner

Hi, SUSE Linux 10.1 contains fontconfig 2.3.94, which changed the FcPatternGetString() function from return path names to return only the filenames. We received this bugreport: https://bugzilla.novell.com/show_bug.cgi?id=179457 However, Bernd Rosenkraenzer reported this problem already and the change was reverted for fontconfig 2.3.95. Its just that it might be broken only in SL 10.1 (perhaps fixed with online update, still in discussion). So this is just a heads-up, if more bugreports should appear. Ciao, Marcus

June 2, 2006

Re: How are we doing?

by Robert Shearman

Molle Bestefich wrote: > EA Durbin wrote: > >> lack of comments in the code > > > +1, I think it's horrifying. The lack of comments in your email is more horrifying. Yes, yes, I know you will say that your email is self-documenting, but that isn't the point. ;-) -- Rob Shearman

June 2, 2006

Re: How are we doing?

by Mike McCormack

>> lack of comments in the code > > +1, I think it's horrifying. void the_function_that_adds_one_to_i(int i) { /* this adds one to i */ i = i + 1; /* this returns i to the caller */ return i; } Horrifying, yes :) Mike

June 2, 2006

Re: How are we doing?

by Molle Bestefich

EA Durbin wrote: > lack of comments in the code +1, I think it's horrifying.

June 2, 2006

Re: user32, x11drv: patch to send WM_SIZE at window state change (bug 4964)

by Alexandre Julliard

Juris Smotrovs <juris.smotrovs(a)sets.lv> writes: > The defwinproc mismatch itself appears > because, after solving the WM_SIZE issue, this message -- > correctly -- is sent, so the actual message queue shifts > relative to the expected message queue, and -- due to > some messages still missing -- three expected defwinproc > messages coincide with three actual non-defwinproc messages > which are expected later-on. Thus this failure is actually > not about messages sent from incorrect place, but simply > about missing messages which is a very typical failure > among the todo tests. Ah OK, I get it now. Thanks, I'll put it in. -- Alexandre Julliard julliard(a)winehq.org

June 2, 2006

Re: winspool: [3/3] Add GetPrintProcessorDirectoryA

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > + if (ret) { > + needed = WideCharToMultiByte( CP_ACP, 0, InfoW, -1, (LPSTR)Info, cbBuf, NULL, NULL); > + if (pcbNeeded) *pcbNeeded = needed; > + ret = (needed > cbBuf) ? FALSE : TRUE; This check is wrong, WideCharToMultiByte will return 0 if the buffer is too small. -- Alexandre Julliard julliard(a)winehq.org

June 2, 2006

Prospects of an OpenAL audio driver...

by Nick Burns

I have started work on an openal driver for wine... So far I have playback and recording working (with minor issues) (for some reason the DSound HEL is unhappy with my driver) OpenAL seems to have enough functionality to do the job. Are there any problems with using OpenAL for such a purpose? - Nick

June 2, 2006

Re: [Darwine] RFC - wine-macos mailing list

by Alexandre Julliard

Jeremy White <jwhite(a)codeweavers.com> writes: > My driving concern is that I think we need to welcome the Mac > community to the Wine Project and do all that we can to > enable the Mac developers and users to use mainstream Wine resources. > I don't think anyone wants www.winehq.org to be perceived as > a 'Linux only' environment. (Although I do see that www.winehq.org > doesn't list Mac OS X...hmmm). I think creating a separate list for Mac is only going to reinforce that impression, which is just the opposite of what we want. Mac users should be considered first-class citizens just like Linux users, and we must make it clear that they are welcome on our standard mailing lists. If at some point there's too much traffic on wine-users we can split it, but we are not there yet. -- Alexandre Julliard julliard(a)winehq.org

June 2, 2006

Re: RFC - wine-macos mailing list

by Joshua Root

C.W. Betts wrote: > If you could have it so that wine-macos is instantly sent to > darwine-devel, and vice-versa. That seems rather redundant. Might as well just migrate all the darwine-devel subscribers over to wine-macos and discontinue the former, rather than have two lists with the same content. - Josh

June 2, 2006

Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by Dan Kegel

On 6/1/06, tkho(a)ucla.edu <tkho(a)ucla.edu> wrote: > One thought that has recently crossed my mind: Building off his framework and > putting much of the code in the server may not have been a great idea, since > the only real need for the server is to get the unix pid of the thread. Nah, I think it was the right thing to do. You definitely want the server to do the dirty work here. > + /* return base address of allocated memory in eax */ > + asm("movl %0, %%eax" > + : > + :"r"(mem) > + :"%eax"); > + asm("int3"); /* execution doesn't continue past here */ Better surround that with #if defined(LINUX) && defined(__i386__), or whatever the right symbol is, and explain better why 'int3' is how you return to the caller of ptrace. > + printf("using allocator in kernel32 at 0x%08x\n", > + (unsigned) allocator); You might want to strip out the debugging prints... > +enum remote_op_code > +{ > + REMOTE_OP_NEW_THREAD, > + REMOTE_OP_VM_ALLOC, > + REMOTE_OP_VM_FREE, > + REMOTE_OP_VM_PROTECT, > + REMOTE_OP_VM_QUERY, > + REMOTE_OP_VM_MAP, > + REMOTE_OP_VM_UNMAP, > + REMOTE_OP_VM_FLUSH > +}; I would have ripped out any part of his patch you're not implementing, just to keep the size down... > + case REMOTE_OP_VM_ALLOC: > + { > +#if defined(linux) && defined(__i386__) > + int pid; > + struct user_regs_struct oldregs, regs; > + struct remote_op_params_vm_alloc *params; > + struct remote_op_result_vm_alloc result; > + ... You probably want to hide all the ptrace stuff inside a separate function called, maybe, posix_remote_mmap(...). Also, which bugzilla bugs / conformance tests will this fix? If the answer is 'none', maybe you need to write them. - Dan

June 2, 2006

ntdll: a simple implementation of cross-process NtAllocateVirtualMemory

by tkho＠ucla.edu

Hello, I ran across the need to do memory allocations across processes and came upon Alexander Yaworsky's patch at http://www.winehq.org/pipermail/wine-devel/2004-September/029953.html and took a different approach. Instead of waiting for the target process to check a fd, I changed the implementation to use ptrace to interrupt the target process and execute code in kernel32 that does an mmap/munmap. This is a simple implementation that does not do a full-on call to Nt(Allocate|Free)VirtualMemory inside the target process, mainly because the locks taken in the allocation management code would cause deadlocks. I've done informal testing to make sure the code doesn't crash Wine by running applications alongside this memory-churner: http://www.seas.ucla.edu/~kho/wine/alloc_test/alloc_test.exe http://www.seas.ucla.edu/~kho/wine/alloc_test/alloc_test.cpp One thought that has recently crossed my mind: Building off his framework and putting much of the code in the server may not have been a great idea, since the only real need for the server is to get the unix pid of the thread. Is this a step in the right direction? Comments appreciated! Thomas Kho --- Index: dlls/kernel/kernel32.spec =================================================================== RCS file: /home/wine/wine/dlls/kernel/kernel32.spec,v retrieving revision 1.174 diff -u -r1.174 kernel32.spec --- dlls/kernel/kernel32.spec 27 May 2006 11:36:56 -0000 1.174 +++ dlls/kernel/kernel32.spec 2 Jun 2006 05:43:15 -0000 @@ -1239,3 +1239,8 @@ # Init code @ cdecl __wine_kernel_init() + +# Remote memory allocation +# kernel32 is mapped to the same place in every process +@ cdecl wine_remote_NtAllocateVirtualMemory(ptr long long) +@ cdecl wine_remote_NtFreeVirtualMemory(ptr long) Index: dlls/kernel/virtual.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/virtual.c,v retrieving revision 1.18 diff -u -r1.18 virtual.c --- dlls/kernel/virtual.c 23 May 2006 12:48:03 -0000 1.18 +++ dlls/kernel/virtual.c 2 Jun 2006 05:43:15 -0000 @@ -42,6 +42,7 @@ #include "wine/exception.h" #include "excpt.h" #include "wine/debug.h" +#include "wine/library.h" #include "kernel_private.h" @@ -778,3 +779,77 @@ __ENDTRY return FALSE; } + +/*********************************************************************** + * wine_remote_NtAllocateVirtualMemory (KERNEL32.@) + * + * Reentrant function that allocates memory + * + * PARAMS + * base [I] Desired base address + * size [I] Number of bytes to allocate + * prot [I] Memory protection flags + * + * RETURNS + * Success: %eax contains base address of allocated region of pages. + * Failure: %eax is NULL. + */ +void wine_remote_NtAllocateVirtualMemory( LPVOID base, DWORD size, DWORD prot ) +{ + char *mem; + size += sizeof(int *); + mem = wine_anon_mmap(base, size, prot, 0); + /*printf("mmap base=0x%08x size=%d prot=%d, allocated at 0x%x\n", + base, size, prot, mem);*/ + *(int *) mem = size; + + mem += sizeof(int); + /* return base address of allocated memory in eax */ + asm("movl %0, %%eax" + : + :"r"(mem) + :"%eax"); + asm("int3"); /* execution doesn't continue past here */ + return; +} + +/*********************************************************************** + * wine_remote_NtFreeVirtualMemory (KERNEL32.@) + * + * Reentrant function that frees mmap'd memory + * + * PARAMS + * base [I] Desired base address + * size [I] Number of bytes to free + * + * RETURNS + * Success: %eax contains size of unmapped region + * Failure: %eax is 0. + */ +void wine_remote_NtFreeVirtualMemory( LPVOID base, DWORD size ) +{ + int result; + if (size == 0) + { + base = (char *) base - sizeof(int *); + size = *(int *) base; + result = munmap(base, size); + } + else /* FIXME unsafe for invalid base */ + result = 1; + + /*printf("munmap base=0x%08x size=%d, result: %d (%s)\n", + base, size, result, result == 0 ? "success" : "failure");*/ + + if (result == 0) /* munmap success */ + result = size; + else + result = 0; + /* return munmap return value in eax */ + asm("movl %0, %%eax" + : + :"r"(result) + :"%eax"); + asm("int3"); /* execution doesn't continue past here */ + return; +} Index: dlls/ntdll/virtual.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/virtual.c,v retrieving revision 1.90 diff -u -r1.90 virtual.c --- dlls/ntdll/virtual.c 23 May 2006 12:48:22 -0000 1.90 +++ dlls/ntdll/virtual.c 2 Jun 2006 05:43:16 -0000 @@ -144,6 +144,36 @@ /*********************************************************************** + * remote_op + * + */ +NTSTATUS remote_op( HANDLE process, int opcode, + void* params, int params_size, + void* result, int* result_size ) +{ + NTSTATUS status, remote_status = 0; + + SERVER_START_REQ( remote_operation ) + { + req->handle = process; + req->code = opcode; + if (params) wine_server_add_data( req, params, params_size ); + wine_server_set_reply( req, result, *result_size ); + if (!(status = wine_server_call( req ))) + { + remote_status = reply->status; + if (result) + *result_size = wine_server_reply_size( reply ); + TRACE("result_size=%d\n", *result_size); + } + } + SERVER_END_REQ; + + return status ? status : remote_status; +} + + +/*********************************************************************** * VIRTUAL_GetProtStr */ static const char *VIRTUAL_GetProtStr( BYTE prot ) @@ -1250,8 +1280,8 @@ * NtAllocateVirtualMemory (NTDLL.@) * ZwAllocateVirtualMemory (NTDLL.@) */ -NTSTATUS WINAPI NtAllocateVirtualMemory( HANDLE process, PVOID *ret, ULONG zero_bits, - SIZE_T *size_ptr, ULONG type, ULONG protect ) +NTSTATUS WINAPI NtAllocateVirtualMemory( HANDLE process, PVOID *ret, + ULONG zero_bits, SIZE_T *size_ptr, ULONG type, ULONG protect ) { void *base; BYTE vprot; @@ -1265,8 +1295,48 @@ if (!is_current_process( process )) { - ERR("Unsupported on other process\n"); - return STATUS_ACCESS_DENIED; + struct remote_op_params_vm_alloc alloc_params; + struct remote_op_result_vm_alloc alloc_result; + int result_size = sizeof(alloc_result); + typedef void (*allocator_type)(LPVOID base, DWORD size, DWORD prot); + static allocator_type allocator = NULL; + + if (!allocator) + { + HMODULE hkernel32; + UNICODE_STRING module; + ANSI_STRING function; + WCHAR kernel32W[] = {'k','e','r','n','e','l','3','2', + '.','d','l','l',0}; + RtlInitUnicodeString(&module, kernel32W); + RtlInitAnsiString(&function, "wine_remote_NtAllocateVirtualMemory"); + if (LdrGetDllHandle(0, 0, &module, &hkernel32) == STATUS_SUCCESS) + LdrGetProcedureAddress(hkernel32, &function, 0, + (void**)&allocator); + else + return STATUS_DLL_NOT_FOUND; + printf("using allocator in kernel32 at 0x%08x\n", + (unsigned) allocator); + } + + alloc_params.addr = *ret; + alloc_params.zerobits = zero_bits; + alloc_params.size = size; + alloc_params.type = type; + alloc_params.protect = VIRTUAL_GetProt( protect ); + alloc_params.allocator = allocator; + status = remote_op( process, REMOTE_OP_VM_ALLOC, + &alloc_params, sizeof(alloc_params), + &alloc_result, &result_size ); + if (!status) + { + *ret = alloc_result.addr; + *size_ptr = alloc_result.size; + } + printf("NtAllocateVirtualMemory status=0x%08x ptr=0x%08x size=%d\n", + (unsigned) status, (unsigned) alloc_result.addr, + alloc_result.size); + return status; } /* Round parameters to a page boundary */ @@ -1372,8 +1442,42 @@ if (!is_current_process( process )) { - ERR("Unsupported on other process\n"); - return STATUS_ACCESS_DENIED; + struct remote_op_params_vm_free free_params; + struct remote_op_result_vm_free free_result; + int result_size = sizeof(free_result); + typedef void (*deallocator_type)(LPVOID base, DWORD size); + static deallocator_type deallocator = NULL; + + if (!deallocator) { + HMODULE hkernel32; + UNICODE_STRING module; + ANSI_STRING function; + WCHAR kernel32W[] = {'k','e','r','n','e','l','3','2', + '.','d','l','l',0}; + RtlInitUnicodeString(&module, kernel32W); + RtlInitAnsiString(&function, "wine_remote_NtFreeVirtualMemory"); + + if (LdrGetDllHandle(0, 0, &module, &hkernel32) == STATUS_SUCCESS) + LdrGetProcedureAddress(hkernel32, &function, 0, + (void**)&deallocator); + else + return STATUS_DLL_NOT_FOUND; + printf("using deallocator in kernel32 at 0x%08x\n", + (unsigned) deallocator); + } + + free_params.addr = *addr_ptr; + free_params.size = size; + free_params.type = type; + free_params.deallocator = deallocator; + status = remote_op( process, REMOTE_OP_VM_FREE, + &free_params, sizeof(free_params), + &free_result, &result_size ); + if (!status) + *size_ptr = free_result.size; + printf("NtFreeVirtualMemory status=0x%08x size=%d\n", + (unsigned) status, (unsigned) free_result.size); + return status; } /* Fix the parameters */ Index: include/winternl.h =================================================================== RCS file: /home/wine/wine/include/winternl.h,v retrieving revision 1.181 diff -u -r1.181 winternl.h --- include/winternl.h 27 May 2006 11:37:02 -0000 1.181 +++ include/winternl.h 2 Jun 2006 05:43:17 -0000 @@ -2242,7 +2242,8 @@ extern NTSTATUS wine_nt_to_unix_file_name( const UNICODE_STRING *nameW, ANSI_STRING *unix_name_ret, UINT disposition, BOOLEAN check_case ); extern NTSTATUS wine_unix_to_nt_file_name( const ANSI_STRING *name, UNICODE_STRING *nt ); - +extern void wine_remote_NtAllocateVirtualMemory( LPVOID base, DWORD size, DWORD prot ); +extern void wine_remote_NtFreeVirtualMemory( LPVOID base, DWORD size ); /*********************************************************************** * Inline functions Index: include/wine/server_protocol.h =================================================================== RCS file: /home/wine/wine/include/wine/server_protocol.h,v retrieving revision 1.198 diff -u -r1.198 server_protocol.h --- include/wine/server_protocol.h 27 May 2006 11:37:01 -0000 1.198 +++ include/wine/server_protocol.h 2 Jun 2006 05:43:18 -0000 @@ -3727,6 +3727,132 @@ }; + +struct remote_operation_request +{ + struct request_header __header; + obj_handle_t handle; + int code; + /* VARARG(data,bytes); */ +}; +struct remote_operation_reply +{ + struct reply_header __header; + unsigned int status; + /* VARARG(data,bytes); */ +}; +enum remote_op_code +{ + REMOTE_OP_NEW_THREAD, + REMOTE_OP_VM_ALLOC, + REMOTE_OP_VM_FREE, + REMOTE_OP_VM_PROTECT, + REMOTE_OP_VM_QUERY, + REMOTE_OP_VM_MAP, + REMOTE_OP_VM_UNMAP, + REMOTE_OP_VM_FLUSH +}; + +struct remote_op_params_new_thread +{ + int suspend; + void *stack_addr; + unsigned int stack_reserve; + unsigned int stack_commit; + void *start; + void *param; +}; +struct remote_op_result_new_thread +{ + obj_handle_t handle; + thread_id_t tid; +}; + +struct remote_op_params_vm_alloc +{ + void *addr; + unsigned long zerobits; + unsigned long size; + unsigned long type; + unsigned long protect; + void *allocator; +}; +struct remote_op_result_vm_alloc +{ + void *addr; + unsigned long size; +}; + +struct remote_op_params_vm_free +{ + void *addr; + unsigned long size; + unsigned long type; + void *deallocator; +}; +struct remote_op_result_vm_free +{ + unsigned long size; +}; + +struct remote_op_params_vm_protect +{ + void *addr; + unsigned long size; + unsigned long new_prot; +}; +struct remote_op_result_vm_protect +{ + void *base; + unsigned long size; + unsigned long old_prot; +}; + +struct remote_op_params_vm_query +{ + void *addr; + int info_class; +}; + +struct remote_op_params_vm_map +{ + void *addr; + unsigned long zero_bits; + unsigned long commit_size; + unsigned long offset_low; + long offset_high; + unsigned long size; + int inherit; + unsigned long alloc_type; + unsigned long protect; +}; +struct remote_op_result_vm_map +{ + void *base; + unsigned long size; +}; + +struct remote_op_params_vm_flush +{ + void *addr; + unsigned long size; + unsigned long unknown; +}; +struct remote_op_result_vm_flush +{ + void *base; + unsigned long size; +}; + + +struct remote_op_request +{ + enum remote_op_code op_code; + thread_id_t originator; + int params_size; +}; + + enum request { REQ_new_process, @@ -3942,6 +4068,7 @@ REQ_create_symlink, REQ_open_symlink, REQ_query_symlink, + REQ_remote_operation, REQ_NB_REQUESTS }; @@ -4162,6 +4289,7 @@ struct create_symlink_request create_symlink_request; struct open_symlink_request open_symlink_request; struct query_symlink_request query_symlink_request; + struct remote_operation_request remote_operation_request; }; union generic_reply { @@ -4380,8 +4508,9 @@ struct create_symlink_reply create_symlink_reply; struct open_symlink_reply open_symlink_reply; struct query_symlink_reply query_symlink_reply; + struct remote_operation_reply remote_operation_reply; }; -#define SERVER_PROTOCOL_VERSION 234 +#define SERVER_PROTOCOL_VERSION 238 #endif /* __WINE_WINE_SERVER_PROTOCOL_H */ Index: server/process.c =================================================================== RCS file: /home/wine/wine/server/process.c,v retrieving revision 1.167 diff -u -r1.167 process.c --- server/process.c 23 May 2006 12:49:34 -0000 1.167 +++ server/process.c 2 Jun 2006 05:43:18 -0000 @@ -22,12 +22,15 @@ #include "wine/port.h" #include <assert.h> +#include <errno.h> #include <limits.h> +#include <linux/user.h> #include <signal.h> #include <string.h> #include <stdarg.h> #include <stdio.h> #include <stdlib.h> +#include <sys/ptrace.h> #include <sys/time.h> #ifdef HAVE_SYS_SOCKET_H # include <sys/socket.h> @@ -36,6 +39,7 @@ #ifdef HAVE_POLL_H #include <poll.h> #endif +#include <sys/wait.h> #include "ntstatus.h" #define WIN32_NO_STATUS @@ -1081,3 +1085,209 @@ release_object( process ); } } + +/* Accept parameters for remote operation and start it */ +DECL_HANDLER(remote_operation) +{ + int access; + struct process *process; + struct thread *thread; + + /* define required access rights */ + switch( req->code ) + { + case REMOTE_OP_NEW_THREAD: + access = PROCESS_CREATE_THREAD | PROCESS_QUERY_INFORMATION + | PROCESS_VM_OPERATION | PROCESS_VM_READ | PROCESS_VM_WRITE; + break; + case REMOTE_OP_VM_ALLOC: access = PROCESS_VM_OPERATION; break; + case REMOTE_OP_VM_FREE: access = PROCESS_VM_OPERATION; break; + case REMOTE_OP_VM_PROTECT: access = PROCESS_VM_OPERATION; break; + case REMOTE_OP_VM_QUERY: access = PROCESS_QUERY_INFORMATION; break; + case REMOTE_OP_VM_MAP: access = PROCESS_VM_OPERATION; break; + case REMOTE_OP_VM_UNMAP: access = PROCESS_VM_OPERATION; break; + case REMOTE_OP_VM_FLUSH: access = PROCESS_VM_OPERATION; break; /* FIXME: is access right? */ + default: + set_error( STATUS_INVALID_PARAMETER ); + return; + } + + switch( req->code ) + { + case REMOTE_OP_NEW_THREAD: + break; + case REMOTE_OP_VM_ALLOC: + { +#if defined(linux) && defined(__i386__) + int pid; + struct user_regs_struct oldregs, regs; + struct remote_op_params_vm_alloc *params; + struct remote_op_result_vm_alloc result; + + params = (struct remote_op_params_vm_alloc *) get_req_data(); + + /* get process object */ + if (!(process = get_process_from_handle( req->handle, access ))) + return; + + thread = get_process_first_thread(process); + pid = thread->unix_pid; + release_object(process); + + /*printf("attaching to process with pid %d\n", pid);*/ + if (ptrace(PTRACE_ATTACH, pid, NULL, NULL) == -1) + goto errorbeforeattach; + + wait(NULL); + if (ptrace(PTRACE_GETREGS, pid, NULL, &regs) == -1) + goto error; + + memcpy(&oldregs, &regs, sizeof(struct user_regs_struct)); + + regs.eip = (int) params->allocator; + + /* cdecl */ + if (ptrace(PTRACE_POKEDATA, pid, regs.esp-4, params->protect) == -1) + goto error; + if (ptrace(PTRACE_POKEDATA, pid, regs.esp-8, params->size) == -1) + goto error; + if (ptrace(PTRACE_POKEDATA, pid, regs.esp-12, params->addr) == -1) + goto error; + regs.esp -= 16; + + /* prevent the kernel from restarting the system call. + * see i386_linux_write_pc() in gdb/i386-linux-tdep.c of gdb */ + regs.orig_eax = -1; + + if (ptrace(PTRACE_SETREGS, pid, NULL, &regs) == -1) + goto error; + if (ptrace(PTRACE_CONT, pid, NULL, NULL) == -1) + goto error; + + wait(NULL); + if (ptrace(PTRACE_GETREGS, pid, NULL, &regs) == -1) + goto error; + + /* eax has pointer to allocated memory */ + /*printf("mem allocated in target process at 0x%08x\n", + (unsigned) regs.eax);*/ + if (ptrace(PTRACE_SETREGS, pid, NULL, &oldregs) == -1) + goto error; + if (ptrace(PTRACE_DETACH, pid, NULL, NULL) == -1) + goto error; + + reply->status = regs.eax ? STATUS_SUCCESS + : STATUS_INVALID_PARAMETER; + result.addr = (void *) regs.eax; + result.size = params->size; + + assert(sizeof(result) <= get_reply_max_size()); + set_reply_data(&result, sizeof(result)); + + break; + +error: + printf("error!\n"); + ptrace(PTRACE_DETACH, pid, NULL, NULL); + set_error( STATUS_INVALID_PARAMETER ); + break; + +errorbeforeattach: + printf("error before attach!\n"); + set_error( STATUS_INVALID_PARAMETER ); + break; +#else + set_error( STATUS_NOT_IMPLEMENTED ); +#endif + } + case REMOTE_OP_VM_FREE: + { +#if defined(linux) && defined(__i386__) + int pid; + struct user_regs_struct oldregs, regs; + struct remote_op_params_vm_free *params; + struct remote_op_result_vm_free result; + + params = (struct remote_op_params_vm_free *) get_req_data(); + + /* get process object */ + if (!(process = get_process_from_handle( req->handle, access ))) + return; + + thread = get_process_first_thread(process); + pid = thread->unix_pid; + release_object(process); + + /*printf("attaching to process with pid %d\n", pid);*/ + if (ptrace(PTRACE_ATTACH, pid, NULL, NULL) == -1) + goto freeerrorbeforeattach; + + wait(NULL); + if (ptrace(PTRACE_GETREGS, pid, NULL, &regs) == -1) + goto freeerror; + memcpy(&oldregs, &regs, sizeof(struct user_regs_struct)); + + regs.eip = (int) params->deallocator; + + /* cdecl */ + if (ptrace(PTRACE_POKEDATA, pid, regs.esp-4, params->size) == -1) + goto freeerror; + if (ptrace(PTRACE_POKEDATA, pid, regs.esp-8, params->addr) == -1) + goto freeerror; + regs.esp -= 12; + + /* prevent the kernel from restarting the system call. + * see i386_linux_write_pc() in gdb/i386-linux-tdep.c of gdb */ + regs.orig_eax = -1; + + if (ptrace(PTRACE_SETREGS, pid, NULL, &regs) == -1) + goto freeerror; + if (ptrace(PTRACE_CONT, pid, NULL, NULL) == -1) + goto freeerror; + + wait(NULL); + if (ptrace(PTRACE_GETREGS, pid, NULL, &regs) == -1) + goto freeerror; + + /* eax has return value */ + /*printf("munmap'd in target process, result=0x%08x\n", + (unsigned) regs.eax);*/ + if (ptrace(PTRACE_SETREGS, pid, NULL, &oldregs) == -1) + goto freeerror; + if (ptrace(PTRACE_DETACH, pid, NULL, NULL) == -1) + goto freeerror; + + reply->status = regs.eax ? STATUS_SUCCESS + : STATUS_INVALID_PARAMETER; + result.size = regs.eax; + + assert(sizeof(result) <= get_reply_max_size()); + set_reply_data(&result, sizeof(result)); + + break; + +freeerror: + printf("error!\n"); + ptrace(PTRACE_DETACH, pid, NULL, NULL); + set_error( STATUS_INVALID_PARAMETER ); + break; + +freeerrorbeforeattach: + printf("error before attach!\n"); + set_error( STATUS_INVALID_PARAMETER ); + break; +#else + set_error( STATUS_NOT_IMPLEMENTED ); +#endif + } + case REMOTE_OP_VM_PROTECT: + case REMOTE_OP_VM_QUERY: + case REMOTE_OP_VM_MAP: + case REMOTE_OP_VM_UNMAP: + case REMOTE_OP_VM_FLUSH: + break; + default: + set_error( STATUS_INVALID_PARAMETER ); + return; + } +} Index: server/protocol.def =================================================================== RCS file: /home/wine/wine/server/protocol.def,v retrieving revision 1.198 diff -u -r1.198 protocol.def --- server/protocol.def 27 May 2006 11:37:01 -0000 1.198 +++ server/protocol.def 2 Jun 2006 05:43:18 -0000 @@ -2615,3 +2615,124 @@ @REPLY VARARG(target_name,unicode_str); /* target name */ @END + + +/* Accept parameters for remote operation and start it */ +(a)REQ(remote_operation) + obj_handle_t handle; /* process handle */ + int code; /* operation code (see below) */ + VARARG(data,bytes); /* operation parameters (see below) */ +(a)REPLY + unsigned int status; /* operation status */ + VARARG(data,bytes); /* operation result data (see below) */ +(a)END +enum remote_op_code +{ + REMOTE_OP_NEW_THREAD, + REMOTE_OP_VM_ALLOC, + REMOTE_OP_VM_FREE, + REMOTE_OP_VM_PROTECT, + REMOTE_OP_VM_QUERY, + REMOTE_OP_VM_MAP, + REMOTE_OP_VM_UNMAP, + REMOTE_OP_VM_FLUSH +}; + +struct remote_op_params_new_thread +{ + int suspend; + void *stack_addr; + unsigned int stack_reserve; + unsigned int stack_commit; + void *start; + void *param; +}; +struct remote_op_result_new_thread +{ + obj_handle_t handle; + thread_id_t tid; +}; + +struct remote_op_params_vm_alloc +{ + void *addr; + unsigned long zerobits; + unsigned long size; + unsigned long type; + unsigned long protect; + void *allocator; +}; +struct remote_op_result_vm_alloc +{ + void *addr; + unsigned long size; +}; + +struct remote_op_params_vm_free +{ + void *addr; + unsigned long size; + unsigned long type; + void *deallocator; +}; +struct remote_op_result_vm_free +{ + unsigned long size; +}; + +struct remote_op_params_vm_protect +{ + void *addr; + unsigned long size; + unsigned long new_prot; +}; +struct remote_op_result_vm_protect +{ + void *base; + unsigned long size; + unsigned long old_prot; +}; + +struct remote_op_params_vm_query +{ + void *addr; + int info_class; +}; + +struct remote_op_params_vm_map +{ + void *addr; + unsigned long zero_bits; + unsigned long commit_size; + unsigned long offset_low; + long offset_high; + unsigned long size; + int inherit; + unsigned long alloc_type; + unsigned long protect; +}; +struct remote_op_result_vm_map +{ + void *base; + unsigned long size; +}; + +struct remote_op_params_vm_flush +{ + void *addr; + unsigned long size; + unsigned long unknown; +}; +struct remote_op_result_vm_flush +{ + void *base; + unsigned long size; +}; + +/* structure for marshalling remote operation requests */ +struct remote_op_request +{ + enum remote_op_code op_code; + thread_id_t originator; + int params_size; +}; Index: server/request.h =================================================================== RCS file: /home/wine/wine/server/request.h,v retrieving revision 1.132 diff -u -r1.132 request.h --- server/request.h 23 May 2006 12:49:34 -0000 1.132 +++ server/request.h 2 Jun 2006 05:43:18 -0000 @@ -323,6 +323,7 @@ DECL_HANDLER(create_symlink); DECL_HANDLER(open_symlink); DECL_HANDLER(query_symlink); +DECL_HANDLER(remote_operation); #ifdef WANT_REQUEST_HANDLERS @@ -542,6 +543,7 @@ (req_handler)req_create_symlink, (req_handler)req_open_symlink, (req_handler)req_query_symlink, + (req_handler)req_remote_operation, }; #endif /* WANT_REQUEST_HANDLERS */ Index: server/trace.c =================================================================== RCS file: /home/wine/wine/server/trace.c,v retrieving revision 1.310 diff -u -r1.310 trace.c --- server/trace.c 27 May 2006 11:37:01 -0000 1.310 +++ server/trace.c 2 Jun 2006 05:43:19 -0000 @@ -3263,6 +3263,21 @@ dump_varargs_unicode_str( cur_size ); } +static void dump_remote_operation_request( const struct remote_operation_request *req ) +{ + fprintf( stderr, " handle=%p,", req->handle ); + fprintf( stderr, " code=%d,", req->code ); + fprintf( stderr, " data=" ); + dump_varargs_bytes( cur_size ); +} + +static void dump_remote_operation_reply( const struct remote_operation_reply *req ) +{ + fprintf( stderr, " status=%08x,", req->status ); + fprintf( stderr, " data=" ); + dump_varargs_bytes( cur_size ); +} + static const dump_func req_dumpers[REQ_NB_REQUESTS] = { (dump_func)dump_new_process_request, (dump_func)dump_get_new_process_info_request, @@ -3477,6 +3492,7 @@ (dump_func)dump_create_symlink_request, (dump_func)dump_open_symlink_request, (dump_func)dump_query_symlink_request, + (dump_func)dump_remote_operation_request, }; static const dump_func reply_dumpers[REQ_NB_REQUESTS] = { @@ -3693,6 +3709,7 @@ (dump_func)dump_create_symlink_reply, (dump_func)dump_open_symlink_reply, (dump_func)dump_query_symlink_reply, + (dump_func)dump_remote_operation_reply, }; static const char * const req_names[REQ_NB_REQUESTS] = { @@ -3909,6 +3926,7 @@ "create_symlink", "open_symlink", "query_symlink", + "remote_operation", }; static const struct

June 2, 2006

Re: Test Case

by Mike McCormack

EA Durbin wrote: > This is as close as I will be able to come to including a test case, as > this is how I obtained my results. If you want me to fix the problem, please submit a regression test to wine-patches with a todo_wine{} around the code that doesn't work. thanks, Mike

June 2, 2006

Re: [Darwine] RFC - wine-macos mailing list

by C.W. Betts

If you could have it so that wine-macos is instantly sent to darwine-devel, and vice-versa.

June 2, 2006

Test Case

by EA Durbin

This is as close as I will be able to come to including a test case, as this is how I obtained my results. Here is my code, and the resulting logs. Here are some patches I used, just a quick hack of the existing wine code, to run a query and iterate through the results. As you'll see in the enclosed results, this query is returning the results of Sequence < 8 even though the query called for Sequence >= 8. trace:msi:msiobj_release 0x7efcad60 trace:msi:msiobj_release object 0x7efcad60 destroyed trace:msi:MSI_ViewFetch 0x7efda640 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 2 trace:msi:msiobj_release 0x7efcad60 trace:msi:msiobj_release object 0x7efcad60 destroyed trace:msi:MSI_ViewFetch 0x7efda640 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 1 trace:msi:msiobj_release 0x7efcad60 trace:msi:msiobj_release object 0x7efcad60 destroyed trace:msi:MSI_ViewFetch 0x7efda640 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 3 trace:msi:msiobj_release 0x7efcad60 trace:msi:msiobj_release object 0x7efcad60 destroyed trace:msi:MSI_ViewFetch 0x7efda640 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 5 trace:msi:msiobj_release 0x7efcad60 trace:msi:msiobj_release object 0x7efcad60 destroyed trace:msi:MSI_ViewFetch 0x7efda640 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 4 f8 And when I queried the Media Table WHERE LastSequence >= 20, it returns LastSequence < 20, trace:msi:ACTION_InstallFiles DEBUGGING SELECT * FROM Media WHERE LastSequence >= 20 trace:msi:MSI_ViewExecute 0x7efde0f0 (nil) trace:msi:MSI_ViewFetch 0x7efde0f0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest Last Sequence: 6 trace:msi:ITERATE_QueryTest Disk Id: 1 trace:msi:ITERATE_QueryTest CAB: L"Disk1.cab" trace:msi:msiobj_release 0x7efe0900 trace:msi:msiobj_release object 0x7efe0900 destroyed trace:msi:MSI_ViewFetch 0x7efde0f0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest Last Sequence: 14 trace:msi:ITERATE_QueryTest Disk Id: 2 hence its broken. And this query is the same, regardless of the platform WHERE VALUE >= test condition, is WHERE value is Greater than or equal test condition, on any SQL implementation, MSI, mysql, postgre, ORACLE, etc. etc., wine's implementation is broken.

June 1, 2006