WWN: wn20030822_184.xml

Fri Aug 22 01:11:51 CDT 2003

wn20030822_184.xml

-brian
-------------- next part --------------
<?xml version="1.0" ?>
<kc>

<title>Wine Traffic</title>

<author contact="http://www.theshell.com/~vinn">Brian Vincent</author>
<issue num="184" date="08/22/2003" />
<intro> This is the 184th release of the weekly Wine Weekly News publication.
Its main goal is to be amazed at the sheer number of virus emails received this week. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at <a href="http://www.winehq.com">www.winehq.com</a> </intro>
<stats posts="186" size="662" contrib="58" multiples="33" lastweek="24">

<person posts="16" size="44" who="Eric Pouech" />
<person posts="14" size="34" who="Dmitry Timoshkov" />
<person posts="18" size="94" who="Dimitrie O. Paun" />
<person posts="9" size="23" who="Steven Edwards" />
<person posts="9" size="23" who="Alexandre Julliard" />
<person posts="8" size="26" who="Sylvain Petreolle" />
<person posts="8" size="24" who="Francois Gouget" />
<person posts="7" size="15" who=" &lt;puoti at inwind.it&gt;" />
<person posts="6" size="17" who="Jonathan Wilson" />
<person posts="5" size="19" who="Kelly Leahy" />
<person posts="5" size="15" who="Maxime Bellenge" />
<person posts="4" size="17" who=" (Dominik Strasser)" />
<person posts="4" size="9" who="Gregory M. Turner" />
<person posts="4" size="8" who="Tom" />
<person posts="3" size="32" who="Martin Wilck" />
<person posts="3" size="12" who="Marcelo Duarte" />
<person posts="3" size="9" who="admiral coeyman" />
<person posts="3" size="8" who="Alex Pasadyn" />
<person posts="3" size="8" who="Gerald Pfeifer" />
<person posts="3" size="8" who="Richard Cohen" />
<person posts="3" size="6" who="Jon Griffiths" />
<person posts="3" size="6" who="Steven Edwards" />
<person posts="2" size="82" who="Subhobroto Sinha" />
<person posts="2" size="9" who="root" />
<person posts="2" size="7" who="Shachar Shemesh" />
<person posts="2" size="6" who="Jim White" />
<person posts="2" size="5" who="Christian Costa" />
<person posts="2" size="4" who="Jeremy Newman" />
<person posts="2" size="4" who="Robert North" />
<person posts="2" size="4" who="Martin Fuchs" />
<person posts="2" size="3" who="Jukka Heinonen" />
<person posts="2" size="3" who="Ferenc Wagner" />
<person posts="1" size="3" who="Martin Troester" />
<person posts="1" size="3" who="Jakob Eriksson" />
<person posts="1" size="3" who="Martin Fuchs" />
<person posts="1" size="3" who="Rok Mandeljc" />
<person posts="1" size="3" who="John K. Hohm" />
<person posts="1" size="3" who="Keith Matthews" />
<person posts="1" size="3" who="Ulrich Weigand" />
<person posts="1" size="2" who="Lionel Ulmer" />
<person posts="1" size="2" who="Mike Hearn" />
<person posts="1" size="2" who="Jeff Smith" />
<person posts="1" size="2" who="Felipe Wilhelms Damasio" />
<person posts="2" size="4" who="Marcus Meissner" />
<person posts="1" size="2" who="Boaz Harrosh" />
<person posts="1" size="2" who="David Laight" />
<person posts="1" size="2" who="PETREOLLE Sylvain" />
<person posts="1" size="2" who="Fabian Cenedese" />
<person posts="1" size="2" who="Dustin Navea" />
<person posts="1" size="2" who="Troy Rollo" />
<person posts="1" size="2" who="Dave Miller" />
<person posts="1" size="1" who="E Lea" />
<person posts="1" size="1" who="Rein Klazes" />
<person posts="1" size="1" who="flyker" />
<person posts="1" size="1" who="Jason Edmeades" />

</stats>
<section 
	title="News: Interview with Jeremy White, Frontier &amp; Wine" 
	subject="News"
	archive="http://www.winehq.com"
	posts="2"
	startdate="08/16/2003"
	enddate="08/22/2003"
>
<topic>News</topic>
<p>The <a href="http://www.lpbn.org">Linux Public Broadcasting Network</a>
did a <a href="http://www.lpbn.org/modules.php?op=modload&amp;name=News&amp;file=article&amp;sid=416&amp;mode=thread&amp;order=0&amp;thold=0">series</a>
of interviews at Linux World about proprietary vs. open source 
development.  <a href="http://stream.lpbn.org:81/files/CodeWeavers.mov">Jeremy White</a> from CodeWeavers
took part.  I haven't had a chance to see it yet so I don't have much
to say about it.</p>

