WINE 991031 (Hallowine) Released

Egonis Similaris writes " WINE 991031 (Hallowine) has been released." My main personal WINE wish is to use it to run Quickbooks. Has anyone else gotten QB to work reliably under WINE?

Comments

Re:What does WINE stand for?

[SgtPepper]

WINE Is Not an Emulator

Because everythings native it doesn't really EMULATE anything, it REPLACES or DUPLICATES

What Corel's Doing

[Ian Schmidt]

Wine has always been 2 projects in one. The actual Windows API reimplementation (WineLib) and a binary loader (Wine, or "the emulator part" as some people refer to it) which loads windows EXE and DLL files and hooks them up with the API stuff in WineLib. The binary loader itself is basically small and bugless - .EXE files are typically a lot less sophisticated than Unix ELF binaries and shared libraries so there's not much to do there in the first place.

So, Corel has put a lot of work into the Windows reimplementation end of things, reorganizing Wine's COM support and header files so you can now compile MFC (which contains a fair amount of MS "insider coding", although luckily you get the source with MSVC++) under WineLib. They also paid Cygnus to do the anonymous struct and union patches which everyone now gets to enjoy in GCC 2.95.2. As a result of this work they now have a common codebase between Windows and Linux for their office applications.

The best part is they've been willing to do all this work to the specs of Wine's current "Linus", Alexandre Julliard. So wine's gotten a ton of good professional work on stuff the regular spare-time developers would have taken much longer on. We now have a solid infrastructure for Win32 threading, impressive OLE/COM support, a much more debugged user interface, and lots of common controls.

As a result it's almost more accurate to say Corel was under Wine's wing - they've had patches rejected due to conflicts with Alexandre's architectural vision, and promptly resubmitted them with everything fixed. I wish all companies involved in open source were that way :)

Anyway, the first stage of that involvement's coming to a close. Corel naturally won't tell us their actual progress with their apps, but they are known to be working on an installer now and their recent patches have been for progressively more obscure bugs. Incidentally, their work has made a lot of other applications work much better too. ModPlug Tracker, a popular Windows tracker-style music application, now works with nary a glitch on Wine. Less than 6 months ago it was unstable and full of graphical glitches.

And as far as claims that app support is getting worse, that's generally false. As with any large project there are frequently bugs that break certain apps, and sometimes apps work accidentally due to combinations of bugs and stop when that bug is fixed. Most people track the "official" releases instead of CVS so something breaks and they don't see that it's fixed again the next day in CVS and end up with the wrong impression :)

-Ian, wine-devel but not speaking for 'em.

Wine = What I Never Execute.

[cybrthng]

Wine is a great idea, but for the years its been in the running, and the changes its evolved through i don't see it ever really completing.

There was another package that was anounced on slashdot a few weeks ago about a "winelib" type programming package that is coming so people can just cross compile.. dunno if we will see that..

I get solitaire to run, i've had other programs run, but once they work *DON'T* upgrade or make any changes, or else it may blow up.

I'd like to see wine start from square one. They have plenty of code to scavange through, they have a HUGE amount of the API documented and coded, but the project has evolved into such a beast that it limits out any growth in a direction that wasn't planned for a few years back.

Make a 1.0 milestone, say in 1.0 we will support Windows 3.1 apps, in 1.1 we will support win32, in 2.0 we will support Win95, in 3.0 we will support NT or whatever it may be.. but make it work for one layer, produce a 1.0 binary, get it in use, get the quirks resolved, have the foundation, learn from your mistakes, if it needs some re-work, re-work it, and then evolve it on up (only after feature locks, and then feature planning)

Re:Wine = What I Never Execute.

[Ed Avis]

I'm running Word and Excel 97 SR-2. Now, I do have a complete Win98 install on the old DOS partition, including IE4, so perhaps if IE is required, they're just relying on the one that's installed over there? (I might add, IE4 almost works; I can start to view simple web pages before it kicks me to the debugger.)

Technically, you are breaking the licence agreement for bgIE; it says that you may run it only on Windows. Whether this is actually illegal is another matter, especially as you actually own a Win98 licence (or I expect you do :-). There was a rather inconclusive discussion about a similar topic in an earlier story.

But I wasn't aware that Word and Excel 97 required IE (don't know about 2000). I'm sure they automatically install it given half the chance, though (like most other MS products).

Office 97 requires IE3 or later. I've recently tried running it on an IE-less Win98 system (Revenge of Mozilla is excellent), and while apps loaded after complaining about DLLs, you couldn't do anything (like open a file) without the thing breaking. Presumably the new file open dialogue box is part of IE. After I installed IE3 things worked.

Re:Wine = What I Never Execute.

[Pretender]

First, Wine has made incredible strides in the last year. By incredible I mean "I can't believe how many more applications, including popular ones, work or work better now."

Second, it's the Wine people themselves who are also working on winelib; it's sort of a serendipitous project, I believe. That's not coming along quite as quickly last I checked, but if Corel really is getting involved then maybe that will change. Not sure how that has gone.

I have been upgrading at every release for the last six months and the only time things have ever "broken" as the result of an upgrade, it has been because they changed the options or the .conf file and I didn't pay attention. Usually five minutes later and everything's working again.

I should point out that I no longer use precompiled binaries; the code base is sort of large but it's worth it to compile it yourself. I fixed a lot of things by doing that. (Having to stick with glibc 2.0.7 for the time being sort of forced that as well.)

I don't think that what they're doing lends itself to nailing down the releases the way you suggest (1.0=Win31, 1.1=win32, etc.). It's hard to know what's what in the vast undocumented world of the Win32 API's. They're really doing a fantastic job these days, anyway - if you haven't tried it in a few months, try it.

These people are the ones who make it possible for people like me, in corporate NT-only settings, to survive with a dedicated Linux desktop.

In the last two upgrades, fonts have improved dramatically, and I can run Word and Excel (although printing is still a bit sticky).

Hope this clears some things up.

Re:Intuit has only had TWO calls for Linux version

[jd]

Be fair. She was correct, to within the accuracy defined by the new ActiveErrorMargin(tm) controls, as demonstrated by William "Nobody talks to me about Linux" Gates.