September 2007 - Wine-Devel

Kudos - Fireworks 8 working better...

by Dan Kegel

http://www.5thpercentile.com/devBlog/archives/2007/09/wine_just_got_t.html and http://appdb.winehq.org/appview.php?iVersionId=4149&iTestingId=15163 both say that wine-0.9.44 really improves Adobe Fireworks. Yay! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Sept. 6, 2007

Re: ddraw/tests: Check deviceGUID of enumerated devices.

by David Hedberg

Ah, I thought this was going a bit too well ;) I'll fix the issues and send it in again. Regarding a fix, would something as simple as the following be acceptable? (in dlls/ddraw/direct3d.c) @@ -263,6 +263,12 @@ IDirect3DImpl_7_EnumDevices(IDirect3D7 *iface, return hr; } Callback(interface_name, device_name, &ddesc, Context); + + ddesc.deviceGUID = IID_IDirect3DHALDevice; + Callback(interface_name, device_name, &ddesc, Context); + + ddesc.deviceGUID = IID_IDirect3DRGBDevice; + Callback(interface_name, device_name, &ddesc, Context); [..] If so, I'll wrap it up together with the tests. Thanks for the guidance, David On 9/7/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Donnerstag, 6. September 2007 16:02:59 schrieb David Hedberg: > > This patch adds tests to check the devices enumerated by > > IDirect3D7_EnumDevices . At least two games rely on the behavior > > tested by one of the test in this patch. > If wine behaves incorrectly and your test fails on wine, you have to send a > fix before or in the same patch as the test. Alexandre has some scripts that > run the conformance tests after each patch and refuses all patches that cause > in test failures. > > If you do not know how to fix the bug, or want to keep it unfixed for some > other reason(e.g. the incorrect behavior is hard to fix and considered > harmless), then you can mark the test as todo_wine. Then the tests script > will ignore failures in the test. However, Alexandre will drop a note and ask > for further explanation if a test marked todo_wine succeeds(e.g. we had a > test that succeeded or failed for some time based on the features graphics > driver). > > todo_wine test(2 + 2 == 3.99998, "This is my test marked as TODO\n"); /* > Microsoft does something insane here */ > > Other things: > + if(!memcmp(&lpdd7->deviceGUID, &IID_IDirect3DRGBDevice, > sizeof(IID_IDirect3DRGBDevice))) > > You can use IsEqualGUID here. Sorry for not spotting this earlier. > > + IDirect3D7_EnumDevices(lpD3D, (LPD3DENUMDEVICESCALLBACK7) > enumDevicesCallbackTest7, &d3d7et); > To get more compiler checks, you shouldn't cast the function to the right > type, but use void *d3d7et, and cast it to the right pointer in your > function. Debugging a wrong function pointer is a nasty thing ;-) > > >

Sept. 6, 2007

Re: problem with silly CreateBitmap call

by Francois Gouget

On Thu, 6 Sep 2007, Deun wrote: [...] > The size of the bitmap seems crazy... So I've made a patch to > fix this in bitmap.c by setting 1x1 size in case of stupid > input instead of failing with BadAlloc. However, since it works > fine on real windows, so I'm not sure about the behaviour that > the function should have. Seems like a good candidate for a conformance test. Call the API with the crazy values and see what comes out... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.

Sept. 6, 2007

RE: problem with silly CreateBitmap call

by Deun

