Slashdot Mirror

Make no mistake, while Wine is getting damn good it is not perfect or even practical for all Windows software. Some software will probably never run under it, most will not run without some tweaking, so don't expect it to. OTOH, if you tried Wine even as late as a few months ago you might be surprised how things have changed. It all depends on what you 'need' to run.

Many of the main Wine sites have reviews of software and what works -- or how to get it to work. Keep in mind that if a comment is old, even a few weeks, it may not apply to the latest version of Wine. Usually this is a good thing, though some regressions do happen, so you might need a specific 'vintage' for a specific application.

That said, here's a good list;

1. Frank's Corner -- always deserves a mention

   The official Wine Application Database sponsored by Codeweavers

   Transgaming's WineX game list and search engine

   Wine Headquarters -- also sponsored by Codeweavers -- is the main Wine site and has the detailed and oft quoted FAQ-o-Matic

For more information, check the links on any of these sites.

Yeah, it's been fixed for a few days now, by this patch.

I find that I have no need for op-code compatability, so long as I have source code compatability. GCC can take the same source file, and make it run on nearly any processor. (Any reasonable processor really, but if I don't qualify it someone will ask about 6502 support)

I care about how fast the processor is running my apps. x86, Sparc, MIPS, alpha, come to mind as reasonable processors to consider, all will meet my needs just fine.

Well, there is an exception, I have wine installed so in theory I can run some programs only if I have binary compatability. In practice I rarely do that. Rarely enough that the few times I want to do it I can just ssh over to an x86 machine that I can pick up dirt cheap, and magicly the program will run on my other machine. (And most people won't know that I had to do a little magic to make it work)

Last Xmas I spent a couple of weeks at my mum's, where all my old desktops are, now converted to Linux app & web servers. I couldn't get to terms with the fact that my former gaming machine, a dual P3-800 with a 22" monitor, was just sitting there being wasted. My only Windows (XP) machine left is my laptop, which is hardly good enough to run Chuckie Egg, never mind CS.
After a quick search on google and a couple of days fiddling around with Wine I got Counter-Strike working on the app server. What joy! Frame-rate not the best around (30-60fps) but still playable.
Not all games will run, and I hear EverQuest is the reason why many people need to keep at least one Windows machine lying around, but support for new games and applications is making the list of supported apps grow all the time.
Certainly worth a try...

Red Hat Linux 9 Technical Changes (or when the RELEASE-NOTES are just not enough) by Dax.Kelson@GuruLabs.com
Copyright 2003 Guru Labs, L.C.
Intro Over the past eight years or so, I've been excited each time a new version of Red Hat Linux gets released. During the past few years, people have even been writing reviews of each release. As a general rule, I've been dissatisfied by the superficialities, inaccuracies, and irrelevancies in the reviews often times performed by someone who does not have intimate knowledge of Red Hat Linux. A systems administrator needs an in-depth review that covers relative to the previous release:

• Architectural & behavioral changes
• Installer changes
• Changes to included software packages

Normally, with each new release of Red Hat Linux, someone here at Guru Labs combs through it looking for the above changes to update the Guru Labs Linux courses. This time it was my turn, and I decided to simultaneously write a technical review for the system administrators out there. I hope that the results are satisfactory.

Abbreviation notes:
RHL = Red Hat Linux
RH = Red Hat Inc.
Architectural & behavioral changes There were many changes between RHL7.3 and 8.0, for example, the use of root=LABEL=/ in the /boot/grub/grub.conf file, the replacement of Xconfigurator with the redhat-config-xfree86 program, and the new dhclient DHCP client daemon. There are not nearly as many behavioral changes from RHL8.0 to RHL9, yet the ones that exist are significant. Kernel 2.4.20-8 The kernel in RHL8.0 was based on the 2.4.18 kernel. Despite the name, the RHL 2.4.20-8 kernel is based on 2.4.20 plus bug fixes identified up through 2.4.21-pre4-ac4. During the past couple years, the RHL kernels have included back ported functionality from development kernels that has proven stable. The new RHL9 kernel is no exception. Major changes since RHL8.0 include:

• Addition of Native POSIX Thread Library (NPTL) for standards based threading support with impressive performance. This is definitely a nice addition, however, I anticipate that sys admins who add patches on-top-of the RHL kernel from 3rd party (UML, FreeSWAN, etc) sources will have a more difficult time getting the patches to apply and work cleanly. Presumably when the 2.6 kernel comes out, the divergence of the RHL kernel will drop substantially.
• • Certain applications using the old LinuxThreads API in a certain manner may no longer work (was that vague enough?)
  • In particular if using Java, update to the latest version from Sun at:
  • http://java.sun.com/j2se/1.4.1/download.html
  • The WIN32 API translation software, WINE, suffers from this problem. Proper fixes are in the works, however, workarounds exist.
  • Installing and running Oracle 9i R2 has major issues since it includes two different older embedded Java JVMs that don't work with NPTL. The solution is stick with RHL8.0 or the officially supported Red Hat Linux AS edition.

ACPI support appeared in a beta (as well as in a 8.0 beta), but was removed for the final shipping kernel.

Filesystem ACL and EA support appeared in the betas, but was pulled for the final shipping kernel. I was really looking forward to ACLs and EAs support in RHL (Solaris had support since 2.5.1), maybe an errata kernel will re-add the feature.

• To see what software specifically supports

• Architectural & behavioral changes
• Installer changes
• Changes to included software packages

Normally, with each new release of Red Hat Linux, someone here at Guru Labs combs through it looking for the above changes to update the Guru Labs Linux courses. This time it was my turn, and I decided to simultaneously write a technical review for the system administrators out there. I hope that the results are satisfactory.

Abbreviation notes:
RHL = Red Hat Linux
RH = Red Hat Inc.
Architectural & behavioral changes There were many changes between RHL7.3 and 8.0, for example, the use of root=LABEL=/ in the /boot/grub/grub.conf file, the replacement of Xconfigurator with the redhat-config-xfree86 program, and the new dhclient DHCP client daemon. There are not nearly as many behavioral changes from RHL8.0 to RHL9, yet the ones that exist are significant. Kernel 2.4.20-8 The kernel in RHL8.0 was based on the 2.4.18 kernel. Despite the name, the RHL 2.4.20-8 kernel is based on 2.4.20 plus bug fixes identified up through 2.4.21-pre4-ac4. During the past couple years, the RHL kernels have included back ported functionality from development kernels that has proven stable. The new RHL9 kernel is no exception. Major changes since RHL8.0 include:

• Addition of Native POSIX Thread Library (NPTL) for standards based threading support with impressive performance. This is definitely a nice addition, however, I anticipate that sys admins who add patches on-top-of the RHL kernel from 3rd party (UML, FreeSWAN, etc) sources will have a more difficult time getting the patches to apply and work cleanly. Presumably when the 2.6 kernel comes out, the divergence of the RHL kernel will drop substantially.
• • Certain applications using the old LinuxThreads API in a certain manner may no longer work (was that vague enough?)
  • In particular if using Java, update to the latest version from Sun at:
  • http://java.sun.com/j2se/1.4.1/download.html
  • The WIN32 API translation software, WINE, suffers from this problem. Proper fixes are in the works, however, workarounds exist.
  • Installing and running Oracle 9i R2 has major issues since it includes two different older embedded Java JVMs that don't work with NPTL. The solution is stick with RHL8.0 or the officially supported Red Hat Linux AS edition.

ACPI support appeared in a beta (as well as in a 8.0 beta), but was removed for the final shipping kernel.

Filesystem ACL and EA support appeared in the betas, but was pulled for the final shipping kernel. I was really looking forward to ACLs and EAs support in RHL (Solaris had support since 2.5.1), maybe an errata kernel will re-add the feature.

• To see what software specifically supports ACLs and EA

starting with Longhorn Server in 2005
LOL!. I already have it. Just download any Longhorn 3683 or 4008 build and use a tool called TweakNT to switch OS editions. I did say that a syncronised release was likley with Longhorn didn't I?. WTF? You ask. Lookee here. Don't switch if you depend on Telephony though.

Ok, just hope it doesn't come into Windoze installers. That might put of hopes of YAWLL (yet-another-windows-longhorn-leak)

I can't wait to play some great games on my linux machine!

Try Wine, its still your only chance...

You've been able to do this for quite some time now by using the /proc filesystem. Check out this mailing list post for details: http://www.winehq.com/hypermail/wine-devel/2002/06 /0044.html

Um, I'd say his point is that Kazaa only works on Windows. If a person does not use Windows, then they can't use Kazaa, and therefore it's not a choice for some people. How difficult is this to understand?

Kazaa Lite runs under wine.

I can't believe that when I searched the list of replies to this article there is no mention of Gnucleus. Not only is it open source, but there is not spyware or anoying pop-up ads in the program. I have used quite a few different Gnutella clients and I have found gnucleus to be one of the better. Sadly, they don't have a linux verison, but you can get the source and probably figure out a way to make it work on Linux or you could just run it in on linux using a windows emulator like Wine.

Arrggh, it's too hard.

I work for VMware. if you want to believe we've corrupted Kevin's precious bodily fluids, feel free. I don't speak for the company, and I know nothing beyond what slashdot has posted about plex86. Consider yourself disclaimed.

If I understand the story correctly, plex86 has basically surrendered. They've given up on running arbitrary supervisor level code; the Linux guests that Kevin refers to above require a patch to "fix" something the new "lean, mean" plex86 gets wrong.

If Linus is feeling even vaguely himself, he will not accept this patch. Ordinarily, people trying to put stuff into the kernel that a) hurts performance, and b) fixes no real problem, but c) is critical to some contrived project that seems really important to the contributor get entertainingly flamed, and then shown the door. In fact, Kevin's most likely motivation for submitting this as a Slashdot story is to marshall support for his Linux patch.