I happened to stumble 
across a screenshot of 
<a href="http://www.wiredfool.com/discuss/msgReader$1301?mode=topic">Frontier 
running under Wine</a> on Linux
being displayed on a remote MacOS X client. 
<a href="http://frontier.userland.com">Frontier</a> is a 
web content management system.

There's a few other pages out there that describe
the specifics of how to get it to run under Wine:

[<a href="http://inessential.com/linux/frontierunderwine.php">page 1</a>]
[<a href="http://www.wiredfool.com/discuss/msgReader$1299">page 2</a>]

</p><p>
I also poked around on the 
<a href="http://www.freelists.org/archives/cad-linux/">cad-linux</a> 
mailing list and noticed a bunch of
people are trying out all sorts of CAD programs under Wine.
</p>
</section>
<section 
	title="Evolution of Wine's File Management" 
	subject="RFC: evolution of file management"
	archive="http://www.winehq.com/hypermail/wine-devel/2003/08/0358.html" 
	posts="9"
	startdate="08/19/2003"
	enddate="08/21/2003"
>
<topic>Filesystems</topic>
<p>Over the past decade of Wine development there have been
massive changes to the underlying filesystems developed by
Microsoft.  Many new features have been added and API support
for those features has grown.  Support in Wine has been minimal,
partly because what's there works and messing with such an important
part of Wine is dangerous.  However, Eric Pouech and Alexandre Julliard
have been working on a separation of kernel32 and ntdll. That work
prompted Eric to give an update on it and ask for comments on the
future direction:</p>

<quote who="Eric Pouech">
In the process of separating ntdll from kernel32, one of the next hurdles 
is the implementation of NtCreateFile.
Since it's rather a core API, some thoughts are needed. Moreover, there 
are a few shortcomings in current file handling we might want to address.

The goal of this small RFC is to:
<ol>
 <li> gather all known shortcomings of current file implementation </li>
 <li> propose some solutions and roadmaps for the implementation </li>
</ol>
feel free to add your own remarks to these lists.

shortcomings

 <ol> 
  <li>no dynamicity in DOS drive management: user should be able, in 
his/her   session(1), to either change the mapping of a DOS drive 
letter, or mount a SMB share somewhere...)</li>
  <li> mounting should be done session wide and not process wide, and of 
course shared across processes</li>
  <li> ntdll and kernel32 are not separated regarding file management</li>
  <li> devices (vxd and DOS) management is still a hack</li>
  <li> it may be necessary to introduce a notion of filesystem for some 
operations (open, read, write, seek, close, dir_enum, ioctl) in order to 
support several FS (unix, smb...)</li>
  <li> poor management of ejectable devices</li>
  <li> short/long file name conversion should be consistent (across 
several processes in the same session, across several sessions)</li>
</ol>

</p><p>Note: (1) a session is linked to a running instance of the wineserver</p>

