[Wine] Arguments for Wine on windows/incremental adoption

James Mckenzie jjmckenzie51 at earthlink.net
Thu Dec 10 19:45:35 CST 2009


oiaohm wrote:
>
>Most if not all of the Userspace dll's already can build for windows if developers decide to use it.
>
Really?  Hmmm.  There is a lot of work left to fully support the Windows API.  I've been working on a RichEdit function for over a year now to get it to work like the WindowsXP version.  
>
>Wined3d also works on windows.   This is supported development by visualization software makers.
>
>Sorry to say wine has a bug for bug policy and is not really a platform in it own right.  Linking by default to wine dll's is not
>something that is recommended.
>
Correct.  Our 'bug for bug' policy is because some programs actually DEPEND on undocumented functionality build into certain versions of Windows.  If we 'fixed' these bugs, those programs would not function properly.  This is because of poor coding practices actually encouraged by Microsoft.
>
>Really we don't need to bother about wine dlls on windows platform.

>Reactos is a replacement NT core using wine dll's.

Since they do not fully follow a 'black box/white box' process, they may find themselves in legal hot water.  The Wine project cannot use any of the contributed code from this project because of their failure to do this.
As an example, Heath decided to create an IBM clone.  They dug through the BIOS code.  Their clone was pulled from the marketplace at the insistance of the U.S. Court system.  Tandy decided to watch what the BIOS was doing and found that the system had to have the letters IBM in a certain location.  Once this was overcome, Tandy (now Phoenix) made a better BIOS with increased functions, including the ability to 'shadow' in memory the entire contents of the BIOS.  This made extended/expanded memory possible.  If Tandy had not done this we just might have two choices for a high price very slow PC:  IBM and Apple.  We want folks to have a choice in operating systems, Windows and UNIX (Linux is basically another type of UNIX, Linus has stated this on many occasions.)

>So far they are not including 16 bit support.

NT in its first iterations did not either.  That was what Windows 3.1 and Windows 3.11 (Networking) was for.  Most programs are now 32 bit, but there are a few Windows 3.1/3.11 programs that companies still rely on that there are no replacements for in the 32 bit world.  Also, NT was basically a server OS (I was at one of the NT 3.5.1 beta sites and it ran dog slow on a 16MB system, which was high end for 1994/1995.)

>Important thing here why should wine run on windows so providing windows with the same compatibility as wine + windows own?  Doing
>so would undermine Reactos's efforts and any one else lining up to clone windows.

And why should we care what Reactos is up to?  Our position is to provide the Windows API on any UNIX type environment, not to provide a replacement for Windows.  The latter may make everyone who works/worked on this project subject to the Lion of Redmond.  United we stand, but individually, in court, we don't stand a chance.  Because Microsoft has stated it will not support Linux in any form, makes them have to provide case law that supports us.  The SCO situation proves that they don't have all of the information they need....And they are still going after RedHat and a few others (Novell signed an agreement that keeps SuSe out of the legal fray, but SuSe is delibrately broken so that OpenOffice.org will not or should not run on it.)

>
>Reactos are working on support for MS compilers and build envorment.   Wine only worries itself about gcc.  So why duplicate effort
>with Reactos?   
>
See my long winded explanation above or maybe I can shorten it.  In the United States, what ReactOS is doing is illegal.  Simple fact that this may be found by the E.U. courts.  Attempting to duplicate the functionality of an object by observing what it does to data is a long standing and legal method, breaking apart code is not, except for testing and evaluation.  This is what security folks do.  They look at code for possible problems and then advise companies on how to fix it.  We use Coventry for this function and we have been somewhat quick at fixing buffer overflows and other coding problems.  Wine is so good that some known userspace virii will run on it and inflict damage as if we were running Windows.  This has been cause for concern, but Linux tends to limit the damage to the user's available work area.
>
>Wine better game compatibility in places brings users to Linux Solaris BSD and Mac.   Why should we undermine this?
>
That is NOT what the Wine project is about.  We are not just aiming at the gaming community.  We want Wine used in productin systems running business software products.  A game may bring on a million users, but the ability to run Office 2007 might bring on 100 Million.  Which would you want?  I'd go for both, but if I can get the second set, that is much better.  The bottom line is that we are out to duplicate the Windows API, bugs and all, for a specific version of Windows.  Right now, that version appears to be Windows XP SP3, which is the most popular and installed version of Windows.  Duplicating Windows code, line for line, should not and is not the purpose of this project and may cause legal issues.
>
>Next is doing what you describe would also undermine people from making cross platform code.   So giving MS always the advantages.
>One dll at a time so what MS just releases more dlls more incompatibility you get no where.
>
You just hit upon the subject of one of my previous messages.  Microsoft will keep the dll functionality fluid enough so that they can break this project at any time.  I will add this statement to give you some idea of what they attempted to do in the mid-1980s:

