World Wine News

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.

The current output is a large patch, available here:

http://perso.wanadoo.fr/pouech-eric/ep-file.diff.gz (400 KB uncompressed)

It's not completely 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)
• homogeneous 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 needs 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)

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 than later (before WineConf? :))

Cool stuff.

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

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.

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.

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.

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

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.

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

http://sourceforge.net/projects/wine/

Direct donation link:

http://sourceforge.net/donate/index.php?group_id=6241

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

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 won't 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 a lot 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

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:

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