Even if Linus does accept this patch, I can guarantee you that Microsoft, the FreeBSD team, the now non-existent Be, etc., won't all be taking helpful hints from Kevin about which x86 features they may and may not use. Ergo, there is nothing interesting (either commercially or geekily) you can do with plex86; the most it can hope for is to run recent-ish Linux guests on recent-ish Linux hosts. Bestill my heart.

On the upside, maybe Kevin will stop implying that VMware stole Bochs, now that he's spent four years trying to clone our software and has finally admitted defeat.

I certainly hope you realize that those are all screenshots of ReactOS running under Bochs running under Windows XP. Only the second image shows off the ReactOS GUI, which seems to be a WINE derivative.

Wine works quite well for a large number of applications and support is improving daily.

Chris

From the makers of Things You Cant Do in Windowscomes Things You Can't Do in Linux You Can Do in Windows:

With chapters such as, Playing games without a Athlon XP 2200 emulation runner, Running a 21th century GUI!, and free time!! Thats right folks, with our guide to Things You Can't Do In Linux you can actually install programs without scheduling the time to do so! Install a new camera without restarting 6 times to find the right driver! Even use the latest video card without scrambling for seventy-two kernel patches!

All for the price of only thirty-nine ninety-five.

Yep, he said that.

Although I wonder why nobody else made a library that implements the Win32 API as a library.

