Hi everybody,
So as you all know I've been working on various bug fixes throughout wine, with my most significant contributions to date being MSI OLE automation support and implementation of http protocol support in urlmon. This involvement was driven by my initial experiences of getting a key program used by molecular biologists, Invitrogen's Vector NTI, to install on wine with a fairly convoluted shell script and submitting my first patch to fix a crash with this program; Dan Kegel helped me iron out this first patch a lot and furthermore his comments about how it'd be nice if such a complicated shell script was not necessary with wine got me started with my other patches and the rest, as they say, is history.
So why, you may ask, am I sending all this in an email to wine-devel? The short answer is that this is a shameless email to see if I might motivate someone to work on our winhelp implementation a bit, as it is currently completely useless with Vector NTI. This seems like a fairly significant task, and my obligations at school/work have recently kicked up quite a bit, making it unlikely I will be able to take it on anytime soon. However, I hope to motivate someone with these reasons:
(i) I feel like I've certainly been doing (and will continue to do) my part in helping out wine, and if this in any case motivates someone looking for a development direction I would certainly not object; and
(ii) My ultimate vision/goal has been to have Vector NTI run so well that I could approach Invitrogen and see if they might at the very least say something to that effect on their Web site ("add wine + linux as a supported platform"), if not package Vector NTI a la Google Picassa, which would be great publicity for wine. Also, as you can see from the comments on my ubuntuforums howto http://ubuntuforums.org/showthread.php?t=347095 for a lot of molecular biologists, Vector NTI is the only reason they have to dual-boot/use VMWare at all (full-disclaimer: this is not 100% true for myself). So you could help perhaps a fairly small but non-insignificant group of people by doing some work on winhelp.
Although Vector NTI is a rather large set of programs, currently I believe the only things keeping it from installing/working to a "gold" level according to winehq definitions are (i) winhelp and (ii) either MFC42 implementation (required for WSH to install properly; I suppose only a few functions prob are really required, but I'm not sure how good an idea having a very small stub MFC42 would be) or JScript support in wine. Either item in (ii) seems like a very significant undertaking, but (i) seems doable and prob. necessary for a lot of apps.
So anyhow just my attempt to influence someone to start working on winhelp. Sorry for cluttering your inboxes.
Misha
On 9/3/07, Misha Koshelev mk144210@bcm.edu wrote:
Hi everybody,
So as you all know I've been working on various bug fixes throughout wine, with my most significant contributions to date being MSI OLE automation support and implementation of http protocol support in urlmon. This involvement was driven by my initial experiences of getting a key program used by molecular biologists, Invitrogen's Vector NTI, to install on wine with a fairly convoluted shell script and submitting my first patch to fix a crash with this program; Dan Kegel helped me iron out this first patch a lot and furthermore his comments about how it'd be nice if such a complicated shell script was not necessary with wine got me started with my other patches and the rest, as they say, is history.
So why, you may ask, am I sending all this in an email to wine-devel? The short answer is that this is a shameless email to see if I might motivate someone to work on our winhelp implementation a bit, as it is currently completely useless with Vector NTI. This seems like a fairly significant task, and my obligations at school/work have recently kicked up quite a bit, making it unlikely I will be able to take it on anytime soon. However, I hope to motivate someone with these reasons:
(i) I feel like I've certainly been doing (and will continue to do) my part in helping out wine, and if this in any case motivates someone looking for a development direction I would certainly not object; and
(ii) My ultimate vision/goal has been to have Vector NTI run so well that I could approach Invitrogen and see if they might at the very least say something to that effect on their Web site ("add wine + linux as a supported platform"), if not package Vector NTI a la Google Picassa, which would be great publicity for wine. Also, as you can see from the comments on my ubuntuforums howto http://ubuntuforums.org/showthread.php?t=347095 for a lot of molecular biologists, Vector NTI is the only reason they have to dual-boot/use VMWare at all (full-disclaimer: this is not 100% true for myself). So you could help perhaps a fairly small but non-insignificant group of people by doing some work on winhelp.
Better winhelp is a goal of wine 1.0 (bug 664).
Although Vector NTI is a rather large set of programs, currently I believe the only things keeping it from installing/working to a "gold" level according to winehq definitions are (i) winhelp and (ii) either MFC42 implementation (required for WSH to install properly; I suppose only a few functions prob are really required, but I'm not sure how good an idea having a very small stub MFC42 would be) or JScript support in wine. Either item in (ii) seems like a very significant undertaking, but (i) seems doable and prob. necessary for a lot of apps.
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.
So anyhow just my attempt to influence someone to start working on winhelp. Sorry for cluttering your inboxes.
Misha
Damjan
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.
It would be unnecessary if software developers would check for needed .DLL's and install them if they are not present. This is not just a problem on wine. It occasionally arrises in Windows as well (although not as often). I recently bought a new laptop with Vista on it and was missing d3d9_30.dll for my Everquest game. EQ did not install it. Vista did not come with it. Neither did my default installation of direct X. I've seen this problem occur quite a few times on our guild's message board technical question section.
I wouldn't be too worried about the legal issue of using DLLs unless you were planning on using it for a business. If you are, then you should probably purchase a Windows license for each computer that has to use those DLLs. Waste of money, but when it comes to the corporate world, copyright infringement is taken much more seriously. Individuals who want to appease their conscience should just find a Linux equivalent of the needed program, use Windows, or just download the DLLs and not worry about it. If you're morrally opposed to taking DLLs, then you should be morrally opposed to simulating Windows to get Windows programs to run. A can of worms, I know. I just keep seeing this issue come up. I'm not a lawyer, but using Microsoft's DLLs in a wine installation doesn't seem any different than installing Windows media player, Internet Explorer or MS office into wine. Some applications won't work in wine without them. Even if you paid for office, Microsoft expects you to run it on a Windows machine. Mac will run windows now you say? Yes, but you have to purchase a copy of Windows to do so. What if a small company got started by agreeing to develop for Windows? (Don't know an example, but I wouldn't put it past MS to make deals like that.) Then you take their program and run it on wine therefore violating their agreement?
Anyway, I would examine the reason you're concerned about using the DLLs. Wine just doesn't bundle the needed DLLs because that would definately violate copy protection laws. It's an annoyance, but having someone develop a program like you suggest seems a little under the table. ;)
Am Montag, 3. September 2007 16:02:54 schrieb Charity Abbott:
I wouldn't be too worried about the legal issue of using DLLs unless you were planning on using it for a business. If you are, then you should probably purchase a Windows license for each computer that has to use those DLLs. Waste of money, but when it comes to the corporate world, copyright infringement is taken much more seriously.
Wine does target the corporate world, so we have to take extreme care not to violate the license of any single DLL. Microsoft would love a pretext to shut everything down.
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.
-
Charity Abbott -
Damjan Jovanovic -
Misha Koshelev -
Stefan Dösinger