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

Re: [AppDB] Change licence to AGPL

by Chris Morgan

I think I'm ok with the gpl/agpl v3 change. Are there any other people using the appdb code that this might affect? Chris On Nov 23, 2007 10:34 PM, Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> wrote: > On Saturday 24 November 2007 04:01:24 Trent Waddington wrote: > > interesting. Do you have a list of contributors and their signoff on > > this license change? > > > > Or is it just you two? > > > > Well I didn't think that was necessary; but after some thought I realize that > the AppDB only seemed to include a LICENSE file containing the GPL v2, while > a GPL/AGPL v3 change would require previous code to be licenced under 'GPL v2 > or later'. > > So I'm including the other authors in this mail to see if they agree, or have > already licenced their code under GPL v2 or later > > Sorry for all the mess, but legal stuff isn't really my thing. :) > > > Alexander N. Sørnes > > > > On Nov 24, 2007 12:36 PM, Alexander Nicolaysen Sørnes > > > > <alex(a)thehandofagony.com> wrote: > > > Change licence to AGPL > > > > > > > > > > > > Alexander N. Sørnes > > > >

Nov. 24, 2007

Re: [AppDB] Change licence to AGPL

by Alexander Nicolaysen Sørnes

On Saturday 24 November 2007 04:01:24 Trent Waddington wrote: > interesting. Do you have a list of contributors and their signoff on > this license change? > > Or is it just you two? > Well I didn't think that was necessary; but after some thought I realize that the AppDB only seemed to include a LICENSE file containing the GPL v2, while a GPL/AGPL v3 change would require previous code to be licenced under 'GPL v2 or later'. So I'm including the other authors in this mail to see if they agree, or have already licenced their code under GPL v2 or later Sorry for all the mess, but legal stuff isn't really my thing. :) Alexander N. Sørnes > On Nov 24, 2007 12:36 PM, Alexander Nicolaysen Sørnes > > <alex(a)thehandofagony.com> wrote: > > Change licence to AGPL > > > > > > > > Alexander N. Sørnes

Nov. 24, 2007

Re: [AppDB] Change licence to AGPL

by Trent Waddington

interesting. Do you have a list of contributors and their signoff on this license change? Or is it just you two? On Nov 24, 2007 12:36 PM, Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> wrote: > Change licence to AGPL > > > > Alexander N. Sørnes > > > >

Nov. 24, 2007

xlviewer install cmdline passed from CreateProcessA to msiexec looks wrong

by Darragh Bailey