Isn't that what Wine is?

Wine is an implementation of the Windows Win32 and Win16 APIs on top of X and Unix. Think of Wine as a Windows compatibility layer. Wine provides both a development toolkit (Winelib) for porting Windows sources to Unix and a program loader, allowing many unmodified Windows 3.x/95/98/ME/NT/W2K/XP binaries to run under Intel Unixes. Wine works on most popular Intel Unixes, including Linux, FreeBSD, and Solaris.

One of the main points in M$'s argumentation is that the GPL hurts the industry, because you cannot write commercial apps based on GPL software, but the GPL is not the only Open Source license and most reasonable OS libraries are licensed under the LGPL or similar licenses that allow developing commercial software.

Open source developers simply have to choose an appropriate license for their project when they start. And if they find out that they chose wrong there is still the possibility to change the licensing terms. A very prominent example for such a license change is the Wine project that changed it's license from X11-like to LGPL recently.

If a company finds an OS library useful for their own project, but they cannot use it, 'cause it's GPL, they can still contact the author and ask for different licensing terms. They'll probably have to pay for that then, but they'd have to pay for a commercial product, too. So even GPL'd libraries are not really a hurdle for commercial software development. A good example for such dual licensing is ReiserFS, which is published under the GPL, but sold under different licensing terms to companies that want to use it commercially.

