How Is Wine Doing These Days?

zigzag noted a nice article Summarizing the Wine Architecture. It has some interesting technical stuff, as well as poll results asking what Wine's priorities should be (running Office came first, followed by games. I vote games, but I'm sick of having to run Diablo2 on my crappy old laptop w/o 3D Acceleration since it's my only windows box). Anyway, not a lot there, but this is a seriously important project so take a gander.

Comments

For Christ's sake, FIX THE WINE LOGO

[Ian Schmidt]

For well over a year now Wine has had a correct, nice looking logo which you can view on www.winehq.com yet Slashdot insists on using the ugly, insulting, modified Windows logo.

I hate to get bent over something this trivial, but somebody's gotta.

-Ian, wine-developer, but probably not speaking for all of 'em.

Doing things the NT way

[11223]

Several times in the article it mentions that they're leaning towards doing things the NT way. Is that because of NT's POSIX capabilities and cleaner design, or just because it seems to be better documented?

Related: Are there any status updates on MainWin for Linux? It'd be nice to see that as an easy and well-proven method for porters.

Re:Doing things the NT way

[Ian Schmidt]

WineLib is getting to be very well-proven indeed. In addition to the port you've heard of (Canvas), there's a whole slew of others in progress covering everything from text editors to CAD packages. Deneba's success with Canvas pretty much opened the floodgates based on traffic on the mailing list and news group, and personally I think it's all good :-)

As for NT, the reasoning is much as you say. It's both *far* cleaner than Win9x (no 16-bit code, no VxDs running wild in kernel mode) and generally far better documented. Plus, MS's stated goal is to eventually merge all their OSes onto a NT/2000 based kernel. It hasn't happened yet (Windows ME, shipping this fall, is still DOS-based) and there are rumors of ANOTHER DOS-based Windows after WinME, but if you believe MS it will eventually.

not games....yet

[fluxrad]

supporting games in linux with WINE is not necessarily a good ideal to shoot for. At it's best, it's crappy windows emulation with worse performance, at it's worst, it's an excuse for game coders to say "bah - they've got wine, why code fo linux now?"

Additionally, there are a lot more games coming out for linux now than ever before - alot of the top games are now available for linux, and although i never really liked diablo, i REALLY want to see a half-life client. - GIMME MY FSCKING COUNTER-STRIKE IN LINUX DAMNIT!!!! Anyway, the place we need to be looking is just all around kick-ass compatibility/ability to use generic windows software. Office would be nice, but we do have several alternatives there. I would personally like to see programs like Mplayer and Acid or ReBirth with better support. I have, though, seen wine go from a puny little program that helped you run windows apps like minesweeper, into a powerful tool that even professional coders (like the folks at Corel) are using. The guys at wine should keep doing what they're doing and we'll see wine go exactly where it needs to go.


FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network

WINE is NOT EMU

[Dungeon Dweller]

A little info on WINE, it doesn't actually EMULATE. What it does do is allow for Windows executables to be loaded on the platforms that WINE is compiled under. It also feeds the applications with false information/conversions needed in order to operate under this environment. For instance, my C: drive is actually a FAT32 partition loaded under Linux. In the config file, it is /mnt/fat-c. When the program asks for the C: drive, WINE returns that mount point as if it were the C: drive. It can also pass info to my sound and networking capabilities.

Interestingly, WINE just sort of started as a posting to a news group on letting Linux load Windows binaries, which it technically can with a little kernel hacking, it just won't actually RUN them if they need the .dll's and environment that Windows provides.

WINE may never be able to run programs quite as fast as Windows, but supposing that the Linux equivalents of the DLL's used by Windows apps are faster, it actually is theoretically possible that it could run programs FASTER. The steps are translation, not emulation.

Re:Shifty APIs

[Ian Schmidt]

The main reason is that apps sometimes pull weird tricks for specific OS versions. The command line winver switch in Wine doesn't actually change the behavior of anything, it just changes what value the GetVersion() APIs return to Windows apps. The best example of this is Internet Explorer 5.0. When running on Win95, it uses the well-documented (if gross) VxD calls to allocate and manage memory blocks. When running on Win98, the identical binary uses some undocumented features that Wine doesn't support yet. Result: -winver win95 displays pictures on web pages, -winver win98 doesn't :-)

As an aside, this sort of thing is basically a symptom of the fact that MS is now held hostage by their own massive installed base. Before you laugh, read on ;-) It *doesn't matter* what APIs they add/change in Win2000, because all software for the next several years (including Office) will still need to run on MS operating systems all the way back to Win95. This is great for Wine, since it lets it catch up with MS while Windows is essentially stuck in a rut.

MS got away with "out-innovating" OS/2 on APIs in the early 90s because Windows 3.0 and 3.1 were just starting to take off, so there was no legacy software to worry about breaking. But as early as Win95 they started doing things like not fixing documented bugs in APIs because it would break existing application software.

It's actually funny to think about - their own monopoly is strangling them :-)