OK, long time lurker, only recently decided to try my hand at coding for wine. Picked a bug 9628 and decided to have a bash. Bug occured because a patch to the msiexec command line parsing was reverted due to regressions in the xlviewer installer and other apps. I don't know about the other apps, I can't find a corresponding bug and only gleaned this bit of info from the changelog and in the cvs mailing list that tracks commits. http://www.winehq.org/pipermail/wine-cvs/2007-March/031339.html After some digging I found that problem was that with current git the command line being sent to msiexec when installing "RPG Maker" was missing the msiexec executable. So the msiexec command line parsing would result in "/i" as being the first element of the arguments array to be processed. The main loop, expected that msiexec should always be argv[0], and so will always start from the second element. Then comparing of what used to happen when msiexec used the call to CommandLineToArgvW suggested that use of CommandLineToArgvW was more correct given the main loop design. If the program name is absent as the first argument, msiexec would just get back an empty string as the first element and the arguments to msiexec would start at the second element. Since this appears more correct, I looked at the behaviour of xlviewer (free download from microsoft) installer, to see what the differences were. I had to add some extra traces to the start of the main function in msiexec to get an idea of what was going on. Basically they would just dump out the contents of argv, one per line, so that I could see what it was getting as the command line. Added the following to the top of the main function: for( i=0; i<argc; i++) { WINE_TRACE("bug 9628: argv[%d] = \"%s\"\n", i, argv[i]); } using the newly build wine tree, and just pointing wine at the exe. The command line msiexec would get on installing xlviewer was trace:msiexec:main bug 9628: argv[0] = "c:\windows\system32\msiexec.exe" trace:msiexec:main bug 9628: argv[1] = "/I" trace:msiexec:main bug 9628: argv[2] = "C:\windows\temp\IXP001.TMP\XLVIEW.MSI" trace:msiexec:main bug 9628: argv[3] = "CDCACHE=2" trace:msiexec:main bug 9628: argv[4] = "LAUNCHEDFROMSETUP=1" trace:msiexec:main bug 9628: argv[5] = "SETUPEXEPATH=C:\windows\temp\IXP001.TMP" SETUPEXENAME=SETUP.EXE /lpiwaeo C:\windows\temp\Microsoft" trace:msiexec:main bug 9628: argv[6] = "Office" trace:msiexec:main bug 9628: argv[7] = "Excel" trace:msiexec:main bug 9628: argv[8] = "Viewer" trace:msiexec:main bug 9628: argv[9] = "2003" trace:msiexec:main bug 9628: argv[10] = "Setup(0004)_Task(0001).txt CDCACHE=0 DWSETUPLOGFILE=C:\windows\temp\Microsoft" trace:msiexec:main bug 9628: argv[11] = "Office" trace:msiexec:main bug 9628: argv[12] = "Excel" trace:msiexec:main bug 9628: argv[13] = "Viewer" trace:msiexec:main bug 9628: argv[14] = "2003" trace:msiexec:main bug 9628: argv[15] = "Setup(0004).txt DWMSILOGFILE=C:\windows\temp\Microsoft" trace:msiexec:main bug 9628: argv[16] = "Office" trace:msiexec:main bug 9628: argv[17] = "Excel" trace:msiexec:main bug 9628: argv[18] = "Viewer" trace:msiexec:main bug 9628: argv[19] = "2003" trace:msiexec:main bug 9628: argv[20] = "Setup(0004)_Task(0001).txt" Now this looks wrong to me. It looks like there is a bug in how the command line is being passed to msiexec. The existing code that parses this command line, is in fact working around this bug. Adding +process to the WINEDEBUG variable I got to see what CreateProcessA was calling msiexec with[1]: L"\"c:\\windows\\system32\\msiexec.exe\" /I C:\\windows\\temp\\IXP008.TMP\\XLVIEW.MSI CDCACHE=\"2\" LAUNCHEDFROMSETUP=\"1\" SETUPEXEPATH=\"C:\\windows\\temp\\IXP008.TMP\\\" SETUPEXENAME=\"SETUP.EXE\" /lpiwaeo \"C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup(0014)_Task(0001).txt\" CDCACHE=\"0\" DWSETUPLOGFILE=\"C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup(0014).txt\" DWMSILOGFILE=\"C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup(0014)_Task(0001).txt\"" 1. I also have to increase the debug str length in debug.c otherwise the end of the string would get dropped. Now when I run msiexec with the following command line msiexec /I C:\\windows\\temp\\IXP008.TMP\\XLVIEW.MSI CDCACHE="2" LAUNCHEDFROMSETUP="1" SETUPEXEPATH="C:\\windows\\temp\\IXP008.TMP\\" SETUPEXENAME="SETUP.EXE" /lpiwaeo "C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup(0014)_Task(0001).txt" CDCACHE="0" DWSETUPLOGFILE="C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup(0014).txt" DWMSILOGFILE="C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup(0014)_Task(0001).txt" I see the following appear in the traces from msiexec: trace:msiexec:main bug 9628: argv[0] = "programs/msiexec/msiexec.exe.so" trace:msiexec:main bug 9628: argv[1] = "/I" trace:msiexec:main bug 9628: argv[2] = "C:\windows\temp\IXP002.TMP\XLVIEW.MSI" trace:msiexec:main bug 9628: argv[3] = "CDCACHE=2" trace:msiexec:main bug 9628: argv[4] = "LAUNCHEDFROMSETUP=1" trace:msiexec:main bug 9628: argv[5] = "SETUPEXEPATH=C:\windows\temp\IXP002.TMP\" trace:msiexec:main bug 9628: argv[6] = "SETUPEXENAME=SETUP.EXE" trace:msiexec:main bug 9628: argv[7] = "/lpiwaeo" trace:msiexec:main bug 9628: argv[8] = "C:\windows\temp\Microsoft Office Excel Viewer 2003 Setup(0003)_Task(0001).txt" trace:msiexec:main bug 9628: argv[9] = "CDCACHE=0" trace:msiexec:main bug 9628: argv[10] = "DWSETUPLOGFILE=C:\windows\temp\Microsoft Office Excel Viewer 2003 Setup(0003).txt" trace:msiexec:main bug 9628: argv[11] = "DWMSILOGFILE=C:\windows\temp\Microsoft Office Excel Viewer 2003 Setup(0003)_Task(0001).txt" Which seems bang on with what msiexec should be getting as its commandline arguments. In fact the only way I could pass in the command line to msiexec and get the same output near the top was with the following: msiexec /I C:\\windows\\temp\\IXP002.TMP\\XLVIEW.MSI CDCACHE="2" LAUNCHEDFROMSETUP="1" SETUPEXEPATH="C:\\windows\\temp\\IXP002.TMP\" SETUPEXENAME="SETUP.EXE" /lpiwaeo "C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup\(0003\)_Task\(0001\).txt" CDCACHE="0" DWSETUPLOGFILE="C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup\(0003\).txt" DWMSILOGFILE="C:\\windows\\temp\\Microsoft Office Excel Viewer 2003 Setup\(0003\)_Task\(0001\).txt"" Notice the difference between the following: SETUPEXEPATH="C:\\windows\\temp\\IXP008.TMP\\" = correct command line SETUPEXEPATH="C:\\windows\\temp\\IXP002.TMP\" = broken It seems to me that current command line parsing in msiexec is a hack to work around a bug somewhere between CreateProcessA and where the executable actually gets run, when you have a directory path ending in a slash and also enclosed by quotes. It appears that one of the double slashes at the end gets substituted before its time. So basically, I'm wondering if I'm actually on the right track here. Is this a bug in the behaviour of how the command line is sent to the new process? I've yet to log a bug since I'm still trying to understand what exactly is happening and if this is in fact a bug. At the moment I trying to work out how to get more information on what's happening to the commandline in the create_process function, so I've yet to work out why the command line is altered by the time it reaches the msiexec program. Any suggestions are welcome. :) -- Darragh "Nothing is foolproof to a sufficiently talented fool."

