This is the 88th 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).
James Robinson asked whether there will
be a port of WINE to OS/390 mainframe USS?
LINUX runs fine under USS, so it would seem that WINE should run there
as well. Has anyone done this yet?
Ulrich Weigand answered:
To clear up a possible misunderstanding first: Linux for S/390 does *not* run under USS or under OS/390.
OS/390 is (one of) the standard operating system(s) used on S/390 mainframes. One component of OS/390, the Unix System Services (USS), provides an environment that allows to run certain Unix applications. However, USS is not itself an operating system, just an ABI layer on top of OS/390 (somewhat similar to the POSIX subsystem of Windows NT).
Linux for S/390, on the other hand, is a true port of the Linux operating system to the S/390 hardware. It runs directly on the S/390 platform, *instead* of OS/390 or any other mainframe operating system.
This has the effect that while USS is much more integrated into the OS/390 environment, Linux on S/390 is much more similar to 'real' Unix platforms. Porting Unix or Linux applications to USS is often non-trivial (e.g. gcc does not run on USS at all), while porting to Linux on S/390 is most of the time just a recompile.
What I want to say by that is that a port of Wine to *USS* seems rather unlikely, given the difficulties I mentioned. However, a port to *Linux* on S/390 should really be possible, and some time ago I already did a proof-of-concept implementation.
Of course, a port of Wine to any non-Intel hardware means just a port of the Wine *library* at the moment, as Wine does not contain an Intel processor emulator and cannot run Windows/Intel binaries on non-Intel hardware.
Under the same subject of porting Wine, Jutta Wrag asked about Sparc support. Ulrich also answered:
I did send my fixes to Alexandre; I think the current release should build on Sparc (unless it has been broken again in the meantime -- I haven't tried for some time).
In any case, that is a port to Sparc32; Sparc64 is another issue completely (and probably much more difficult)...
Alexandre Julliard committed a patch of his which heavily modified some command line options:
- the --synchronous option is now only available from the ~/.wine config file
- The --desktop, --display and --language command-line options have been removed
An astonished Andreas Mohr asked, Why would you
consider --desktop to be "obsolete" ?
Alexandre explained it was the start of a larger modification (to move towards 1.0), which would involve removing almost all command line options. Alexandre explained a bit his motivations:
Because with these command-line options kernel32 must know about and export information specific to x11drv.
Also there's a larger issue of mechanism vs. policy; if we want to be able to use the same set of Wine libraries for multiple usage (wine loader, Winelib apps, mp3 players loading Windows dlls, etc.) we need to move all policy decisions to the higher layers. We cannot have kernel32 enforce a specific command-line usage, since this doesn't apply in all cases.
For another instance of the same issue, see the discussion about the deferred debug trace a couple of weeks ago: we need the Wine libraries to provide the *mechanism* to display tracing and other informations, but the *policy* of when and how to switch tracing on or off must be moved to higher layers (like the debugger) instead of hardcoding a magic key sequence in user32.
(see issue #87 for the details.)
Alexandre explained also that another patch would allow those options to be changed (like --managed, --desktop...) in the config file, and also on a per application basis (see issue #83 for more details).
Lots of developpers felt unconfortable with the trends taken by this patch, and requested that the command line options to be still available.
One potential solution would be to run Wine from a script which would support such command line options and set the configuration files accordingly.
Just wanted to let everyone know that the TransGaming DirectX development is now being hosted at SourceForge. You can get updates from our live CVS tree, discuss DirectX specific issues on the 'WineX-devel' mailing list, etc. The SourceForge project page is at:
http://sourceforge.net/project/winex
The CVSROOT for CVS is:
:pserver:anonymous_at_cvs.winex.sourceforge.net:/cvsroot/winex
We're doing WineHQ merge-ins every week or two, so things should stay relatively up to date.
Currently, we're undertaking a rearchitecture of the Direct3D work, along the lines of the DDraw HAL work we've been contributing to the WineHQ tree. Basically, we're separating the glX code into the x11drv for device independance. We're also redoing the front end interfaces to start supporting D3D APIs both older and newer than D3D 7.
On the OpenGL front, we've done some work on the visual management code that solves some problems we were seeing where you couldn't get a double-buffered visual on some cards without using -desktop mode. I should be posting a patch for this back to wine-patches very soon. There are still some kinks to be worked out...