Run Wine on it....

I enjoyed the first game so much, wonder when Blizzard is going to make a second one... I've even been playing through the original games single player missions again under Wine.

Chris

Right Here

it will e-mail you where you can buy that wine, on-line

Right Here

Actually, yes

Ha! Gotcha! :)

Notepad and ~/ in the same sentence!?

Ever heard about Wine?

Please, no karma whores replying to this with advertisements for wine; we have enough drunk developers as it is!

*phew* Luckily, I made an advertisment for the emulator Wine, not the wine you can get drunk from.

tee hee

Sorry, but you're mistaken. There is a lot being handed back to the community. http://www.winehq.com/hypermail/wine-license/2002/ 06/0156.html

There are some real applications that could come out of this rather than just endless virtualization - much of it could prove useful to ReactOS which aims to be a open source alternative OS to Windows...
Also another in the pipeline which need a lot more work on Wine before anything will happen with it (XOpenWin, which aims to replace the Windows GDI with XWindows :-))
Wine and other related things need developers, so sign up and get coding. Check out the wine-devel mailing lists for more useful info...

Run VTI (A TI calculator emulator) under Wine. Then in VTI, run Tezxas (A ZX Spectrum emulator)

Yeah that would be nice, but I think the biggest obstacle for users converting to linux is the rude awakening of knowledge required to setup and use it to its potential, now they need to know what a computer is :)

It hasn't been a problem for me, I'm been ripping computers apart and putting them back together for a long time, but for some of my friends who I thought were fairly technical, I've been shocked at how much they stuggle with linux.
"How do I get back to the windows part if I swith a dos thing or console or whatever you call it?"
"What do you mean manually set?"
"How do I play game xyz in here?"
The solution to the problem of the user's knowledge requirement I think is installed/configured linux computers, which get /. time now and then...and they also need an idiotproof wizard/lizard/druid/thing that will come up the first time the computer is booted which has the user change the root password, setup at least one user, and give the user the change to take like a tutorial of basic operations (I mean like, how to use the window manager, where to put files etc)

The "good windows emulator" you spoke of will be around soon, when winex reaches their goal and merges their code with the wine project, which I think will happen and once it does, a simple windows skeleton will be there on the system, and some sort of software can detect the user trying to user a windows binary or inserting a windows cdrom and prompt them with a box asking if they are trying to run windows software, and if so, translate their actions to winex syntax etc etc. In the end I think for linux to be a hit w/ "normal users" (non-technical, semi-computer literate) it has to be able to run windows applications (like games, m$ office, quicken, yourfavoritewindowsprogramhere, etc) without the hassle of wine/winex hacking or the purchase of fancy software like VMware (which would require you to buy windows anyway so to the user "pointless") Sounds like LindowsTM? Well it's not, Lindows costs money. I think Open Source software can work, but if advocates of it (hi devels :)) want it to be popular, they need to ungreedily write some pretty code and hype it up for a distribution like mandrake to include. Then when that's settled, we linux users, show it off to our friends and say "See this? It does everything windows does, everything OSX does, and lots more, and its' free. (So why the heck are you still running this?)"