Nov. 24, 2007

Re: WineD3D: Implement detection of ATI cards with Mesa DRI drivers [try 4]

by Roman Mamedov

Roderick Colenbrander wrote: > The main reason why the D3DX_CAPABLE macros should be used before checking the renderer string is that not in all cases all extensions are around while the rendering string can still be the same. I think it's is quite difficult to say for sure what will be better in most or all cases. The approach proposed by me, is that if the code can be reasonably sure that the card is some model from ATI, it should never report the card as being nVIDIA. That is why the patch first looks at the renderer strings (which for Mesa can provide a reliable indication if it's an ATI card at all, or not), and only then slides inside the model range for exact model, according to the extensions/capabilities available. And in case if some of them are not available for some reason, it will return a step-lower generation of an ATI card, and not nVIDIA one. I.e. reporting Radeon 9500 as being Radeon 8500 should be OK, but reporting it as GeForce 3 might be not, since a program might then use some nVIDIA-specific code, or just bail out completely (see issue #7267).

Nov. 23, 2007

Re: WineD3D: Implement detection of ATI cards with Mesa DRI drivers [try 4]

by Roderick Colenbrander

> Roderick Colenbrander wrote: > > I think the code should be like this (in pseudo code) this way also > other cards will at least be classified: > > > > case VENDOR_MESA: > > if(D3D9_CAPABLE(gl_info) > > if(strstr(gl_info->gl_renderer, "R300")) > > card = radeon_9500; > > else > > card = generic_nv_card; > > if(D3D8_CAPABLE(...) > > if(strstr(gl_info->gl_renderer, "R200")) > > card = ... > > > > You are right, but please notice that with my latest patch, the same > behavior is already achieved, by not "break"-ing at the end of > VENDOR_MESA case if we didn't match one of ATI module names. The main reason why the D3DX_CAPABLE macros should be used before checking the renderer string is that not in all cases all extensions are around while the rendering string can still be the same. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Nov. 23, 2007

Re: WineD3D: Implement detection of ATI cards with Mesa DRI drivers [try 4]

by Roman Mamedov

Roderick Colenbrander wrote: > I think the code should be like this (in pseudo code) this way also other cards will at least be classified: > > case VENDOR_MESA: > if(D3D9_CAPABLE(gl_info) > if(strstr(gl_info->gl_renderer, "R300")) > card = radeon_9500; > else > card = generic_nv_card; > if(D3D8_CAPABLE(...) > if(strstr(gl_info->gl_renderer, "R200")) > card = ... > You are right, but please notice that with my latest patch, the same behavior is already achieved, by not "break"-ing at the end of VENDOR_MESA case if we didn't match one of ATI module names. This is the code that proceeds to be executed then: ... break; } /* Card is probably one of the non-ATI cards which are also supported by Mesa. * Continue to the fallback behavior of VENDOR_WINE. */ case VENDOR_WINE: default: /* Default to generic Nvidia hardware based on the supported OpenGL extensions. The choice * for Nvidia was because the hardware and drivers they make are of good quality. This makes * them a good generic choice. */ gl_info->gl_vendor = VENDOR_NVIDIA; if(WINE_D3D9_CAPABLE(gl_info)) gl_info->gl_card = CARD_NVIDIA_GEFORCEFX_5600; else if(WINE_D3D8_CAPABLE(gl_info)) gl_info->gl_card = CARD_NVIDIA_GEFORCE3; else if(WINE_D3D7_CAPABLE(gl_info)) gl_info->gl_card = CARD_NVIDIA_GEFORCE; else if(WINE_D3D6_CAPABLE(gl_info)) gl_info->gl_card = CARD_NVIDIA_RIVA_TNT; else gl_info->gl_card = CARD_NVIDIA_RIVA_128; ...

Nov. 23, 2007

Re: WineD3D: Implement detection of ATI cards with Mesa DRI drivers [try 4]

by Roderick Colenbrander

> This is an updated version of my previous patch for the same purpose. > > The proposed code now uses the WINE_D3DX_CAPABLE macros instead of DRI > module names for guessing the exact card model which is to be returned. > The patch also no longer includes manual addition of an entry to the > ChangeLog. Thanks to Roderick Colenbrander and Stefan Dösinger for the > suggestions. I have tested and confirmed that this patch fixes the bug > #7267 (http://bugs.winehq.org/show_bug.cgi?id=7267 ) to the same extent > as the previous version of the patch did. I think the code should be like this (in pseudo code) this way also other cards will at least be classified: case VENDOR_MESA: if(D3D9_CAPABLE(gl_info) if(strstr(gl_info->gl_renderer, "R300")) card = radeon_9500; else card = generic_nv_card; if(D3D8_CAPABLE(...) if(strstr(gl_info->gl_renderer, "R200")) card = ... Roderick -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Nov. 23, 2007

Re: Start: Convert start to Unicode. [try7]

by Anatoly Lyutin

Dan Kegel wrote: > Anatoly, > thank you for working to fix "start" to work better for Unicode, > I should have done that originally. > > You are welcome. :) > But you seem to be having trouble getting the patch in, > so here's what little advice I can give: > > If there is any difference between versions of your patch, > you should describe it in the patch description. > Yes, I agree with you.I just have not done it yet, because I thought that if my patches were discussed in devel-lists there was no need for that. > If there isn't, you should call it a resend, rather than a new try. > I will surely do it. > - Dan > -- Best regards Anatoly Lyutin.

Nov. 23, 2007

re: Start: Convert start to Unicode. [try7]

by Dan Kegel

Anatoly, thank you for working to fix "start" to work better for Unicode, I should have done that originally. But you seem to be having trouble getting the patch in, so here's what little advice I can give: If there is any difference between versions of your patch, you should describe it in the patch description. If there isn't, you should call it a resend, rather than a new try. - Dan

Nov. 23, 2007