Re: Missing WWN issues

[Eric Pouech]

Francois Gouget a écrit :
> Looking through the WINeHQ CVS I noticed that we are missing 4 WWN
> issues. Fortunately they seem to be available at the Wine Kernel Cousin
> web site... sort of.
>
> Would some kind soul volunteer for retrieving what can be retrieved?
> -
>
> WWN 88 and WWN 89
> http://www.kerneltraffic.org/wine/wn20010314_88.html
> http://www.kerneltraffic.org/wine/wn20010315_89.html
>
> Unfortunately these two appear to be empty so there's not much to
> save.

from my archive, it seems I never wrote the issue #89. Here's what I
have from #88 (basically, it's splitted in articles, but you should be
able to get what you need from it)

A+

@{Title:}
@{MailRef:}
@{MailTitle:}
@{Cat: Evolution}
@{NumPosts:7}
@{StartDate:2001-03-28}
@{EndDate:2001-03-29}

James Robinson asked whether there will 
<quote who="Jame Robinson">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?</quote>

Ulrich Weigand answered <quote long who="UW">
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 a Intel
processor emulator and cannot run Windows/Intel binaries on non-Intel
hardware.
</quote>

Under the same subject of porting Wine, Jutta Wrag asked about Sparc
support. Ulrich Weigand also answered <quote who="UW">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)...</quote>

@{Title:}
@{MailRef:}
@{MailTitle:}
@{Cat: Evolution}
@{NumPosts:9}
@{StartDate:2001-03-24}
@{EndDate:2001-03-25}

Alexandre Julliard committed a patch of his which heavily modified
some command line options:
<ul>
    <li>the --synchronous option is now only available from the
~/.wine config file</li>
    <li>The --desktop, --display and --language command-line
options have been removed</li>
</ul>

An estonished Andreas Mohr asked <quote who="AM">Why would you
consider --desktop to be "obsolete" ?</quote>

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: <quote who="AJ">
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.</quote> (see 
<confer issue="87" item="2">for the details</confer>)

Alexandre explained also that a next patch would allow to change those 
options (like --managed, --desktop...) in the config file, and also on 
a per application basis (see <confer issue="83" item="2">for more
details</confer>).

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.

@{Release: 88}
@{Date: 2001-03-26}
@{Week: 13}

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

@{Posts: 52}
@{Size: 169}
@{NumPosters: 22}
@{NumPostersMultiple: 9}
@{NumPostersLastWeek: 7}

<li>13 posts in 37 K by "Alexandre Julliard" &lt;[e-mail]&gt;
<li>5 posts in 18 K by "James Hatheway" &lt;[e-mail]&gt;
<li>4 posts in 12 K by Andreas Mohr &lt;[e-mail]&gt;
<li>4 posts in 12 K by "Dmitry Timoshkov" &lt;[e-mail]&gt;
<li>3 posts in 9 K by Ulrich Weigand &lt;[e-mail]&gt;
<li>3 posts in 8 K by "Jeremy White" &lt;[e-mail]&gt;
<li>3 posts in 7 K by [e-mail]
<li>2 posts in 6 K by Ian Pilcher &lt;[e-mail]&gt;
<li>2 posts in 18 K by Francois Gouget &lt;[e-mail]&gt;