Hi, I know that my patch was ugly, but since the program doesn't crash there's no stack trace : it exits quietly on the X Error message... Since the program seems to load lots of images, if I run it with winedbg it will take ages before reaching the bad one, it was the purpose of my patch to provide a line where a breakpoint can be put to catch the case... But since I'm not (yet) a wine guru, all I can do is provide the way to catch the case with a lousy patch and the link to the game (which is free, but it's still in japanese only) : http://download.mk-style.com/ccmedia/PW/Install_PW.exe (it's around 2.5G big) You even don't need to create an account, starting the client after install is enough to meet the problem... On a side note, there's a crash later in the game after selecting character and entering the world, but that's another story... Regards, Denis Huguet. --- Rolf Kalbermatter <r.kalbermatter(a)hccnet.nl> wrote: > Deun wrote on Thursday, September 06, 2007 10:40 AM > > >trace:x11drv:X11DRV_CreateBitmap (0xed4) > 2147483646x2147483646 > >1 bpp > >X Error of failed request: BadAlloc (insufficient resources > for operation) > > Major opcode of failed request: 53 (X_CreatePixmap) > > Serial number of failed request: 3155 > > Current serial number in output stream: 3163 > > > >This occured after an attempt to load a bmp file that can't > be found > anywhere. > > > >The size of the bitmap seems crazy... So I've made a patch > to fix this in > >bitmap.c by setting 1x1 size in case of stupid input instead > of failing > with > >BadAlloc. However, since it works fine on real windows, so > I'm not sure > about > >the behaviour that the function should have. However this > patch let me run > >the game now : > > First your patch is not very useful as the diff was run from > inside the > directory > where the two files where, instead of from the main wine > directory. So the > patch > does not contain the necessary full project path for the > patch maintainer to > apply > It without guessing, which he won't do without some very > compelling reasons. > > But the more serious problem is that it is really just a hack > and as such > won't > get into wine. Trapping on some arbitrary size is not an > acceptable patch > for > Wine. Instead the root cause should be found. > > Since you say that this comes from trying to load a bitmap > that can be > nowhere > found I wonder if this is the result of some unitialized > structures that > result > in garbage but somehow the loading is not aborted with an > error for whatever > reasons but just passed further to X11DRV_CreateBitmap with > whatever garbage > happened to be in memory and here probably on the stack. > > I see two possibilities and they both are likely to be fixed > in the actual > caller of X11DRV_CreateBitmap instead of in this function > itself: > > 1) Wine code has a bug and should not ever attempt to call > X11DRV to create > the bitmap after it couldn't find the according file on disk > to initialize > the > bitmap members. Instead that function should just return to > the caller with > an error. > > 2) Windows allows to load a nonexisting bitmap file and > returns in that case > a default bitmap, brush or whatever without causing an error. > In that case > the structure should be either initialized to some meaningful > values like > a 0 * 0 or 1 * 1 bitmap before attempting to load the file > from disk and > when the load fails just fall through to create that default > bitmap or on > failure of the loading some special code needs to be executed > to create > whatever Windows returns here. > > So in any case I think you need to figure out from which > function exactly > X11DRV_CreateBitmap is called with these silly parameters and > concentrate > on fixing that one instead. Your patch is still very likely > to crash on a > 0x7e000000 * 0x7e000000 bitmap and therefore didn't adress > the root cause > of this problem. > > Not knowing anything about the stack trace it is completely > impossible for > anyone not running that application to look for the likely > cause of this > problem as there are quite a few functions in Wine that call > X11DRV_CreateBitmap somewhere and somehow. > > Rolf Kalbermatter > > ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting

Sept. 6, 2007

Re: ddraw/tests: Check deviceGUID of enumerated devices.

by Stefan Dösinger

Am Donnerstag, 6. September 2007 16:02:59 schrieb David Hedberg: > This patch adds tests to check the devices enumerated by > IDirect3D7_EnumDevices . At least two games rely on the behavior > tested by one of the test in this patch. If wine behaves incorrectly and your test fails on wine, you have to send a fix before or in the same patch as the test. Alexandre has some scripts that run the conformance tests after each patch and refuses all patches that cause in test failures. If you do not know how to fix the bug, or want to keep it unfixed for some other reason(e.g. the incorrect behavior is hard to fix and considered harmless), then you can mark the test as todo_wine. Then the tests script will ignore failures in the test. However, Alexandre will drop a note and ask for further explanation if a test marked todo_wine succeeds(e.g. we had a test that succeeded or failed for some time based on the features graphics driver). todo_wine test(2 + 2 == 3.99998, "This is my test marked as TODO\n"); /* Microsoft does something insane here */ Other things: + if(!memcmp(&lpdd7->deviceGUID, &IID_IDirect3DRGBDevice, sizeof(IID_IDirect3DRGBDevice))) You can use IsEqualGUID here. Sorry for not spotting this earlier. + IDirect3D7_EnumDevices(lpD3D, (LPD3DENUMDEVICESCALLBACK7) enumDevicesCallbackTest7, &d3d7et); To get more compiler checks, you shouldn't cast the function to the right type, but use void *d3d7et, and cast it to the right pointer in your function. Debugging a wrong function pointer is a nasty thing ;-)

Sept. 6, 2007

Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite

by Vincent Povirk

