Wine Traffic Brian Vincent

This is the 204th issue of the Wine Weekly News publication. Its main goal is to ponder. 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
News OSNew Xandros News Codeweavers

Barry Smith reviewed Xandros 2.0 Deluxe for OSNews.com. He briefly mentions the included CrossOver products integrated into the system:

Codeweavers worked as expected. It ran MS Office and Adobe Photoshop and Paint Shop Pro quite well. Codeweavers did have the potentially annoying habit of trying to automatically install any and all Windows disks that you stuck into either drive, but such is life and the feature can easily be disabled. I call Codeweavers a neutral aspect as far as my use goes. But for someone who really needs to run a few specialized Windows programs, and who cannot or will not setup a dual boot system, this is a good alternative.

Filesystems Architecture

Eric Pouech is doing extensive work on Wine's mechanism for working with files and filesystems. The scope of work is pretty extensive and delves into some core parts of Wine. After all, making a Windows application think the underlying Linux filesystems are native is a pretty daunting task. Eric has been working on this for quite a few months. The resulting changes will probably be some of the biggest we've seen in months. Eric made available some of his work and asked people to comment on it:

The current output is a large patch, available here:

It's not completly ready yet for inclusion, however some ongoing discussions could overlap with what I've currently done (like how to configure drive without a config file, SMB handling...). So better discuss it widely (yet another flame war).

The benefit of the patch:

  • all file creation, opening, directory browsing is now done in ntdll instead of kernel32
  • file IO management can be cleanly separated between kernel32 and ntdll (1)
  • files/ directory could be removed (not done in the patch (also nuked include/drive.h and include/file.h)
  • homogenous drive & device handling (we no longer store those objects in the server). Drive and device are now standard file handles (from a Windows point of view).
  • a few current Wine bugs have been fixed (see the todo_wine removed in the tests subdirs)
  • we no longer rely on the Wine config dir for the drive settings
  • partial NT volume management implementation
  • most of the volume related information (& ioctl) are done on the real unix device attached to the volume

What has been removed (from current implementation):

  • file system options (all FS are considered case insensitive)
  • per drive code page (all drives are now handled with the wine specfic UNIXCP code page)

What still need some improvement

  • fix all the introduced bugs (even if all the current tests actually pass)
  • setting a first default environment (even if tools/winefs provides it - see below)

Eric went on to describe in detail how filesystems would be defined and managed. The instructions are quite clear and actually seem to boil down to something really simple: apply patch, run the new winefs tool, report things that break.

Dimi looked at it and liked it:

I have to admit I haven't read the patch, but the idea looks good. I personally like the use of the filesystem for this sort of thing (I'm a one-value-per-file kinda guy, and I'd put a lot more into the filesystem, generally speaking, if I had my way :)).

Here are a few random thoughts on it:

  • it seems we're duplicating a bit stuff like udev/proc, but we can't rely on them, so I guess it's not a big deal. However, somehow we should keep in mind that udev will allow for hotplugging disks etc, and we should keep an open eye to integrate with that in the future.
  • I assume ${WINEPREFIX}/{dos,}device point somewhere in the user's home dir (~/...), right?
  • I hope Alexandre likes the idea, and we can get it in sooner, rather then later (before WineConf? :))

Cool stuff.

Juan Lang had a question about handling paths:

Eric, the sooner the better as far as I'm concerned.

In my quick read of the patch I didn't see any translating from the Win32 namespace to the NT namespace; do you plan to do anything there?

To pick a (bad) example, the name \\server\share\file is valid in the Win32 namespace, but not in the NT namespace; it must be translated to \??\UNC\server\share\file

Since you mentioned SMB, I will too: don't worry too much, it's currently broken anyway. As long as the code's cleaner it should be easier to fix (and this looks much cleaner).
RPC / COM / OLE Microsoft Ove Kåven Boaz Harrosh

Mike Hearn expressed concern that Microsoft may pull some software a lot of people use, I noticed that Win98 is about to be finally obsoleted. After this, it's possible Microsoft will do the same as they did with IE and other stuff for Win95 and pull downloads from their website. This is a problem, because we currently need the DCOM downloads in order for some apps to work - can somebody with legal knowledge check the EULA and see if we are allowed to redistribute this file?

Ivan Leo Murray-Smith glanced at it and reported, No legal knowledge needed, the EULA at http://www.microsoft.com/com/dcom/dcom98/eula.asp is very clear, and says that the user cannot distribute the dcom installer.

In early version of Windows 9x, DCOM was added as a separate download. So it's possible to download dcom95 and install it. Wine has gradually improved it's DCOM / OLE support over the past few years. It's now to the point where a lot of very useful code has been written but not merged. Mike and Ove Kåven have been the active workers lately, but things have been stalled for about 6 months. Mike has a hefty patch based on some work Ove did, but it needs to be cleaned up and submitted.