<p> <u>proposal</u>
<ol>
<li> "path gates" (target: #1, #2, #3/partly, #4/partly, #6/partly)
all file names will be handled using the NT-style:
<ul>
 <li>DOS paths (C:\foo\bar) into \??\C:\foo\bar</li>
 <li> network paths (\\station\foo\bar) into \??\UNC\station\foo\bar</li>
 <li> DOS device names (CON) into \??\CON</li>
 <li> NT device names (\\.\PhysicalDrive0) into \??\PhysicalDrive0</li>
 <li> a VXD ?? (normally \\.\VFD) into \??\VFD </li></ul>
<br /><br />
the device concept will disappear and be replaced by a "path gate":
<ul>
	in NT-Win32 name space, point where to convert from a
	NT-path to a Unix-path <br /><br />

	for example, assuming we have created a path-gate from
	\\??\c: to /mnt/windows, the NT-path \\??\c:\foo\bar
	will be transformed into the unix-path /mnt/windows/foo/bar
</ul>

the path-gate will hold the current options that the device currently 
does (case sensivity, fixed/removable...)
<br /><br />
path-gates will be stored in the server (they are session wide)
<br /><br />
management of VxD and devices could benefit from it: they could be path 
gates pointing to them selves (or nothing ?)
</li>
<li>FS (target: #4/partly, #5/partly, #6/partly)
<br /><br />
I'm still wondering if we really need a FS (even a very simplistic one) 
in Wine
</li>
<li>short/long file names (target #7)
<br /><br />
since current short file name management seems satisfactory, there's no 
need IMO to move short/long names conversion in the server</li>
</ol></p></quote>

Martin Fuchs pointed out some of the lower-level structures
 used in NT to represent filesystem hierarchies:
<quote who="Martin Fuchs">
 It would be good to implement this "path gates" as near as possible 
 like the way it is implemented in Windows NT/XP. This mapping is done 
 using the NT object namespace. Object namespace is another virtual tree 
 structure similar to a file system or the registry. It is accessed by 
 functions like NtOpenDirectoryObject(), NtOpenSymbolicLinkObject(), 
 NtQueryDirectoryObject(), NtQuerySymbolicLinkObject(), ... There has 
 been a tool in the internet called "winobj.exe", with which you can 
 examine this internal NT object namespace. However it is not compatible
 to XP, I don't know, if someone has yet updated it. But I do have a own
 program which can display it also for XP.

 Drive mapping is stored as symbolic links for example at "\GLOBAL??\D:".
 This links point to the partitions, like e.g. "\Device\HarddiskVolume3".
 There are also the ArcNames, which you can find in the NT bootloader config
 file "boot.ini". At "\ArcName\multi(0)disk(0)rdisk(0)" you can find another
 symbolic link to "\Device\Harddisk0\Partition0".

 This examples are from my XP system. System versions before XP used a
 bit of another mapping schema. 

 By the way: You can also find the whole registry as a subtree in the NT
 object namespace at paths like "\REGISTRY\HKEY_LOCAL_MACHINE\.... Would
 not be bad, if we could implement this also.
</quote>

Eric seemed to have taken that into consideration and replied:
<quote who="Eric Pouech">
I do know how it's implemented in NT.

anyway, there are a few differences between ROS and Wine:
<ul>
 <li> in common, we do need to have the same interface as Windows do. This 
only applies to interface living in user land.</li>
 <li> kernel land is another matter. ROS needs to stick to NT's behavior, 
Wine needs to convert calls to what Unix does provide.</li>
 <li> ROS needs to mount physical drives, Wine makes (it's the current 
implementation, this is open to discussion) part of the Unix file 
hierarchy visible from the windows part</li></ul>

Regarding file support, the minimal things Wine need to do is:
<ul>
 <li> support the same file naming as NT does (mainly the \??\ part of the 
NT name space), the rest is not absolutely needed. Currently, Wine does 
not implement a unique name space for all the objects (as NT does, using 
sub dir for some differenciation) but rather different name spaces</li>
 <li> to allow the mapping from a NT path to a unix path, there are two 
simple ways to do it:
 <ol>
	 <li> use all NT name space and somehow inject Unix file name space (/ and 
          all the subdirs) in it</li>
	 <li> store the unix information (the path in the unix / hierarchy) as a 
          specific attribute of the NT name space (at least the \??\ subtree)</li>
 </ol></li></ul></p><p>
I chose the second approach (you're more proposing the first one) 
because I felt it was more suited to wine behavior.
</p><p>
Concerning NTDLL's directory objects, I'm still wondering if we need (in 
Wine) to implement them. It's indeed needed in NTDLL's interface (object 
attribute for instance) and implements part of the "path gate" 
(especially some attributes like case sensivity in further lookups...). 
So, this is still part of the open questions I have (I may start without 
directory objects, and add them later on).
</p><p>
One of the strength of current NT name space is the orthogonality which 
is used across all objects in NTDLL (for example, in handle management, 
or sending requests - thru IRPs - at all the objects).
The good side is to be able to convert an operation on a file into an 
IRP which is send to the FS which handles the file, which can in turn 
send it or transform it to another part...
As wine implements a more monolithic approach, and since we don't have 
this orthoganility available today, I'm not yet convinced we need to 
stick more to the NT behavior than what I described above as the minimal 
requirements.
</p></quote>

<p>Ferenc Wagner wanted to know about other details,
<quote who="Ferenc Wagner">
 Do we need attributes like hidden, system, etc?</quote></p>

<p>Keith Matthews expanded on that:</p>
<quote who="Keith Matthews"><p>
More to the point we need attributes to allow support of NT ACLs.  I've
been looking at the problem and progressing only very slowly, some of
the problems are technical, others are nothing to do with Wine at all.
</p><p>
At the level we are dealing with here the essential problems (for those
who have not examined the issues) are :-
<ul>
	<li>Not all supported O/S s offer ACLs.</li>

	<li>Those that do support POSIX ACLs which do not map exactly to NT ACLs</li>

	<li>Even in Systems which do support POSIX ACLs there is no guarantee that
	all disc filesystems at any one host will offer it, Of the Linux
	filesystem types only XFS supports ACLs out of the box. Work is in
	progress for ReiserFS and due to start for JFS. There is a patch for
	ext2/3. One map currently favoured is to use ext2/3/Reiser for the root
	filesystem and XFS for (some of) the rest).</li>
</ul></p><p>
All of the systems that do support ACLs use Extended Attributes to store
them. I am still looking at limitations on number of EAs, but there is a
possibility that an extreme case on NT may not be supported on Linux.
</p><p>
Since I've not yet got round to looking at TrustedBSD there's
potentially another can of worms there.
</p><p>
My conclusion is that we do (regrettably) need a VFS layer to harmonise
handling of all this lot and respond correctly when wine-ver is 9X.
</p></quote>

<p>Eric disagreed:</p>
<quote who="Eric Pouech"><p>
I think Wine's goal is to provide this kind of feature of top of what 
the underlying OS provides (this is also the case for DOS HIDDEN and 
SYSTEM attributes => there are not available in standard Posix FS, so 
are managed by wine(*)). So IMO, file (protected by ACL) access should 
be provided by the underlying OS.
</p><p>
ACL manipulation (from windows to posix - even if 1003.1e hasn't been 
voted by POSIX) should be added (I'm not sure we have a 1:1 mapping anyway)
however, I don't understand your remark about the winver 9x... IMO, if 
the Linux user mounts a NT partition with ACL (and has the proper 
privileges) it should run Wine on this partition rather transparently 
(except for ACL manipulation function)
it's not my goal to support:
<ul>
 <li> real FS mounting in wine => this is the job of the OS, not wine's</li>
 <li> a real VFS (as Linux does)</li>
 <li> the (V)FS I'm talking about is more related to adaptation (as you 
    mention), but I'm not sure I got you right</li></ul></p>
 <p>
 (*) except files starting with a . which get the HIDDEN attribute</p>
</quote>

Robert North gave a pointer so some work being done at the
kernel filesystem level:
<quote who="Robert North">
Can't really answer your question,
but on the kernel mailing list, There has been some discussion of
whether these attributes should be exposed from mounted fat partitions:
The fat fs maintainer has a patch, and is wondering what to do with it.
(The patch exposes the fat attributes as extended attributes)

See the thread titled "[RFC] ioctl vs xattr for the filesystem specific
attributes".
</quote>

<p>Eric mentioned that it would require opening the file to get the
attributes and wondered what effect that would have on performance.</p>

<p>No one had any large objections (yet) so perhaps we'll see an
implementation in the near future.</p>

</section>
<section 
	title="Update On Last Weeks' Feature" 
	subject="Update On Last Weeks' Feature"
	archive="http://www.winehq.com/" 
	posts="1"
	startdate="08/20/2003"
>
<topic>Licensing</topic>
<p>Gerald Pfeifer pointed out that last week's feature article
on <a href="http://www.winehq.com/site?issue=183#Feature:%20Wine%20History">Wine's
history</a> had some mistakes concerning specifics of LGPL provisions.
Specifically, I wrote the following:</p>
<quote who="Brian Vincent">
<p><ul>
<li>All changes to the source code must be made available </li>
<li>Anyone redistributing Wine must provide access to the source code under the original terms of the LGPL </li>
<li>However, anyone who wishes to simply "link" their own Windows program to Wine can do so without having to make their source code available. </li>
</ul></p></quote>

That's not really correct. You don't have to make changes available
in all instances. Here's what I should have written:
<quote who="Brian Vincent">
<ul>
<li>Source code (including all changes from the original Wine sources)
 must be made available to people who receive a binary of Wine. This
 also applies if Wine is used as a library, in which case only the
 source of Wine (including all changes) must be made available.</li>

<li>Simply linking with Wine does not mean you need to make the source
code available for your program.
</li></ul></quote>

<p>As always, please refer to the 
<a href="http://www.fsf.org/licenses/licenses.html">Free Software 
Foundation's website</a> for specifics of their licenses.</p>

</section>
<section 
	title="Environment Variable Handling in Wine's Config" 
	subject="REGRESSION: environment variables no longer possible"
	archive="http://www.winehq.com/hypermail/wine-devel/2003/08/0342.html" 
	posts="7"
	startdate="08/19/2003"
>
<topic>Configuration</topic>
<p>Marcus Meissner wondered why Alexandre committed a patch
that changed the way environment varibles were handled:</p>
<quote who="Marcus Meissner"><p>

Apparently the changes from yesterday removed support of environment variables
in registry keys (very useful for the "Path" keys in the "Drive" sections).

Can it be readded? Or is there a rational behind it?
</quote>

<p>Dmitry Timoshkov pointed out how to make it work:</p>
<quote who="Dmitry Timoshkov"><p>

Actually it's just the format of the Wine config has changed. Now all
 environment variables should be surrounded by the percent signes (%HOME%),
 and are handled by the normal registry code. Alexandre has changed the sample
 config as well.
</quote>

<p>Alexandre clarified why,
<quote who="Alexandre Julliard">
 Actually the format of the config has not really changed, most entries
have been behaving that way for a long time already. I just made the
drives part of the config behave like all the other entries.</quote></p>
</section>
<section 
	title="FreeBSD, OpenGL, and Pthreads" 
	subject="Build broken due to -lpthread"
	archive="http://www.winehq.com/hypermail/wine-devel/2003/08/0401.html" 
	posts="4"
	startdate="08/20/2003"
	enddate="08/21/2003"
>
<topic>Ports</topic>
<topic>Build Process</topic>
<p>Gerald Pfeifer reported a problem compiling Wine under FreeBSD.
It seemed to manifest itself when linking with the pthread library.
Alexandre then asked,
<quote who="Alexandre Julliard">
So what's the right way to link with libpthread on FreeBSD?</quote></p>

Gerald messed around and found a solution,
<quote who="Gerald Pfeifer">
Wine builds fine if I just omit the -lpthread line above.
</quote>

<p>Specifically, the line he meant was this:
<code>  /usr/bin/gcc -shared  -Wl,-Bsymbolic,-z,defs glu32.spec.o    glu.o
    glu32.dll.dbg.o -o glu32.dll.so -L../../dlls  -L../../libs/wine -lwine
    -L/usr/X11R6/lib  -lSM -lICE -lXxf86dga -lXxf86vm -lXv -lXext -lX11
    -lGL -lGLU -lpthread -L../../libs/port -lwine_port  -lm  -lc
</code></p>

He researched a little more and found a better solution:
<quote who="Gerald Pfeifer">
 If I simply remove -lpthread from
<ul>
 <li>dlls/glu32/Makefile</li>
 <li> dlls/d3d8/Makefile</li>
 <li> dlls/d3d9/Makefile</li>
 <li> dlls/d3dx8/Makefile</li>
 <li> dlls/opengl32/Makefile </li></ul>

Wine, builds without problems.
</quote>

<p>Alexandre then made some changes in CVS that did just that.</p>

</section>
<section 
	title="Top 10 Reasons For Using Fox Under Wine" 
	subject="Re: [Foxgui-users]Re: Wine fixes (1)"
	archive="http://www.winehq.com/hypermail/wine-devel/2003/08/0377.html" 
	posts="1"
	startdate="08/20/2003"
>
<topic>Ports</topic>
<p>Apparently there's yet another cross-platform GUI toolkit out
there called FOX.  From the 
<a href="http://www.fox-toolkit.org/">FOX Toolkit website</a>:
<quote who="Fox">
 FOX is a C++ based Toolkit for developing Graphical User Interfaces easily 
 and effectively. It offers a wide, and growing, collection of Controls, and 
 provides state of the art facilities such as drag and drop, selection, as 
 well as OpenGL widgets for 3D graphical manipulation. FOX also implements 
 icons, images, and user-convenience features such as status line help, and 
 tooltips.Tooltips may even be used for 3D objects! 
</quote></p>

Someone posted a patch to that project to add support for 
Wine. The maintainer wondered why bother since there was a
native version, but he added it anyway. (Of course, that 
seems to beg the question, why have yet another cross-platform
GUI toolkit.. but that's besides the point.) Dimi Paun decided
to list some reasons why a port to Wine is good:
<quote who="Dimitrie Paun">

Top 10 reasons you want Fox ported to Wine:
<ul>
 10. Windows sux<br />
  9. Microsoft is evil<br />
  8. Test windows features without rebooting (as Doug mentioned)<br />
  7. Keep development on Linux<br />
  6. Run valgrind on the Windows port<br /> 
  5. Make sure the Win32 part is portable to multiple implementations<br />
  4. Help find missing features/problems/etc. in Wine<br />
  3. Some people may prefer the Wine widgets to the GTK+ ones<br />
  2. wxWindows is already ported to Wine, Fox needs that too! ;)<br />
</ul></p><p>
and the number one reason is:
<ul>
  1. It is just cool!!! <br />
</ul></p><p>
     (what geek can resist this sort of virtualization? :))
</p></quote>
</section></kc>