It appears Wine's SHCreateDirectoryEx is the same as Windows XP in the way that matters to me: both return ERROR_ALREADY_EXISTS whether the thing that already exists is a file or a directory. I haven't found a situation where either version returns ERROR_FILE_EXISTS. On 9/2/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Vincent Povirk" <madewokherd+d41d(a)gmail.com> wrote: > > > Well, I COULD do that if SHCreateDirectoryExW worked the way the Wine > > API docs claim. It seems to be returning ERROR_ALREADY_EXISTS even > > when the thing that already exists is a file and not a directory. > > Then it needs a separate test case and a fix. > > -- > Dmitry. > -- Vincent Povirk

Sept. 6, 2007

Re: problem with silly CreateBitmap call

by Jesse Allen

On 9/6/07, Rolf Kalbermatter <r.kalbermatter(a)hccnet.nl> wrote: > > Since you say that this comes from trying to load a bitmap that can be > nowhere > found I wonder if this is the result of some unitialized structures that > result > in garbage but somehow the loading is not aborted with an error for whatever > reasons but just passed further to X11DRV_CreateBitmap with whatever garbage > happened to be in memory and here probably on the stack. > In testing the dib engine I found that I could pass in corrupt bitmaps to the LoadImage function and wine would attempt to load it. I can't remember the details exactly but I knew that it would not exactly fail, while all image programs and windows itself didn't like the bitmaps. There are some conformance issues there that I do not have time to research. I do not think this problem is exactly related to LoadImage, but however it might be having to do with uninitialized structures like you say so I still suggest to trace the problem to the original call. Jesse

Sept. 6, 2007

RE: problem with silly CreateBitmap call

by Rolf Kalbermatter

Deun wrote on Thursday, September 06, 2007 10:40 AM >trace:x11drv:X11DRV_CreateBitmap (0xed4) 2147483646x2147483646 >1 bpp >X Error of failed request: BadAlloc (insufficient resources for operation) > Major opcode of failed request: 53 (X_CreatePixmap) > Serial number of failed request: 3155 > Current serial number in output stream: 3163 > >This occured after an attempt to load a bmp file that can't be found anywhere. > >The size of the bitmap seems crazy... So I've made a patch to fix this in >bitmap.c by setting 1x1 size in case of stupid input instead of failing with >BadAlloc. However, since it works fine on real windows, so I'm not sure about >the behaviour that the function should have. However this patch let me run >the game now : First your patch is not very useful as the diff was run from inside the directory where the two files where, instead of from the main wine directory. So the patch does not contain the necessary full project path for the patch maintainer to apply It without guessing, which he won't do without some very compelling reasons. But the more serious problem is that it is really just a hack and as such won't get into wine. Trapping on some arbitrary size is not an acceptable patch for Wine. Instead the root cause should be found. Since you say that this comes from trying to load a bitmap that can be nowhere found I wonder if this is the result of some unitialized structures that result in garbage but somehow the loading is not aborted with an error for whatever reasons but just passed further to X11DRV_CreateBitmap with whatever garbage happened to be in memory and here probably on the stack. I see two possibilities and they both are likely to be fixed in the actual caller of X11DRV_CreateBitmap instead of in this function itself: 1) Wine code has a bug and should not ever attempt to call X11DRV to create the bitmap after it couldn't find the according file on disk to initialize the bitmap members. Instead that function should just return to the caller with an error. 2) Windows allows to load a nonexisting bitmap file and returns in that case a default bitmap, brush or whatever without causing an error. In that case the structure should be either initialized to some meaningful values like a 0 * 0 or 1 * 1 bitmap before attempting to load the file from disk and when the load fails just fall through to create that default bitmap or on failure of the loading some special code needs to be executed to create whatever Windows returns here. So in any case I think you need to figure out from which function exactly X11DRV_CreateBitmap is called with these silly parameters and concentrate on fixing that one instead. Your patch is still very likely to crash on a 0x7e000000 * 0x7e000000 bitmap and therefore didn't adress the root cause of this problem. Not knowing anything about the stack trace it is completely impossible for anyone not running that application to look for the likely cause of this problem as there are quite a few functions in Wine that call X11DRV_CreateBitmap somewhere and somehow. Rolf Kalbermatter

Sept. 6, 2007

WineHQ Upgrade Downtime

by Jeremy Newman

On Wednesday Sept 12 at 14:00 US Central Time, we will be taking all of WineHQ offline for maintenance and upgrades. The server itself will offline for about an hour. Some services will be offline longer than that as we adjust/fix them to the upgraded server.

Sept. 6, 2007

Re: Wine on 64bit system crashes (critical)

by Roderick Colenbrander