Well this is too long already, but what I'm trying to say to everyone, is that I think we go about marketing linux in the wrong ways- we need to keep it technical, for the geeks and servers and stuff, but make some like "easy mode" for the non-computer savvy so we can push it out on the masses and then more 3rd parties will devel for it and presto, it's _the_ OS of the 21st century...

Mod the parent up.

If the source code for Office X were available, porting could be fairly straight-forward. This is not the case. Office X is already compiled for PowerPC hardware, and MS is surely not going to release the source code.

WINE works because Windows programs compile to the same processor instructions that Linux or BSD on x86 do. It is then only the linked libraries that WINE needs to replace.

For more helpful info about WINE, check here.

Tony

Excerpt:
[snip]Code Red did what any "virus" presented with a large homogeneous population would do: it infected more than 359.000 computers in just the first day.[snip]

It is only a matter of time before a more virulent worm appears. The only way to decrease its impact is to diversify the OS population. Because it is an alternate implementation of the Win32 API and runs on top of a completely different OS, Wine does not have the same flaws and thus can provide this needed diversity.

Umm, why shouldn't it be susceptible to 'virii', like windows is? Never mind that linux can be infected with a virus... Now your telling me that something that was reverse engineered to run windows programs, with bug for bug compatibility, can't run some virus that is running win32 specific code?

There was recently some discussion on the Wine newsgroup about limiting emulated applications' access to the system. This could be handy for dealing with semi-malware or just programs that don't fully like the emulated environment (and might need to be prevented from doing too many suspicious is-it-really-Windows checks). The reply was that since a Wine emulated program is running as an ordinary executable, it could call Unix system calls anyway, so there would be little point (from a strict security point of view).

However, something like NetBSD's and OpenBSD's recently added feature to monitor system calls and define policies could potentially be very handy for running binary-only programs you don't fully trust: and of course most such programs are on the Windows platform.

Even though 100$ is a low price for office

Wine Is Not an Emulator! It's an implementation of the Windows API for *nix. If you had ever visited the Wine project's site, you would know that.

I was basically defending the GPL from someone who called it Marxist or whatever..

The Wine project started out with a BSD-style license, and switched to LGPL.

A quote from the page:
"However, with some recent events I cannot disclose, it is clear to me that the opportunity for Wine to be used in a proprietary product is too tempting and has caused some harm to the Wine project. Based on experience, I feel strongly that the potential for harm is great enough that CodeWeavers needs to take two actions. First, we would like to release all new code we develop under an LGPL style license. Second, I would like to open another call for a license change and thereby strongly add my voice to Alexandre's."

My observation has been, that no one truly understands the internals of a windows system. [...]

Not meaning to spam, but it sounds like you may be interested in - and most people here could use a look at - ReactOS (it's Wine's complementary project - Wine provides the user-mode part, and we the kernel). Windows is no more a Microsoft thing only

You could always try it in Wine [1] [2] [3]

David

There's windows binarys on the site but I couldn't compile the source on my linux box (no windows.h !!!).

You can get a working windows.h (and supporting libraries) for Linux here. It's called Winelib.

Face the music: there are not enough users on Linux to justify having any developers work on a port of, say, Photoshop. It would take millions of dollars to port, and nobody will buy it. Given that Linux has maybe 0.5% of the desktop, and that maybe 1% of that will ever buy software that costs more than $30, I doubt the expense is justified.

How about promoting more useful projects like Wine/Winelib instead? A company with even marginal resources (Codeweavers) can do wonders with Wine, such as run MS Office and MSIE quite well. If some other company spent some more resources on improving it, it would be able to run 90% of the apps out there, including Photoshop and all the other stuff. It would also have a good chance of increasing that 0.5% market share to something more reasonable.

If you still don't believe me, just consider what would happen if Adobe ported Photoshop to Linux. 10 or 15 people would actually buy it. It would get press coverage. And then, nothing would happen and no other company will bother porting anything. Kind of like what happened to Loki.

A nice small little app. Works fine under Linux and Wine for me, too.

Oops -- it was not, in fact, MS. I had been skimming something a long time ago that was talking about it, referring to MS's header files. It turns out that there was actually a different case that set precedent, and that this was then mentioned in reference to Microsoft.

