moronikos writes to mention that the first release candidate of Wine 1.0 was announced and released into the wild today. This new version includes only bug fixes as the team is in a code freeze while pushing for the full 1.0 release.
by Anonymous Coward
on Saturday May 10 2008, @04:06AM (#23359432)
I am not familiar with MAME, but the other you mention are emulators, in that they perform byte-code interpreting of the program code (I guess MAME does too). Wine does not, it only provides an ABI-compatible implementation of (most of) the WIN32 API.
If Wine would be an emulator, it would run equally well on PowerPC or SPARC hardware. It does not, you need the exact same hardware that the original program was intended for.
Finally, for the semantically pedantic: yes, recent versions of Dosbox also have a "dynamic" execution mode which tries to do the same that wine does. Naturally, it only works when running Dosbox on x86-compatible hardware.
Finally, for the semantically pedantic: yes, recent versions of Dosbox also have a "dynamic" execution mode which tries to do the same that wine does. Naturally, it only works when running Dosbox on x86-compatible hardware.
QEMU does this too, as does any decent virtualization system. So emulation means translation between different kinds of hardware?
An emulator manually interprets the original system's machine code, solving a hardware incompatibility, a compatibility layer only implements an API (in Wine's case the Windows API), solving an OS incompatibility. Technically an emulator doesn't have to be on different hardware to the original, but it's fairly pointless to do. Dosbox is technically both an emulator and compatibility layer, because it covers both hardware and OS changes, most emulators run the original hardware's OS (if it has one). The Java Runtime would be an emulator if it wasn't for the fact that there is no hardware that runs Java bytecode natively (or at least, it came after the Java Runtime).
Actually, Wine is an alternate implementation of the APIs, not an emulation of them. There's a difference, at least if you're using the words in a technical sense rather than a regular English sense. Which, when being pedantic about a technical matter, is the correct sense to use them in.
You've already been corrected multiple times in this thread, so I won't repeat the same thing. Rather, I'll provide an analogy that may make it clearer:
AMD does not emulate x86, it implements it. Similarly, WINE does not emulate the Win32 API, it implements it.
Conversely, QEMU emulates x86, it does not implement it.
I was always under the impression that WINE, based on how it is designed, would never be finished, or even close to a finished release point. I mean, yeah, I know 1.0 doesn't mean it's done, just that it hit a specific milestone, but even so, WINE, being considered a ⥠1.0 version seems to me like it shouldn't happen until it can at least come close to running most everything thrown at it.
Just my non-developer, non-programer, former WINE-user $.02.
by Anonymous Coward
on Saturday May 10 2008, @04:21AM (#23359484)
Wine is nowhere near finished. I was recently pointed to Wine's API stats [winehq.org], where the current state of the API implementation is stated. They are currently at 63% of the targeted Windows APIs.
That said, quite a few apps are already working without problems in Wine. In order to be able to do a 1.0-release, they have selected a few (major) apps that have to be running flawlessly. I can't find a link for it now, but it's somewhat like:
- Adobe Photoshop CS2 (or CS4?) - MS Office 2007 document viewers - Google Picasa
That's a somewhat arbitrary list, and doesn't say anything about the 9765 [winehq.org] application that are listed in the AppDB, many of which work without problems. I think the 1.0 release does not constitute a milestone in and of itself, but it may help to expand its userbase, and hopefully we'll start to see a more dependable release cycle than just the bi-weekly "snapshot" release they have been doing.
We know those stats aren't quite accurate. Here's basically how we generate them: we ask the various subsystems maintainers, "How close to complete do you think this is?" and then we munge in some true numbers on actual function calls (API's) exported by DLL's and the number we've implemented (and in and of themselves each API might not be 100% complete.)
So take those numbers with a grain of salt. In some cases, it's completely possible a DLL will be nearly 100% functional with not many of the API's implemented at all. Microsoft has invented thousands of API's over the years and some have been dead on arrival - no one has ever used them. Even Microsoft doesn't use all of their API's. That's why within Wine development there's an often cited development method of, "Show me an app that actually uses that."
Finally, Tom hasn't updated those stats in almost a year and we've done a lot of work since then. (Big kudos to Tom Wickline for tackling that stuff.)
So what Wine really aims for is to take the most common few thousand API's and try to do them really well. Then we flesh out some bits around that. Then we stub out things around that and finally there's bits we just haven't even started.
I mean, I've been running Windows software under WINE for *years*. What's their definition of "1.0"? Does it really mean anything, or will we be getting 1.0.1, 1.0.2, etc monthly afterwards anyway just like before? Or is 1.0 some "complete feature set" release, suggesting that I can now run any windows software (I doubt that's true, considering that even MS Office is still a bit shaky).
by Anonymous Coward
on Saturday May 10 2008, @06:32AM (#23359926)
The beef is described at http://wiki.winehq.org/WineReleaseCriteria In essence, 1.0 is just another release, but with more stability (e.g. a month's codefreeze and only very careful bugfixes) and a few longstanding bugs (e.g. serial I/O, dos apps) fixed not because lots of people need them, but because it just seemed wrong to reach 1.0 without fixing them.
I think this is great Wine is finally reaching "1.0". I am hoping this version will be treated as a longer lived, stable, supported branch. This way developers might seriously target Wine as a platform or at least consider it a real "Microsoft Windows Compatible" target (Yea, it would be better if ports of apps were targeted to be Linux or Mac OS X native)
Sure it won't run all Windows apps perfectly - but then again, neither does Windows! There are lots of apps out there that have various bad code that often shouldn't even run at all but somehow gets away with working under a generic Windows XP install. Then they crash under Wine, Windows Vista, or even XP under odd configurations. And then there are the ones that do things different under different versions of Windows to get around bugs or varying behavior in Windows.
Also having a longer lived "1.0" branch would mean tips and tricks to getting individual programs to run would not become obsolete quite as quickly, and a Wine "1.0" users would not have to worry as much about apps breaking every few weeks.
At any rate, Wine has come a very long way - I remember when it was just trying to be a Windows 3.1 clone!
I am hoping this version will be treated as a longer lived, stable, supported branch.
WINE will never become quite like other software, which define their own features. Think of it like a web browser with lousy standards support (not that the Windows API is anything like a standard), there's really no point in creating a very long-lifed branch that scores 58%. You do some development and you're at 61% and the new version is just better and should replace the old one everywhere. The only real reason to keep a stable branch is to keep people from getting hit with regressions. Because all kinds of software runs on top of WINE, it can have some really bad regressions as applications can go from platinum (runs flawlessly) to garbage (not at all) because it does something in the initialization that failed. So yes, a more stable branch than the biweekly development snapshots is good. Any older branch than say 3-6 months I think will be pretty useless.
When I switched from Windows to Linux, it turned out that I was able to function without specific applications, there are Linux equivalents for pretty much everything.
Well, yeah, it depends on what you need, doesn't it? What you say is true for many, maybe even most people, but that doesn't mean nobody needs Wine.
If you have to interoperate with Windows users who use specific software, and the Linux equivalents can't read/write files from that software sufficiently well for your purposes, then you may still find yourself looking for a way to run the Windows programs. This used to be the case a lot with MS Office; modern Linux office apps are pretty good at interoperating, so it's not an issue so much, though there are still a few rare cases where the Linux software won't be able to duplicate what MS Office does quite well enough. (Complex VBA macros that automate other Windows applications, for example. Though I don't know offhand whether Wine can handle those either, and frankly anyone who uses them deserves the pain they cause:)
Then there are the cases where the Linux programs are genuinely inferior. Again it's a question of whether that actually matters. For example, GIMP is good enough for most casual users and even many professionals, but still a lot of people are inevitably going to find there are things they need that it doesn't do, and then they're going to want a way to run Photoshop.
And finally we have the fundamental matter of freedom of choice. Some people just prefer various proprietary Windows applications, and it's good that they can have the freedom to choose to retain those, even if the Linux equivalent would work just as well. Linux is all about the freedom to use your computer how you like, after all!
there are Linux equivalents for pretty much everything
And that's the killer. If 95% of what you need runs on one platform but 100% runs on another, which will you choose? I know businesses that are still running Windows 9x, out of support, because it still works and it runs their in-house VB4 application. If Linux (or FreeBSD or Solaris or whatever) can also run this VB4 application - for which there is no non-Windows equivalent because it was developed in house for a specific purpose relevant only to that company - then they can consider these platforms for their upgrade when they do finally get around to it. If not then they're locked in.
The point of WINE is that, for a lot of people, there is one important app keeping them on Windows that has no open alternative. Without WINE, they have to keep a windows [virtual] machine around. With it, they can switch.
Just look at the list of applications supported by Wine [winehq.org] and you'll understand why I say that. Basically, if I can run Civ IV, Heroes IV and other strategy games on Linux, and with Matlab having a Linux version, there's very little to justify my using Windows. OK, there's Fruityloops, but that's it!
Does this mean they'll start releasing binaries for OS X soon? I've compiled it a couple of times, but it's a lot of effort (you need to check out things from two separate svn repositories, run a script, hunt bugs, then compile for every version), and since they claim in the first paragraph of the front page to support OS X I'd really expect them to have regular binary builds.
The problem with wine has always been the moving target that is Windows. That's how Microsoft keeps itself relevant. Using its monopoly position to keep everyone on the upgrade treadmill.
With Vista so terrible and, really, only new machines going vista and old machines staying as they are on XP, the XP level of the Win32 API has remained fairly stable for a good number of years. In fact, it may be unlikely that Microsoft will ever be able to unify the user base on a new version of the API again.
(And yes I know that there are still users of 3.1, W95,W98,W98SE, etc. but these are static installations that typically don't buy new software.)
Wine, moving forward, has a very good chance of capturing a usable market because ISVs are reluctant to abandon XP in any meaningful way.
Alright guys, this release is 15 years in coming. I'm not aware of any other free software project that's taken 15 years to get to 1.0.
We know we've got some core architecture just right. That's taken a long time to get there. Now we have a lot of bug squashing to do and in many cases it's pretty amazing how quickly regressions can be found, bugs tracked, etc if we just have a few more eyes on this release.
So we put together a list of things you can do to help us out - check it out here: 1.0 regression hunting [winehq.org]. And hey! We're giving out t-shirts to the folks who help us out the most.
Notice we didn't say anything about jumping in and writing code? You're certainly welcome to, and in some cases there might even be some low hanging fruit. However, without development experience on Wine's codebase your valuable time might best be spent regression testing your favorite game!
Because Wine is not an emulator, it is faster and uses less memory than emulators.
How well do 3d games work with emulators?
If you run Windows on a virtual machine, you will still need Windows for that. With wine you don't.
But obviously you are free to use what ever you like and what works best for you. As wine is not ready, it is not a perfect solution, even it does have some advantages for the applications that work with it.
doesn't wine still require windows files to run things like d3d? so to run it legally you still need to purchase windows anyway?
The short answer is, as another poster wrote: No.
The long answer is that not all of the DirectX features are quite there, I don't know if it's current but there's an overview here [winehq.org]. The result is that some games won't play without native DLLs. Doing that requires the Windows files and adding an override in winecfg. This was a much larger issue before than it is now and it keeps getting fewer that need these overrides.
"Why would I want to use Wine when I can just run windows in a virtual machine?"
You don't have a lot of spare RAM? (e.g. using VirtualBox requires enough RAM for the host OS + the RAM for the virtualized OS + the RAM for the app running in it; with Wine you eliminate the need for the virtualized OS)
You don't want to buy a Windows license/pirate Windows for a single app? (or more generally, you don't want Microsoft code on your system if you can help it?:)
Because you do not want to support Microsoft by purchasing Windows? Besides, these days MS will not even sell you a version of Windows that runs best under a VM (XP for newest x86 computers, 98 for the rest).
I see a business model of developing programs for the dominant desktop platform but also certifying them to run properly under Wine for Linux users. If the application is explicitly Wine-aware, it shouldn't be that hard to get it Gtk+/Qt themed, use UNIX-styled file dialogs or call native libraries for Linux-specific functionality. Of course.Net/Mono may be a better solution for a lot of developers.
Why would I want to use Wine when I can just run windows in a virtual machine?
Because you...
...don't have a copy of Windows to install and don't want to buy one.
...want the application window to use your normal X11 window manager rather than having to have an entire Windows environment with start menu and everything.
...don't want to wait for Windows to boot every time you want to run the application.
...want to run an application using 3D.
...don't have VMX hardware and don't want to shell out money for VMware.
...don't want the overhead of emulating the entire hardware.
I won't argue the reason that you don't want to run proprietary software, because if you're running Windows applications, that's probably not your problem. However, even so, I would feel it would be nice to be able to run e.g. a game without necessarily making my system a nest of evil. I've always felt that I don't mind games being proprietary -- they're a bit like movies or books in the way that it is the content, and not the code, that actually matters.
That said, there are obviously lots of reasons for wanting to use Wine.
Another reason you're forgetting, and I know at least this applied in the earlier days of Wine, but I've not verified it recently... if you're a developer (developer developer... etc) the wine libraries can also be used to compile linux native binaries from windows based source. It's not the ideal way to port software, but it works for a quick and dirty compile. The plus side is, while Wine is constrained to a single architecture for the purpose of executing windows binaries compiled for that architecture, the code could be compiled for any architecture or OS that wine runs under.
You ask why one would want to use WINE instead of a virtual machine (like VirtualBox or VMWare). Here are a few reasons that pop in my mind without thinking about it forever:
1) You don't want to buy an MS-Windows license 2) You don't want to support Microsoft 3) You don't want to waste multiple gigabytes of hard drive space for a virtual drive 4) You want to be able to browse and manipulate the MS-Win files under Linux 5) You want native Linux file permissions 6) You want higher possible performance 7) You don't want to waste many hundreds of megabytes of RAM 8) You want to be able to use thin client to display the resulting program 9) You don't want to have to install, configure, and maintain another whole OS 10) You don't want to fight possible viruses, auto updates that break things, Windows Genuine, etc, etc 11) You want each program to appear as a real process 12) You want to be able to compile a program to run cross-platform 13) You want native Linux filesystem access while in the MS-Win application 14) You want native CUPS/printing access while in the MS-Win application
There are LOTS of reasons for WINE to exist despite virtual machines. That is not to say that virtual machines are not useful, just different.
Version number schemes vary between different software, and you'll have to ask WineHQ specifically what they mean to be at 1.0.
In the FOSS world, though, usually version 1.0 is a pretty big milestone showing that the software is complete, with few bugs known and little or no features missing. Some projects gone on for years in the 0.x numbers before ever getting to 1.0 (if ever). Wine itself started just naming it on the date (eg, Wine 20020314), but a couple years ago or so they started calling it 0.9.0 and so on.
Usually the big number in a version number represents important steps, though this can of course vary. For example, OpenBSD doesn't bother with making a fuss about what the number on the left means and they just increment by 0.1 always (after 3.9 came 4.0, and so on). GNU Emacs decided a long time ago that no complete rewrite would ever happen, and so they constantly increment the big number for large changes (they're at version 22.0 now). Hell, Netscape even decided to skip an entire number (4.7 -> 6.0) after the original company died and the new versions were based on the Mozilla project.
but... (Score:5, Funny)
Re:but... (Score:5, Funny)
Parent
Cygwine? (Score:5, Interesting)
Parent
Re:but... (Score:4, Interesting)
Parent
Re:but... (Score:5, Informative)
Parent
Re:but... (Score:5, Funny)
Parent
Re:but... (Score:5, Funny)
Parent
Re:but... (Score:5, Funny)
It's really just placing a layer between reality and perception.
So definitely not an emulator.
Parent
Re:but... (Score:5, Insightful)
If Wine would be an emulator, it would run equally well on PowerPC or SPARC hardware. It does not, you need the exact same hardware that the original program was intended for.
Finally, for the semantically pedantic: yes, recent versions of Dosbox also have a "dynamic" execution mode which tries to do the same that wine does. Naturally, it only works when running Dosbox on x86-compatible hardware.
Parent
Re:but... (Score:4, Interesting)
QEMU does this too, as does any decent virtualization system. So emulation means translation between different kinds of hardware?
Parent
Re:but... (Score:5, Insightful)
Parent
Re:but... (Score:5, Informative)
Dosbox is technically both an emulator and compatibility layer, because it covers both hardware and OS changes, most emulators run the original hardware's OS (if it has one).
The Java Runtime would be an emulator if it wasn't for the fact that there is no hardware that runs Java bytecode natively (or at least, it came after the Java Runtime).
Parent
Re:but... (Score:5, Informative)
Parent
Re:but... (Score:5, Insightful)
AMD does not emulate x86, it implements it. Similarly, WINE does not emulate the Win32 API, it implements it.
Conversely, QEMU emulates x86, it does not implement it.
Parent
Re:but... (Score:5, Funny)
Parent
Re:but... (Score:5, Funny)
Parent
Obligatory... (Score:4, Funny)
I'll drink to that!!!
(seriously though...hooray WINE!)
Wait, What?! (Score:5, Interesting)
Just my non-developer, non-programer, former WINE-user $.02.
Re:Wait, What?! (Score:4, Insightful)
being considered a 1.0 version seems to me like it shouldn't happen until it can at least come close to running most everything thrown at it.
Nah, it just has to run more old Windows apps than the latest version of Vista. I think Wine as it was 10 years ago met that requirement.
Parent
Re:Wait, What?! (Score:4, Informative)
That said, quite a few apps are already working without problems in Wine. In order to be able to do a 1.0-release, they have selected a few (major) apps that have to be running flawlessly. I can't find a link for it now, but it's somewhat like:
- Adobe Photoshop CS2 (or CS4?)
- MS Office 2007 document viewers
- Google Picasa
That's a somewhat arbitrary list, and doesn't say anything about the 9765 [winehq.org] application that are listed in the AppDB, many of which work without problems. I think the 1.0 release does not constitute a milestone in and of itself, but it may help to expand its userbase, and hopefully we'll start to see a more dependable release cycle than just the bi-weekly "snapshot" release they have been doing.
Parent
Re:Wait, What?! - Those stats aren't accurate (Score:5, Informative)
So take those numbers with a grain of salt. In some cases, it's completely possible a DLL will be nearly 100% functional with not many of the API's implemented at all. Microsoft has invented thousands of API's over the years and some have been dead on arrival - no one has ever used them. Even Microsoft doesn't use all of their API's. That's why within Wine development there's an often cited development method of, "Show me an app that actually uses that."
Finally, Tom hasn't updated those stats in almost a year and we've done a lot of work since then. (Big kudos to Tom Wickline for tackling that stuff.)
So what Wine really aims for is to take the most common few thousand API's and try to do them really well. Then we flesh out some bits around that. Then we stub out things around that and finally there's bits we just haven't even started.
Parent
Re:Wait, What?! (Score:5, Informative)
- Photoshop CS2 tryout
- Microsoft Powerpoint Viewer 97 and 2003
- Microsoft Word Viewer 97 and 2003
- Microsoft Excel Viewer 97 and 2003
That's all they're targeting. I think it's a great idea to get to that level first, then expand without regression.Parent
So what's the definition? (Score:5, Insightful)
http://www.winehq.org/?announce=1.0-rc1 [winehq.org] pretty much has a list of bugfixes&features, just like any other release. Where's the beef in "1.0"?
I've got your definition right here (Score:5, Informative)
http://wiki.winehq.org/WineReleaseCriteria
In essence, 1.0 is just another release,
but with more stability (e.g. a month's
codefreeze and only very careful bugfixes)
and a few longstanding bugs
(e.g. serial I/O, dos apps) fixed not because
lots of people need them, but because it just
seemed wrong to reach 1.0 without fixing them.
Dan Kegel
Wine 1.0 Release Manager
Parent
Do we still need to wait for SP1 ... (Score:5, Funny)
Hooray! Long live Wine 1.0! (Score:5, Insightful)
Sure it won't run all Windows apps perfectly - but then again, neither does Windows! There are lots of apps out there that have various bad code that often shouldn't even run at all but somehow gets away with working under a generic Windows XP install. Then they crash under Wine, Windows Vista, or even XP under odd configurations. And then there are the ones that do things different under different versions of Windows to get around bugs or varying behavior in Windows.
Also having a longer lived "1.0" branch would mean tips and tricks to getting individual programs to run would not become obsolete quite as quickly, and a Wine "1.0" users would not have to worry as much about apps breaking every few weeks.
At any rate, Wine has come a very long way - I remember when it was just trying to be a Windows 3.1 clone!
Re:Hooray! Long live Wine 1.0! (Score:4, Interesting)
Parent
Re:Hooray! Long live Wine 1.0! (Score:5, Interesting)
Either Google Earth or Picasa (or both) do that.
Parent
Y'know (Score:4, Interesting)
Re:Y'know (Score:5, Insightful)
If you have to interoperate with Windows users who use specific software, and the Linux equivalents can't read/write files from that software sufficiently well for your purposes, then you may still find yourself looking for a way to run the Windows programs. This used to be the case a lot with MS Office; modern Linux office apps are pretty good at interoperating, so it's not an issue so much, though there are still a few rare cases where the Linux software won't be able to duplicate what MS Office does quite well enough. (Complex VBA macros that automate other Windows applications, for example. Though I don't know offhand whether Wine can handle those either, and frankly anyone who uses them deserves the pain they cause
Then there are the cases where the Linux programs are genuinely inferior. Again it's a question of whether that actually matters. For example, GIMP is good enough for most casual users and even many professionals, but still a lot of people are inevitably going to find there are things they need that it doesn't do, and then they're going to want a way to run Photoshop.
And finally we have the fundamental matter of freedom of choice. Some people just prefer various proprietary Windows applications, and it's good that they can have the freedom to choose to retain those, even if the Linux equivalent would work just as well. Linux is all about the freedom to use your computer how you like, after all!
Parent
Re:Y'know (Score:5, Insightful)
The point of WINE is that, for a lot of people, there is one important app keeping them on Windows that has no open alternative. Without WINE, they have to keep a windows [virtual] machine around. With it, they can switch.
Parent
Candidate version number (Score:5, Funny)
Wine - an unmitigated SUCCESS! (Score:5, Interesting)
what? (Score:4, Funny)
Mac Binaries? (Score:4, Interesting)
I think we have Vista to think for this (Score:5, Insightful)
With Vista so terrible and, really, only new machines going vista and old machines staying as they are on XP, the XP level of the Win32 API has remained fairly stable for a good number of years. In fact, it may be unlikely that Microsoft will ever be able to unify the user base on a new version of the API again.
(And yes I know that there are still users of 3.1, W95,W98,W98SE, etc. but these are static installations that typically don't buy new software.)
Wine, moving forward, has a very good chance of capturing a usable market because ISVs are reluctant to abandon XP in any meaningful way.
Can you help us? [t-shirt opportunity within] (Score:5, Informative)
We know we've got some core architecture just right. That's taken a long time to get there. Now we have a lot of bug squashing to do and in many cases it's pretty amazing how quickly regressions can be found, bugs tracked, etc if we just have a few more eyes on this release.
So we put together a list of things you can do to help us out - check it out here:
1.0 regression hunting [winehq.org]. And hey! We're giving out t-shirts to the folks who help us out the most.
Notice we didn't say anything about jumping in and writing code? You're certainly welcome to, and in some cases there might even be some low hanging fruit. However, without development experience on Wine's codebase your valuable time might best be spent regression testing your favorite game!
As always, thanks for all the support!
Re:serious question (Score:5, Informative)
How well do 3d games work with emulators?
If you run Windows on a virtual machine, you will still need Windows for that. With wine you don't.
But obviously you are free to use what ever you like and what works best for you. As wine is not ready, it is not a perfect solution, even it does have some advantages for the applications that work with it.
Parent
Re:serious question (Score:5, Informative)
The long answer is that not all of the DirectX features are quite there, I don't know if it's current but there's an overview here [winehq.org]. The result is that some games won't play without native DLLs. Doing that requires the Windows files and adding an override in winecfg. This was a much larger issue before than it is now and it keeps getting fewer that need these overrides.
Parent
Re:serious question (Score:5, Informative)
Parent
Re:serious question (Score:5, Insightful)
Parent
Re:serious question (Score:5, Informative)
Parent
Re:serious question (Score:5, Insightful)
You don't have a lot of spare RAM? (e.g. using VirtualBox requires enough RAM for the host OS + the RAM for the virtualized OS + the RAM for the app running in it; with Wine you eliminate the need for the virtualized OS)
You don't want to buy a Windows license/pirate Windows for a single app? (or more generally, you don't want Microsoft code on your system if you can help it?
Parent
Re:serious question (Score:4, Informative)
I see a business model of developing programs for the dominant desktop platform but also certifying them to run properly under Wine for Linux users. If the application is explicitly Wine-aware, it shouldn't be that hard to get it Gtk+/Qt themed, use UNIX-styled file dialogs or call native libraries for Linux-specific functionality. Of course
Parent
Re: serious question (Score:5, Insightful)
- ...don't have a copy of Windows to install and don't want to buy one.
- ...want the application window to use your normal X11 window manager rather than having to have an entire Windows environment with start menu and everything.
- ...don't want to wait for Windows to boot every time you want to run the application.
- ...want to run an application using 3D.
- ...don't have VMX hardware and don't want to shell out money for VMware.
- ...don't want the overhead of emulating the entire hardware.
I won't argue the reason that you don't want to run proprietary software, because if you're running Windows applications, that's probably not your problem. However, even so, I would feel it would be nice to be able to run e.g. a game without necessarily making my system a nest of evil. I've always felt that I don't mind games being proprietary -- they're a bit like movies or books in the way that it is the content, and not the code, that actually matters.That said, there are obviously lots of reasons for wanting to use Wine.
Parent
Re: serious question (Score:5, Informative)
-Restil
Parent
Re:serious question (Score:5, Informative)
1) You don't want to buy an MS-Windows license
2) You don't want to support Microsoft
3) You don't want to waste multiple gigabytes of hard drive space for a virtual drive
4) You want to be able to browse and manipulate the MS-Win files under Linux
5) You want native Linux file permissions
6) You want higher possible performance
7) You don't want to waste many hundreds of megabytes of RAM
8) You want to be able to use thin client to display the resulting program
9) You don't want to have to install, configure, and maintain another whole OS
10) You don't want to fight possible viruses, auto updates that break things, Windows Genuine, etc, etc
11) You want each program to appear as a real process
12) You want to be able to compile a program to run cross-platform
13) You want native Linux filesystem access while in the MS-Win application
14) You want native CUPS/printing access while in the MS-Win application
There are LOTS of reasons for WINE to exist despite virtual machines. That is not to say that virtual machines are not useful, just different.
Parent
Re:Infinite Loop (Score:5, Insightful)
Parent
Re:What does 1.0 mean? (Score:5, Informative)
In the FOSS world, though, usually version 1.0 is a pretty big milestone showing that the software is complete, with few bugs known and little or no features missing. Some projects gone on for years in the 0.x numbers before ever getting to 1.0 (if ever). Wine itself started just naming it on the date (eg, Wine 20020314), but a couple years ago or so they started calling it 0.9.0 and so on.
Usually the big number in a version number represents important steps, though this can of course vary. For example, OpenBSD doesn't bother with making a fuss about what the number on the left means and they just increment by 0.1 always (after 3.9 came 4.0, and so on). GNU Emacs decided a long time ago that no complete rewrite would ever happen, and so they constantly increment the big number for large changes (they're at version 22.0 now). Hell, Netscape even decided to skip an entire number (4.7 -> 6.0) after the original company died and the new versions were based on the Mozilla project.
Parent
Re:What does 1.0 mean? (Score:5, Informative)
http://wiki.winehq.org/WineReleaseCriteria [winehq.org]
Parent