> > Hi, > > > > One of my development machines is a dualcore Athlon64 using a 64bit > > version of Debian. I have been using this system for months and it > always worked > > fine. Since I hadn't used the system during the summer it contained an > > older Wine version. > > > > I have upgraded it to the latest GIT version and Wine doesn't work > > anymore. It doesn't just crash, but it locks up the whole system. I have > no idea > > what causes it. I for instance ran Wine some time before as root (I > really > > had to be root at that time) and for the root user it didn't lock up > until I > > wanted to run a fresh .wine directory. > > > > I can't really test what caused it as testing this takes a lot of time > and > > I can't use a bad filesystem or so on this system. On irc a ubuntu64 > user > > said he had similar problems using Wine 0.9.44 but for him it 'only' > > segfaulted. Perhaps there is a connection between the problems. > > > > Has anyone recently seen problems like this? It prevents me from playing > > with Wine code at the moment. > > > > Roderick > > A debian dist-upgrade 'fixed' the problem. I have no idea to what wine was > sensitive. > > Roderick So now and then I'll still have the problem. I'll see if I can make a +all log of it. Roderick -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Sept. 6, 2007

Re: problem with silly CreateBitmap call

by Jesse Allen

On 9/6/07, Deun <deun76(a)yahoo.com> wrote: > Hi, > > I've tried the free-to-play MMORPG game called Perfect World ( > http://perfect-w.jp ) with wine 0.9.44 and it installs fine. > However, when running it often crashed with the following error > in the x11drv traces : > > trace:x11drv:X11DRV_CreateBitmap (0xed4) 2147483646x2147483646 > 1 bpp > X Error of failed request: BadAlloc (insufficient resources > for operation) > Major opcode of failed request: 53 (X_CreatePixmap) > Serial number of failed request: 3155 > Current serial number in output stream: 3163 > > This occured after an attempt to load a bmp file that can't be > found anywhere. > > The size of the bitmap seems crazy... So I've made a patch to > fix this in bitmap.c by setting 1x1 size in case of stupid > input instead of failing with BadAlloc. However, since it works > fine on real windows, so I'm not sure about the behaviour that > the function should have. Look at the +bitmap debug channel, or others and trace to the original call's parameters. Figure out how the app is wanting to create the bitmap and write a test case for it and test on windows and wine. Jesse

Sept. 6, 2007

Re: olethk32.dll

by Juan Lang

Hi Stefan, + if (fdwReason == DLL_PROCESS_ATTACH) + DisableThreadLibraryCalls(hinstDLL); + + return TRUE; You should probably add a DLL_WINE_PREATTACH case that returns FALSE. --Juan

Sept. 6, 2007

Re: Wine on 64bit system crashes (critical)

by Roderick Colenbrander

> Hi, > > One of my development machines is a dualcore Athlon64 using a 64bit > version of Debian. I have been using this system for months and it always worked > fine. Since I hadn't used the system during the summer it contained an > older Wine version. > > I have upgraded it to the latest GIT version and Wine doesn't work > anymore. It doesn't just crash, but it locks up the whole system. I have no idea > what causes it. I for instance ran Wine some time before as root (I really > had to be root at that time) and for the root user it didn't lock up until I > wanted to run a fresh .wine directory. > > I can't really test what caused it as testing this takes a lot of time and > I can't use a bad filesystem or so on this system. On irc a ubuntu64 user > said he had similar problems using Wine 0.9.44 but for him it 'only' > segfaulted. Perhaps there is a connection between the problems. > > Has anyone recently seen problems like this? It prevents me from playing > with Wine code at the moment. > > Roderick A debian dist-upgrade 'fixed' the problem. I have no idea to what wine was sensitive. 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

Sept. 6, 2007

re: nhelp, Vector NTI, molecular biologists

by Stephan Rose

On Thu, 2007-09-06 at 06:17 -0700, Dan Kegel wrote: > Misha wrote: > > and even my version of Windows 98 is bundled with mfc42.dll, so wine really should > > provide it too... [our own version, not Microsoft's.] > > Well, sure. Same goes for a lot of things. But > since mfc42.dll is a Visual C++ runtime file that > has very liberal redistribution terms and is in fact > bundled with many apps, we can get away without > it for a long time. And it's not currently a showstopper > as far as I can tell; I'm more interested in the bugs that > keep e.g. Photoshop from running flawlessly. > > So one of these days it might become a priority. > Until then, it's merely important but not urgent. > - Dan I feel for the poor soul that will implement MFC. Using MFC is horrible enough...but actually *implementing* that?? Good luck! =) Stephan

Sept. 6, 2007

Re: Wine on 64bit system crashes (critical)