I'm not sure what the original document was where I read this, but it's also talked about a bit in this recent WINE->GPL thread.

The crucial sentence in the court's decision:"When specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement".

Now, before Slashdot people start going ape all over this ("But this is the *only* way to compress MP3/compress GIF files so we should be able to do it"), keep in mind that this refers *only* to copyright, not patent law.

Interestingly enough, this passage may give carte blanche to MS to steal whatever chunks of machine code from AOL Instant Messanger they want to to allow interoperability between MSN Messenger and AIM. The same goes for cryptographic signatures containing copyrighted information (*cough* X-Box), and whatnot.

All we'll need to do is hack up Wine to report (But still perform) "strange" CD-ROM accesses. Then we'll know just what the program is looking up on the CD, and we could even get a traceback of the code (EIP, registers, etc). Then, just make a crack that swaps a JMP instruction for a JZ/JNZ...

Well, im not sure about everyone else.. But I know us developers at the WINE project have found the new APIs (documented here) to be anything but useful..
Well, the register does say "what Microsoft has got in there is a grotesque, badly-documented pile of poo it doesn't fully understand itself." (in regards to the fact that the few new APIs microsoft released doco's on are other useless or all together wrong!.)

David.

Interesting point, but I really doubt that this is aimed at the general consumer. It's for Joe Linux, who prides himself on doing nifty tech things with Linux.

Okay, Tux Racer may not be the most amazing thing in the world, but it's fun for a couple hours.

Freeciv...why is freeciv bad? You don't like civilization? There are some differences, but aside from the fact that civ had more artists (and, IMHO, a worse interface) and is a bit easier to use, not huge difference in fun factor.

Lets consider some others:

zangband/ToME/angband/nethack/etc: These *are* a lot of fun. Diablo has much more simplistic, boring gameplay, and it took off all over. Most variants have a pretty simple text or 2d graphics based interface without music, but some are a bit more elaborate. Be a bit of a pain to play on the controller, yes...

Chromium BSU: flashy scrolling shooter. Could use the 3d hardware in the X-box.

Dunno if you can just use ordinary ol' x86 binaries (particularly considering RAM usage), but:

Quake 3 (use the 3d hardware). Not free.

Abuse: This was a *blast* when it came out -- I played it over and over. It's looking a little dated now, but it's still a good game. Free now -- thanks crack.com.

Pingus is apparently shaping up pretty well.

There's part of the amazing Exile series available for Linux. (shareware)

Maelstrom may be too "simple" for you, as it's only an astroids clone, but it was a very well known game on the Mac for a long time, and I still like it.

While I'm not a tremendous fan of Illwinter's Conquest of Elysium II, their Dominions: Priests, Prophets, and Pretenders is a non-flashy but very deep, very good strategy game. Shareware.

There's a DOS-style shooter from Mountain King Studios, Raptor. (shareware)

Finally, there are all the emulators and whatnot...take a look at GNUboy, TuxNES, snes9x, DGen/SDL,
FreeSCI, Sarien, Exult, XU4, ScummVM, Basilisk II, YAE and others.

There are a host of Loki ports that you can't get any more except used. Lots of good stuff from LGames, though I'm not as big a fan of their stuff as some other people are.

Finally, text-based but really, really sophisticated, good, and almost all of them free, there are text-based interactive fiction (Try Tower of Babel before giving up on this...first one I ever beat without cheating, and it's *soooooo* good). The Interactive Fiction Archive has games and players.

Finally, many good games can be played through WINE -- Starcraft, Fallout, Max Payne, Half Life...

These are just some of the games that I enjoy under Linux. There are lots more (admittedly, some of lower quality) available at the SDL Games Page and the Linux Games Tome.

Linux games usually take a bit more (okay, often a lot :-) ) more effort to set up properly. But they're often very customizable, you can actually have an impact on the game design ("This game needs feature X"), and you don't have to leave the comfortable environs of Linux. And the environment is getting better, not worse.

It looks like nothing helpful to any open source projects will be revealed. No server protocol or api for 'security reasons' and because it would allow them to
"clone" Windows, prompting Microsoft to stop investing in research and development on the operating system.

Yeah right, Microsoft just wants an excuse not to help out open source projects.

So it's pretty worthless to projects like Wine and Samba. I think this is just more of their Shared Source program.

Oh and btw, here's an HTML clickable link:
http://story.news.yahoo.com/news?tmpl=story&ncid=5 81&e=1&cid=581&u=/nm/20020805/tc_nm/microsoft_code _dc_17

Such as the classic, Bungie's Myth: The Fallen Lords. You can run the demo under Wine if you're on Linux.

No Wine is NOT an emulator.

Mind explaining to me how Wine doesn't meet the 3rd definition of emulate, listed above?

It certainly appears to "imitate the function of" Windows, doesn't it?

Hell, as an AC pointed out below, even one of the primary Wine developers (Alexandre Julliard) refers to Wine as an emulator, here.

Dinivin

I doubt this will end discussion on the subject, but this link has a quote near the end of the section from the founder of the Wine project:

"The problem is that you are seeing this in economic terms. That's not how it works. The real value is not in the individual contributions, it's in the collaboration, where everybody works with everybody else on building the best possible Windows emulator."

Yes that's right, the founder of the Wine project just called Wine a "Windows emulator"! Would you like to argue with him on the subject?

Hows about pasting from something that actually knows what it's on about?

Myth 1: "Wine is slow because it is an emulator"

Some people mean by that that Wine must emulate each processor instruction of the Windows application. This is plain wrong. As Wine's name says: "Wine Is Not an Emulator": Wine does not emulate the Intel x86 processor. It will thus not be as slow as Wabi which, since it is not running on a x86 Intel processor, also has to emulate the processor. Windows applications that do not make system calls will run just as fast as on Windows (no more no less).

Some people argue that since Wine introduces an extra layer above the system a Windows application will run slowly. It is true that, in theory, Windows applications that run in Wine or are recompiled with Winelib will not be able to achieve the same performance as native Unix applications. But that's theory. In practice you will find that a well written Windows application can beat a badly written Unix application at any time. The efficiency of the algorithms used by the application will have a greater impact on its performance than Wine.

Also, and that's what people are usually interested in, the combination Wine+Unix may be more efficient that Windows. Just as before it's just how good/bad their respective algorithms are. Now to be frank, performance is not yet a Wine priority. Getting more applications to actually work in Wine is much more important right now. For instance most benchmarks do not work yet in Wine and getting them to work at all should obviously have a higher priority than getting them to perform well.

But for those applications that do work and from a purely subjective point of view, performance is good. There is no obvious performance loss, except for some slow graphics due to unoptimized Wine code and X11 driver translation performance loss (which can be a problem sometimes, though).

warcraft 3 has worked with winehq wine as far back as the warcraft 3 beta, see this post to the wine-devel mailing list.

warcraft 3 has worked with winehq wine as far back as the warcraft 3 beta, see this post to the wine-devel mailing list.

A lot of open source projects could benifit from automated testing. The wine project has spent nine years working on translating the windows API to X and reproducing the windows GUI.

Many people think wine is a vital tool for greater use of linux. They rely on people downloading new versions and testing windows programs using whatever versions of X, system libraries and windows DLL's they happen to have and then posting bug reports in a newsgroup. There are still lots of quirks with relativly simple windows programs not redrawing or displaying dialogs correctly.

I believe that wine would progress much faster if the wine developers could make a change then click test and later, with no more effort get a report saying "3 tests which failed previously now pass, 1 test which passed on the last version now fails".

I will be very impressed if somone comes up with a free automated testing tool that allows tests to be set up easily and is powerfull enough to provide human readable results "the bitmap is drawn 1 pixel to the left", "text as expected but wrong font" "dialog appeared behind other window" etc.