WWN Issue 88

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).

This week, 52 posts consumed 169 K. There were 22 different contributors. 9 (40%) posted more than once. 7 (31%) posted last week too.

The top 5 posters of the week were:

13 posts in 37K by Alexandre Julliard
5 posts in 18K by James Hatheway
4 posts in 12K by Dmitry Timoshkov
4 posts in 12K by Andreas Mohr
3 posts in 7K by Lawson Whitney

Ports to OS/390 and Sparc Machines	03/21/2001	Archive
Ports 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)...

Ports to OS/390 and Sparc Machines

03/21/2001

Archive

Ports

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)...

Removal of Commandline Options 03/23/2001 Archive

Removal of Commandline Options	03/23/2001	Archive
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 information, 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.

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 information, 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.

WineX on SourceForge	03/26/2001	Archive
TransGaming 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 independence. 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...

World Wine News