by Dmitry Timoshkov

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> wrote: > One of my development machines is a dualcore Athlon64 using a 64bit version > of Debian. I have been using this system for months and it always worked > fine. Since I hadn't used the system during the summer it contained an older > Wine version. > > I have upgraded it to the latest GIT version and Wine doesn't work anymore. > It doesn't just crash, but it locks up the whole system. I have no idea what > causes it. I for instance ran Wine some time before as root (I really had to > be root at that time) and for the root user it didn't lock up until I wanted > to run a fresh .wine directory. > > I can't really test what caused it as testing this takes a lot of time and > I can't use a bad filesystem or so on this system. On irc a ubuntu64 user > said he had similar problems using Wine 0.9.44 but for him it 'only' > segfaulted. Perhaps there is a connection between the problems. > > Has anyone recently seen problems like this? It prevents me from playing > with Wine code at the moment. I'm using 64-bit Ubuntu 7.04 on an Intel Core2 Duo with SMP kernel for Wine development every day, and had never seen such a problem. -- Dmitry.

Sept. 6, 2007

Wine on 64bit system crashes (critical)

by Roderick Colenbrander

Hi, One of my development machines is a dualcore Athlon64 using a 64bit version of Debian. I have been using this system for months and it always worked fine. Since I hadn't used the system during the summer it contained an older Wine version. I have upgraded it to the latest GIT version and Wine doesn't work anymore. It doesn't just crash, but it locks up the whole system. I have no idea what causes it. I for instance ran Wine some time before as root (I really had to be root at that time) and for the root user it didn't lock up until I wanted to run a fresh .wine directory. I can't really test what caused it as testing this takes a lot of time and I can't use a bad filesystem or so on this system. On irc a ubuntu64 user said he had similar problems using Wine 0.9.44 but for him it 'only' segfaulted. Perhaps there is a connection between the problems. Has anyone recently seen problems like this? It prevents me from playing with Wine code at the moment. 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

Sept. 6, 2007

re: nhelp, Vector NTI, molecular biologists

by Dan Kegel

Misha wrote: > and even my version of Windows 98 is bundled with mfc42.dll, so wine really should > provide it too... [our own version, not Microsoft's.] Well, sure. Same goes for a lot of things. But since mfc42.dll is a Visual C++ runtime file that has very liberal redistribution terms and is in fact bundled with many apps, we can get away without it for a long time. And it's not currently a showstopper as far as I can tell; I'm more interested in the bugs that keep e.g. Photoshop from running flawlessly. So one of these days it might become a priority. Until then, it's merely important but not urgent. - Dan

Sept. 6, 2007

Re: IDirect3DImpl_EnumDevices only enumerating IID_IDirect3DTnLHalDevice

by Stefan Dösinger

Am Mittwoch, 5. September 2007 17:05:19 schrieb David Hedberg: > I've implemented a small test here, but to be honest I'm not really > sure what to test for :) > > The current test only tests what the game in question seems to rely > on, which is that TnLHalDevice should never be the only device > enumerated by IDirect3D7_EnumDevices. > > In addition to this, I think it's "reasonably possible" to make two > additional assumptions, which is that RGBDevice is always and > enumerated, and that if there is a TnlHal device, a Hal device is also > present. Should I add such tests based on my assumptions (and limited > test runs) only? Your test so far looks good, but I think your two additional assumptions sound sane too. You could extend your test with them and post the test on wine-devel, asking people to run it on different Windows drivers. Or just send them to wine-patches, there are automatic tests, if your tests fail we'll see that on the result pages.

Sept. 6, 2007

Re: winhelp, Vector NTI, molecular biologists

by Misha Koshelev

