This is the 107th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).
There's lots and lots and lots of interesting Wine press this week.
First, everyone should go take a look at the interview with Alexandre Julliard over at OSNews. Alexandre covers a lot of different topics including Wine architecture, working with the Win32 API, and some of the various companies working with Wine. There's a link to some screenshots from CodeWeavers too.
The next bit of interesting news comes out of TransGaming and MandrakeSoft. The two companies have partnered together to bundle a unique Linux distribution. Check out the press release for the details. Of course MandrakeSoft makes the popular Mandrake distribution - definitely one of the easiest distros to set up. TransGaming is developing WineX - Wine + all the goodies (DirectX) needed to run games. TransGaming is providing a port of Electronic Arts' "The Sims". Is there anyone out there that hasn't heard of the game? Didn't think so.
So to whet the appetite a bit, here's a screenshot and here's another. Pre-orders supposedly started October 31st (though I couldn't find them anywhere) and shipping is scheduled for November 9th. The package is being called "Mandrake Gaming Edition" and for $69.99 you get Mandrake Linux 8.1, The Sims, and bunch of mornings wondering why you stayed up all night.
But wait, before you put down your Christmas list there's some other TransGaming info you might want to check out. Although this hasn't been addressed here directly, there have been various discussions about TransGaming's business model. Here's one aspect of it:
Now, for some insight into how The Sims got ported, check out this post on LinuxGames. If you scroll down there's a couple of posts from Don Hopkins who worked on the port. The second post is far more interesting - he describes how he helped design The Sims to be portable and he goes on to say how happy he was doing it with Wine. There are several external applications that can be used with The Sims and doing a native port of each would be nearly impossible.
If you read the post above from LinuxGames you might have noticed Loki got slammed pretty hard. Personally, I hate the whole argument of "native vs. Wine ports". Loki has done more to further gaming on Linux than anyone else. The products they put out have been fantastic. I think there's more than enough room in the roughly $6 billion a year gaming industry for a few companies with different approaches. Naturally some games lend themselves better to a native port than others, but as Don points out above - end users care more about functionality than the details of how it was created.
Finally, we have have an announcement from a new company called Lindows. (See that link for the October 23rd press release.) The details are pretty sketchy. Basically the founder of MP3.com, Michael Robertson, has started a company that is going to create a "reliable, easy-to-use, and compatible OS that can run both Linux and Windows software titles". Preview releases are set to be out before year end and Version 1.0 is slated for Q1, 2002. It's a Linux kernel + Wine. ZDNet has an article with a little more detail in it. And John Dvorak also wrote an editorial about it. Will this product ever be more than vaporware? Do you think we'll see patches getting submitted to wine-patches? Only time will tell.
Roger Fujii was having problems getting a program called VirtualDub to work:
there seems to be a funky problem with virtualdub (http://virutaldub.sourceforge.net ). Get differing results between solaris and linux, but both seems to fail before the app comes up.
Under solaris, it seems like something is screwed up with the loader - when it tries to load the binary, it dies in dump_exports because what's at pe_exports is just garbage. Not sure where it's dying under linux (probably the same place) - don't have a devel environment there (yet).
Nothing unusual seems to happen before it gets there (both solaris/linux binaries run sol.exe and other stuff just fine). My suspicion is that the IMAGE_DIRECTORY_ENTRY_EXPORT data isn't pointing to what wine thinks is there, but would like someone who knows more about the loader to say something....
can anyone help shed more light onto this?
Gerard Patel had some insight:
Yes, I have looked at this application. It loads fine under Windows - however, both dependancy walker and the Nt quick viewer are not happy with it (one displays that there is a format error in the exe, the other loops and finally crashes)
The web site says that this executable is compressed with a tool called UPX. This seems to be the reason for the problem, as the original program is compiled with Ms VC++ - not a very exotic tool.
I think that a fix could be to detect a corrupted header in dump_exports and to not try to display anything if numberoffunctions is not coherent with the export section size.
I tried a hack for that and virtualdub got further; however, I see that it is trying to load avicap32.dll and this is not going to work - even under Linux ;:-)
Nerijus Baliunas suggest checking out http://upx.sourceforge.net to unpack it. He also added that Takeshima Hidenori had just submitted a patch adding a stub for avicap32. Gerard got further after unpacking it, but it still died.
Grzegorz Prokopski wants to port a program to Linux using winelib and had some questions:
Q1: Have You heard about anyone who compiled Borland OWL (Object Windows Library) based project with winelib ? Yeah - I know it is an old library and Borland C++ 5.02 is the last version released a few years ago and without future updates.
Anyway I have a project which IS written in OWL and need to check how hard will it be to make it working under Linux without rewriting it all.
I belive I have the sources for complete OWL of course.
Q2: With You expirience what would You say to that statment: If my OWL-based program works under Wine it should be convertable to winelib. How true is that statment ?
Q3: I have read docs about using winelib and seen that there is MS Visual C++ mentioned many times. Does MS VC++ have some kind of support in winemake or in winelib itself ? Does OWL case differ much from MS VC++ ?
Eric Pouech replied to the first question,
well, it might be possible. some folks have been successful with MFC
however, it has to be checked which BCC++ specific extensions were
used by OWL. since OWL is a C++ lib, the DLL linking
is done on decorated names, and since GCC and BCC don't use the same
you need to recompile OWL
. Eric thought it was likely it
could be converted to winelib. Grzegorz didn't think OWL would use
many new Win API features so he didn't think he'd run into a problem
on that front. However, Eric reminded him,
my main concern isn't against API support (some native OWL should run in
wine). it's more compilation issues that we may face (like use of pragma,
specific preprocessor extents..., some 32/16 bit discrepencies).
Compiling MFC under wine is not a piece of cake (and furthermore,
details have never been released because of copyright issues)
This topic spanned a lot of threads. It started with Simon Britnell trying to get the audio to work in Homeworld. Eric Pouech had some suggestions for changing audio.c that might cure the buffer underrun problems Simon was seeing. Simon posted the following note with a patch:
Ove Kåven replied,
Well, it seems like a bad idea to make the player thread enter a busy loop
when there isn't enough data to fill the device buffers, don't you think?
(Well, though I'd like buffer complete notifications to happen more
frequently than they do in Wine's current implementation, making the
player thread use 100% CPU isn't the way...)
Eric Pouech replied it's not a problem if poll was fixed up for it. Ove thought it definitely needed to happen before applying the patch. Then Simon broke in and mentioned he uncovered some race conditions and he needed to fix up the new implementation. Simon and Eric both went to work on working around the problems.
Someone posted a message to the list requesting help getting a some programs to work:
KDX appears to be a client/server app that allows people to connect to servers for file sharing, chatting, and messaging. All the functions are integrated into one client.Hi There
My company produces a few programs that run on Windows and MacOS. Some of the users of these programs have been experimenting using WINE to run the programs on Linux.
This is what they have been saying: "the KDX server runs FLAWLESSLY, 100% perfect, better than solitaire runs"
However, there is one caveat to the above: I'm told that text input doesn't work when running KDX using WINE on Linux.
I was wondering if I would be able to work with WINE developers in making KDX run perfectly on Linux using WINE. I think you would find this to be an easier task than usual because KDX only uses a *minimal* amount of windoze APIs.
For example, KDX implements it's own GUI, it does not use the windoze API for that. Also, KDX even implements it's own graphics routines, it does not use the windoze GDI functions (except for the final step of getting the images onto the screen). KDX loads no obscure DLL's, it's just a single .exe file. It does not use MDI or any crap like that. It does not access the registry. It does not use MFC. So I think it would be much easier for WINE than your average windoze program.
Which probably explains why it's already running well, except there is some bug, probably a minor little thing, that is preventing text input from working.
The website is: http://www.haxial.com
Thanks.