Discussion about what was missing from the builtin implementation. Ove brought up the first issue, Nobody has yet added typelib stuff to widl, eh... I guess I could whip up a framework or something to help with that, since nobody else has yet done it...

Mike Hearn outlined more items:

Actually, in the last 4 days I recruited somebody to hack on this from IRC. He seems pretty competent and is currently implementing the ICreateTypeLib[2] interfaces I think. Alexander (nyef), are you tracking wine-devel yet?

If you could work on the widl backend of course that'd be fantastic. I'm still hoping to get back to properly submitting your DCOM/apartments work soon, but I have 3 or 4 higher priority things on my todo list currently.

I think once those two things are done we'll be able to make do without native DCOM in like 95% of cases..... we'd still need it for code that uses NdrClientCall but I think that'd be the only major missing feature remaining.

Boaz Harrosh and Rob Shearman both mentioned they were interested in working on the typelib stuff. Rob may even have some code that could be used:

I thought about moving all of the typelib stuff to a library (because ITypeLib and ICreateTypeLib must be part of the same object), so that we could use it from widl as part of the build process.

I have a load of code that implements NdrClientCall2 (what's the difference between NdrClientCall and NdrClientCall2?). I am just starting work on NdrServerCall2/NdrStubCall2.

The next day Ove started on adding some new features to widl:

With this patch, widl can be made to parse a suitably adapted version of the stdole2.odl file previously sent to wine-patches (but it can't yet generate anything useful from it). Not unchanged, though, as widl is supposed to be more of a MIDL than a mktyplib (even though I can't seem to convince MIDL to generate stdole32.tlb). And there's a new typelib.c file to eventually fill in...

Log:
Added rules to parse library, coclass, dispinterface, and module definitions, and a number of attributes, and cleaned up a few things. Started on a typelib generation framework.

Ove also submitted some small patches he had laying around.

Architecture Eric Pouech

Alexandre came back from vacation last week and activity picked up quite a bit. He immediately did a bunch of commits to CVS then began debating some patches. Juan Lang's work (mentioned last week in issue #203) drew some heat and it started with a simple comment from Alexandre, You can't share C files across dlls, this violates dll separation and it won't build properly.

Juan wasn't sure where it should go, Is making a static SMB library preferrable? I haven't yet discovered the interface MS uses to SMB (public or private), so I haven't been able to hide it in the real place.

Alexandre thought it was best implemented elsewhere, As I said already, IMO the file I/O stuff should go in the kernel. The current approach is broken, as you noted in your FIXMEs.

Eric Pouech asked for a clarification of what kernel meant - the kernel32 DLL, kernel32/ntdll combination, etc. Alexandre cleared up the confusion, In this case I mean the Linux kernel, this stuff cannot be done efficiently in user space.

Juan wasn't sure what direction to take, File I/O, fine. But how about named pipes? Mailslots? They are implemented with nearly the same SMBs, and belong in kernel32 or ntdll. netapi32 needs 'em too, for these two functions.

Mike McCormack offered to help:

I'm happy to work with you (or even do most of the work) to put named pipes and mailslots into the kernel. We just need to figure out a way to reuse what's already in the kernel (smbfs) in a sensible way.

I was thinking of making a new socket family or something along those lines...

Dimi was worried that the timeline for getting this included in the kernel might be a while. Asking people to upgrade their kernel seemed a bit daunting. Alexandre didn't think it was too much to ask. He added that kernel support would probably even be required for local named pipes. Juan wondered why and Alexandre replied, Mike can probably give you more details, but there are some features that cannot be supported on standard socket pairs, for instance switching between byte and message modes on the fly, or some of the blocking conditions.

Juan felt that condition could be handled without kernel support, The named pipe state can be queried via the QNmPHandState SMB and changed via the SetNmPHandState SMB. See the X/Open IPC mechanisms for SMB, p114 and p116 ( http://www.opengroup.org/products/publications/catalog/c195.htm )

Alexandre still thought that it wouldn't be possible to do it in user space:

Setting the message type was an example of things that require kernel support in the local case. Obviously you cannot send SMB requests on a socketpair.

In the remote case, what we need is for the kernel to manage the whole protocol, so that we can do read() and write() calls as if it were a normal socket. You cannot manage the protocol in the client process, it breaks down as soon as two threads (or worse, processes) share the same pipe.

Juan responded, Again, why? The named pipe server has to support multiple accesses, so multiple processes can create unique connections to the same pipe, and let the server worry about concurrency. Even if that weren't the case, using a synchronization object and shared data in the wineserver would be able to control access. In the multithreaded case, you only need to implement concurrent control in the dll that implements named pipes (most appropriately ntdll). I had to synchronize NetBIOS receives across threads in netapi32.dll, and this doesn't seem any harder.

Alexandre thought putting it in the server would be a problem, You have to do inter-process synchronization, pipe handles can be shared between processes. I don't see how you can do that without putting everything into the wine server, which is the same as putting it into the kernel except with a large performance hit (and not only for named pipes, but for all file I/O, since it will prevent many optimizations). But feel free to prove me wrong; I haven't studied the protocol in detail so maybe I'm missing something.

Utilities

Last week I mentioned the winebrowser script written by Chris Morgan ( http://www.winehq.org/?issue=203#Launching%20Native%20Browsers). This week Chris gave an update, Alexandre wanted winebrowser implemented as a winelib application and also to be more easily configured. Here is the winebrowser winelib application. It uses a registry key(I'm not sure if this is the correct path for the key since I didn't see any other config keys in the registry) and creates a key with the defaults if no key exists.

The source to winebrowser can be found attached to his original email.

Project Management

Dimi announced the ability to make donations to Wine through the Sourceforge download page:

After intense setup work from Alexandre and myself (about 3 clicks per person :P), we've managed to enable donations through our SourceForge page:

Direct donation link:

Now, to test the new facility, we need as many users as possible make all sorts of donations to the project...;)

Graphics

CodeWeaver's Aric Stewart put together some work he's done to better support tablets:

Sorry all, This is way way way _way_ overdue. But it is really the first time i have had a chance to really take some time and review the changes Alexandre gave me, retest everything and put together a patch against the tip.

I did some quick testing and it appears that this will work.

I have broken it into 2 patches

wine_wintab.diff is all the wintab work except for the x11drv stuff wine_x11_wintab.diff is the changes to x11drv. the reason for this is because i still have the ime patch that i submitted earlier in my wine tree so i had to had edit that x11 patch to try to make it not dependent on the xim stuff being already applied. This make there a chance that there are bits that may not apply cleanly, and if you are committing both of my patches (xim and this) then they wont apply cleanly without a bit of fudging.

I am also giving you 2 test applications i used for wintab testing. SYSPRESS.EXE and TILTTEST.EXE These applications helped alot on testing things. They where found on the wacom developers site, i think i still have the source kicking around somewhere.

Changelog: Enables Tablet support with both Tilt and Pressure

The test applications can be found attached to his email.

WineConf 2004 Mike Hearn Alexandre Julliard Francois Gouget Lionel Ulmer Tom Wickline Marcus Meissner

WineConf 2004 is coming up in just a few weeks. Jeremy White is the organizing force behind the conference. He posted two emails this week and updated the WineConf information page. Jeremy proposed the following agenda:

At this point, the plan is to have a very open schedule with a lot of time for informal discussions. Furthermore, we will keep a white board of discussion topics and make time and room for those ad hoc discussion topics. With that said, we will have a formal schedule as follows:

Saturday, 8:30-9:30 am Pastries and coffee, meeting time
Saturday, 9:30-10:15 am Opening keynote - Alexandre Julliard
Saturday, 10:45-12:00 am Wine 1.0 Discussion, led by Dimitrie O. Paun
Saturday, 12:00 am-1:00 pm Lunch (hot hoagies + pizza)
Saturday, 1:00 pm-2:00 pm Making it work: discussion on techniques for getting an app to run, led by Tom Wickline
Saturday, 2:30 pm-3:30 pm (two sessions)
Discussion on internationalization, led by Shachar, AND
So you want to be a Wine hacker?, led by Mike Hearn
Saturday, 4:00 pm - 5:00 pm Explore the Ice Palace at the St. Paul Winter Carnival
Saturday, 6:00 pm - 8:00 pm Dinner, Wine, and recreation at the Mall of America
Saturday, 9:00 pm - ??? Libations, working hack groups back at HQ
 
Sunday, 8:30 am - 9:30 am Donuts and coffee
Sunday, 9:30 am - 10:15 am Porting it: discussion of Winelib, led by Francois Gouget and Dimitrie O. Paun
Sunday, 10:15 am - 12:00 am This space intentionally left blank
Sunday, 1:00 pm - 2:00 pm OLE, led by Marcus Meissner
Sunday, 2:30 pm - ??? Hacking games, playing games, led by Lionel Ulmer

Jeremy arranged for a group rate at a Best Western for $58 /night. For those on a stricter budget he found a youth hostel for $25 /night.

Jeremy also wondered about remote participation. The last WineConf had a streaming video feed which was great for folks who couldn't attend. However, it wasn't interactive at all. Jeremy wondered if it would be worth pursuing something similar:

One thing I would like to do is to stream audio from the conference out to the web and also work very hard to include folks from #winehq (or maybe #wineconf) in some of the sessions.

The sessions I thought made particular sense were the ones around Wine 1.0 as well as on OLE and Games.

Does anyone recall being remote to the last Wineconf? Did it work at all? Is there anything we could/should do to enable others to join us, if only virtually? (Please feel free to tell me that it didn't work worth beans and we should just drop it, btw < g >).