Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Wine Traffic #184 For 22 Aug 2003

By Brian Vincent

Table Of Contents

Introduction

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 www.winehq.com

Mailing List Stats For This Week

We looked at 186 posts in 662K.

There were 58 different contributors. 33 posted more than once. 24 posted last week too.

The top posters of the week were:

1. News: Interview with Jeremy White, Frontier & Wine

16 Aug 2003 - 22 Aug 2003 (2 posts) Archive Link: "News"

Topics: News

People: CodeWeaversJeremy WhiteNews

The Linux Public Broadcasting Network did a series of interviews at Linux World about proprietary vs. open source development. Jeremy White from CodeWeavers took part. I haven't had a chance to see it yet so I don't have much to say about it.

I happened to stumble across a screenshot of Frontier running under Wine on Linux being displayed on a remote MacOS X client. Frontier 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: [page 1] [page 2]

I also poked around on the cad-linux mailing list and noticed a bunch of people are trying out all sorts of CAD programs under Wine.

2. Evolution of Wine's File Management

19 Aug 2003 - 21 Aug 2003 (9 posts) Archive Link: "RFC: evolution of file management"

Topics: Filesystems

People: Eric PouechMartin FuchsFerenc WagnerKeith MatthewsRobert NorthAlexandre JulliardMicrosoft

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:

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:

  1. gather all known shortcomings of current file implementation
  2. propose some solutions and roadmaps for the implementation

feel free to add your own remarks to these lists.

shortcomings

  1. 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...)
  2. mounting should be done session wide and not process wide, and of course shared across processes
  3. ntdll and kernel32 are not separated regarding file management
  4. devices (vxd and DOS) management is still a hack
  5. 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...)
  6. poor management of ejectable devices
  7. short/long file name conversion should be consistent (across several processes in the same session, across several sessions)

Note: (1) a session is linked to a running instance of the wineserver

proposal

  1. "path gates" (target: #1, #2, #3/partly, #4/partly, #6/partly) all file names will be handled using the NT-style:
    • DOS paths (C:\foo\bar) into \??\C:\foo\bar
    • network paths (\\station\foo\bar) into \??\UNC\station\foo\bar
    • DOS device names (CON) into \??\CON
    • NT device names (\\.\PhysicalDrive0) into \??\PhysicalDrive0
    • a VXD ?? (normally \\.\VFD) into \??\VFD


    the device concept will disappear and be replaced by a "path gate":
      in NT-Win32 name space, point where to convert from a NT-path to a Unix-path

      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
    the path-gate will hold the current options that the device currently does (case sensivity, fixed/removable...)

    path-gates will be stored in the server (they are session wide)

    management of VxD and devices could benefit from it: they could be path gates pointing to them selves (or nothing ?)
  2. FS (target: #4/partly, #5/partly, #6/partly)

    I'm still wondering if we really need a FS (even a very simplistic one) in Wine
  3. short/long file names (target #7)

    since current short file name management seems satisfactory, there's no need IMO to move short/long names conversion in the server

Martin Fuchs pointed out some of the lower-level structures used in NT to represent filesystem hierarchies:

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.

Eric seemed to have taken that into consideration and replied:

I do know how it's implemented in NT.

anyway, there are a few differences between ROS and Wine:

Regarding file support, the minimal things Wine need to do is:

I chose the second approach (you're more proposing the first one) because I felt it was more suited to wine behavior.

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

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.

Ferenc Wagner wanted to know about other details, " Do we need attributes like hidden, system, etc?"

Keith Matthews expanded on that:

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.

At the level we are dealing with here the essential problems (for those who have not examined the issues) are :-

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.

Since I've not yet got round to looking at TrustedBSD there's potentially another can of worms there.

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.

Eric disagreed:

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.

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:

(*) except files starting with a . which get the HIDDEN attribute

Robert North gave a pointer so some work being done at the kernel filesystem level:

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

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

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

3. Update On Last Weeks' Feature

20 Aug 2003 (1 post) Archive Link: "Update On Last Weeks' Feature"

Topics: Licensing

People: Brian VincentGerald Pfeifer

Gerald Pfeifer pointed out that last week's feature article on Wine's history had some mistakes concerning specifics of LGPL provisions. Specifically, I wrote the following:

That's not really correct. You don't have to make changes available in all instances. Here's what I should have written:

As always, please refer to the Free Software Foundation's website for specifics of their licenses.

4. Environment Variable Handling in Wine's Config

19 Aug 2003 (7 posts) Archive Link: "REGRESSION: environment variables no longer possible"

Topics: Configuration

People: Marcus MeissnerDmitry TimoshkovAlexandre Julliard

Marcus Meissner wondered why Alexandre committed a patch that changed the way environment varibles were handled:

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?

Dmitry Timoshkov pointed out how to make it work:

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.

Alexandre clarified why, " 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."

5. FreeBSD, OpenGL, and Pthreads

20 Aug 2003 - 21 Aug 2003 (4 posts) Archive Link: "Build broken due to -lpthread"

Topics: Ports, Build Process

People: Alexandre JulliardGerald Pfeifer

Gerald Pfeifer reported a problem compiling Wine under FreeBSD. It seemed to manifest itself when linking with the pthread library. Alexandre then asked, " So what's the right way to link with libpthread on FreeBSD?"

Gerald messed around and found a solution, " Wine builds fine if I just omit the -lpthread line above. "

Specifically, the line he meant was this: /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

He researched a little more and found a better solution:

If I simply remove -lpthread from

Wine, builds without problems.

Alexandre then made some changes in CVS that did just that.

6. Top 10 Reasons For Using Fox Under Wine

20 Aug 2003 (1 post) Archive Link: "Re: [Foxgui-users]Re: Wine fixes (1)"

Topics: Ports

People: FoxDimitrie PaunMicrosoft

Apparently there's yet another cross-platform GUI toolkit out there called FOX. From the FOX Toolkit website: " 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! "

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:

Top 10 reasons you want Fox ported to Wine:

and the number one reason is:

(what geek can resist this sort of virtualization? :))

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.