Slashdot Mirror
First Release Candidate of Wine 1.0 Released
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.
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.
Because WINE can run "Lander on the moon" from Windows 3.11 and Windows XP/later cannot.
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).
.Net/Mono may be a better solution for a lot of developers.
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
If I recall correctly, there's a native Windows version of WINE just for that sort of thing.
I just read Slashdot for the articles.
Well, first off, operating systems do not run using WINE (including Linux). Secondly, Wubi isn't an emulator, virtual environment, etc. Wubi is a Windows application that installs Linux (from within Windows).
What happens if I run Wubi from WINE from Linux installed in Win32 VMWare using WINE in Linux?
I imagine it would install Linux.
Captcha: Products. Ha!
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.
Actually they do say, what's their target for wine 1.0:
http://wiki.winehq.org/WineReleaseCriteria
"doesn't wine still require windows files to run things like d3d? so to run it legally you still need to purchase windows anyway?"
No.
"To any truly impartial person, it would be obvious that I am right."
Wine is nowhere near finished. I was recently pointed to Wine's API stats, 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 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.
- 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.Put identity in the browser.
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).
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. 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.
Live today, because you never know what tomorrow brings
Exactly. Unfortunately, the project does not have this goal.
I just gave wine a shot (again...), and again most of the games
I have do not work (Jade Empire SE f.e.), or only work with
heavy configuration changes or/and incur in terrible
performance penalties (nwn2 f.e.).
Wine is useless for me until it is able to run most of the
stuff thrown at it, without having to install different versions
to work around regressions.
But of course, for those people who want to run Microsoft Office,
it should work great. But given the availability of OpenOffice,
its usefulness seems limited to the corporate env.
Really? I'm looking at that page and don't you know, it seems that Direct3D v9 is 95% supported...
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.
Dan Kegel
Wine 1.0 Release Manager
Being very slightly involved with Octave development and being impressed with its recent pace, I would like to ask you what is Matlab on GNU/Linux giving you that Octave can't?
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.
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.
-Restil
Play with my webcams and lights here
Technically VMWare is a visualizer because it executes the hardware instructions naively(except privileged instructions which require special handling). This makes VMware faster than emulators such as Bochs but virtualizers only provide virtual hardware that is roughly the same type as the host system. VirtualPC is an example of a product that is both. Virtual PC on Windows is a virtualizer. VirtualPC on the PPC Mac is an emulator. QEmu support virtualization but I think it also supports emulation as well for emulating say an ARM system on x86 hardware.
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.
----- obSig
Windows programs have the nasty habit of installing to C:\Program Files, a directory that normal users don't have write permissions on.
This also means that you need write permissions to it to update it.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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.
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. 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!
----- obSig
Buried down at the bottom of the FAQ it says:
If you are running OS X there are no official builds yet. The main reason is that Apple X11 is badly broken, and Wine doesn't run well with it. We don't like giving users a bad impression of Wine.
I wonder how old that entry is and if it's still true -- I know that early versions of X11 for OS X were pretty bad, but it seems like since 10.3, everything X11-dependent I get from Fink or build myself works just fine. Hopefully the Wine folks will take another look at Apple's X11 soon.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
Well the exact term on the page is "95% complete", and if the 5% that isn't implemented is just never used by game creators, it won't be missed.
DX8 support in wine has been solid for a while now, and it's listed as "95% complete" as well, for what it's worth.