On Wed, 2007-09-05 at 19:40 -0500, Misha Koshelev wrote: > On 9/4/07, Alexander Sornes wrote: > > Tirsdag 04 september 2007 03:17, skrev Misha Koshelev: > > > On 9/3/07, Stefan Dosinger wrote: > > > > Am Montag, 3. September 2007 13:30:57 schrieb Damjan Jovanovic: > > > > > Somebody needs to make a do-nothing-useful app, intended for Windows, > > > > > that also installs on wine and supplies each and every DLL that > > > > > Windows applications need but we don't have in wine (like MFC42.DLL, > > > > > the D3DX9_xx.DLL's, new MSVCRT's, etc.). That way we can legally use > > > > > those DLLs without a Windows licence. > > > > > > > > This is not necessarily true. I don't know about MFC42.dll or the > > > > msvcrts, but the directx eula does not allow that; It requires the > > > > application to run only on the Microsoft Windows operating system, > > > > targetting both Windows and Linux+Wine violates the contract. These are > > > > the conditions for distributing the directx dlls. I've not found anything > > > > against installing them on Wine, you just must not distribute the DLLs > > > > with an app that targets both Windows and Wine. Thus I think it's legal > > > > to write a script that downloads them from the original location > > > > @microsoft.com and installs them, as long as that script isn't bundled > > > > with the dlls. However, IANAL. > > > > > > > > What remains unanswered though is how this affects game vendors whose > > > > games run on Wine without intention from the game vendor and ship the > > > > dlls, e.g. Eve Online. > > > > > > Actually you all bring up rather interesting points with regards to Vector > > > NTI as: > > > > > > (a) It pretty much ships with almost every Microsoft redistributable needed > > > (e.g., MDAC, Windows Script, MFC71, etc.) and installs them on its > > > installation _except_ MFC42 (not sure why this oversight and if this would > > > break it on some native system, although I _believe_ it installed correctly > > > on my plain vanilla Win98 VMWare installation, but I would have to double > > > check for sure). > > > > > > > I believe mfc42 is bundled with Windows XP. > Actually, I just reinstalled Windows 98 in VMWare _without_ installing VMWare tools > and even my version of Windows 98 is bundled with mfc42.dll, so wine really should > provide it too... Oh yeah and before this starts a discussion about legalities I meant we should provide our own version, not Microsoft's. > > > > > > (b) If the licenses for those DLLs/redistributables are the same as you > > > suggest for DirectX, this would mean they couldn't ever say they support > > > Wine (but I'm not sure whether or not the licenses are). Anyway, seeing it > > > work "gold" on Wine still wouldn't be a bad thing in either case and > > > certainly Vector NTI is not the only program that needs good winhelp > > > support. > > > > > > Misha > > > Misha

Sept. 5, 2007

Re: winhelp, Vector NTI, molecular biologists

by Misha Koshelev

On 9/4/07, Alexander Sornes wrote: > Tirsdag 04 september 2007 03:17, skrev Misha Koshelev: > > On 9/3/07, Stefan Dosinger wrote: > > > Am Montag, 3. September 2007 13:30:57 schrieb Damjan Jovanovic: > > > > Somebody needs to make a do-nothing-useful app, intended for Windows, > > > > that also installs on wine and supplies each and every DLL that > > > > Windows applications need but we don't have in wine (like MFC42.DLL, > > > > the D3DX9_xx.DLL's, new MSVCRT's, etc.). That way we can legally use > > > > those DLLs without a Windows licence. > > > > > > This is not necessarily true. I don't know about MFC42.dll or the > > > msvcrts, but the directx eula does not allow that; It requires the > > > application to run only on the Microsoft Windows operating system, > > > targetting both Windows and Linux+Wine violates the contract. These are > > > the conditions for distributing the directx dlls. I've not found anything > > > against installing them on Wine, you just must not distribute the DLLs > > > with an app that targets both Windows and Wine. Thus I think it's legal > > > to write a script that downloads them from the original location > > > @microsoft.com and installs them, as long as that script isn't bundled > > > with the dlls. However, IANAL. > > > > > > What remains unanswered though is how this affects game vendors whose > > > games run on Wine without intention from the game vendor and ship the > > > dlls, e.g. Eve Online. > > > > Actually you all bring up rather interesting points with regards to Vector > > NTI as: > > > > (a) It pretty much ships with almost every Microsoft redistributable needed > > (e.g., MDAC, Windows Script, MFC71, etc.) and installs them on its > > installation _except_ MFC42 (not sure why this oversight and if this would > > break it on some native system, although I _believe_ it installed correctly > > on my plain vanilla Win98 VMWare installation, but I would have to double > > check for sure). > > > > I believe mfc42 is bundled with Windows XP. Actually, I just reinstalled Windows 98 in VMWare _without_ installing VMWare tools and even my version of Windows 98 is bundled with mfc42.dll, so wine really should provide it too... > > > (b) If the licenses for those DLLs/redistributables are the same as you > > suggest for DirectX, this would mean they couldn't ever say they support > > Wine (but I'm not sure whether or not the licenses are). Anyway, seeing it > > work "gold" on Wine still wouldn't be a bad thing in either case and > > certainly Vector NTI is not the only program that needs good winhelp > > support. > > > > Misha > Misha

Sept. 5, 2007