"DOS is not done until Lotus will not run".  During that timeframe, Microsoft and Lotus provided competing products.  The folks at Redmond have a track record of causing breakages in code that have caused their competitors to go to U.S. Federal Court and receive monies for Microsoft's apparent anti-competitive tendencies.  What do you think they could do to a project like Wine if they decided it was worth it?  Remember, Microsoft MUST maintain its current status or face reprecussions from its stockholders.  This project has no such requirement and we have very few stakeholders.  We do have a company that provides commercial support and a lot of development effort, but not at the level that Microsoft has.
>
>Somehow you are making a major mistake here.   Wine is not about existing long term.   Wine is about being a stop gap for
>applications you cannot get any other way.
>
Really, you have proof of this?  I have proof of the exact opposite.  This project is over ten years old, which is a long time in the computer world.  I expect it to be around for a long time.  There will be Windows programs that will NEVER, EVER be ported into MacOSX versions, let alone UNIX versions.  Sure there are Java programs, but most of them are at the server level and programs that the average user will never see.
>
>If every application that people wanted was released for Linux and other platforms wine would cease to exist.  This is the
>preferred outcome for most wine supporting people.
>
Nice pipe-dream as well.  As I said, there will never be certain programs for Linux.  That is a fact.  
>
>Really better support for items like QT and KDE inside wine is a far better way forward.  Make it more profitable for developers to
>use cross platform toolkits in the first place avoiding the complete windows problem.
>
And there are functions in .NET that QT and KDE will never have.  Think about this:  90+ of all computers, world-wide run Windows, even Macs.  Less than 1% run Linux and most of them are servers.  Which audience would YOU go for?  The one that is going to make you lots of money or the one that isn't?  Not a question for a Rocket Scientist here.  Now, add in Wine and a fully qualified Windows API plus the ability to add .NET and you have a winner.  Again, there are programs that are never going to be built for Linux.  Not now, not tomorrow, NEVER.  And programmers familiar with .NET are not going to go out and learn QT, TCL/TK or any other 'fancy' interface because of the low numbers in the target audience.  Even Apple has problems with folks learning to use Aqua/Cocoa and they have about an 8% world-wide usage audience.  They provide a toolkit to map .NET code to Cocoa code for major program manufacturers, like Adobe and even Microsoft.
>
Maybe what I should say here is that Linux is thought of as somewhat of a joke.  However, I know differently.  Windows is a real pain to maintain and keep secure.  That is why I use a Mac.  I've not used Windows as my major operating system since 1992, when OS/2 2.0 was released.  Sadly, IBM threw in the gauntlet in 2000.  That is when I switched to RedHat Linux.  Sadly, RedHat went 'commercial' in 2003 and I switched to Fedora (big mistake there folks, it is and remains a wide beta test for Red Hat).  I've used CentOS, Ubuntu, Madrivia (aka Slackware/Debian), and Knoppix.  I then switched to MacOSX.  It appears that Apple has polished Free/Open BSD with a really good, user friendly front-end (something that Windows Vista and Windows 7 wants to be) without the back-end problems that have plagued Windows since Windows 2.0 (yes, folks I go that far back.)  I really wish that Linux would take off and that programmers would see the benefits for programming to it as well as MacOSX.  However, when you have to feed/house/clothe the family, you are going to go where the money is.  That is Microsoft .NET programming.  So, Wine needs to keep on going towards full Windows API functionality and NOT be a replacement for a seriously broken 'operating system'.

Wine + UNIX is what we really need.

We need to replicate the entire Windows API, 16, 32 and 64 bitness.  Across all hardware platforms, across many hardware configurations.  We need to be what Windows should be.  Solid, robust and foolproof.  (I know that two of the three are possible, the third will take some doing.)  We need to replicate all userspace functions.  We DO NOT need to be ReactOS or the Unified Kernel.  They are projects that are in legal hot water and may die the first time the folks from Redmond pay them a visit (and believe me, that is one scary place to be.)  

So, we need to be a better Windows than Windows, even running on Windows.  

Sorry for the long rant, but we've been here before.  Let's all work towards full API functionality and leave the replacements to others.

James McKenzie




More information about the wine-users mailing list