World Wine News

WHAT'S NEW with Wine-20030115: (see ChangeLog for details)

• Much better header files compatibility in Winelib.
• A ton of Direct3D work.
• Many improvements in sound support.
• New wineboot tool to simulate a Windows reboot.
• Lots of bug fixes.

• All efforts now focused on CVS head tree
• Technology Progress - Vertex Shaders, Direct3D, and more
• Additional Development - Joystick improvements and DirectPlay
• Games Updates
• Voting Report

ShaoLin Microsystems Limited, an award winning provider of distributed computing solutions and CodeWeavers, a leading Windows-to-Linux software developer, today announced a strategic alliance partnership. CodeWeavers and ShaoLin joined forces to give a boost to the acceptance of the Linux desktop, particularly in enterprise environments whereby CrossOver and ShaoLin are combining to enhance the capabilities of bridging windows applications to Linux on the desktop deployment and management in enterprise computing environments.

ShaoLin Aptus is the world's best Linux workstation deployment and management solution for enterprises which desired low cost desktop computing system with high availability. It is a middle-ware that makes the most reliable, manageable, secure and open platform alternative to high cost and heavy administration traditional PC's. CodeWeavers' CrossOver allows you to run your favorite windows productivity applications in a ShaoLin environment under Linux, without needing Microsoft OS licenses for each client machine.

I've been too busy lately (job hunting mostly, although I've also been sick and bedridden lately) to do any more work on it, and I was really waiting for Alexandre to comment on my question about C++ before going any further... I haven't seen a reply yet tho.

The current state of my local tree, besides being a mess, is that it has most QT dependencies removed. Currently it uses a lot of QT stub's around WinAPI functions that I wish to remove before doing much more work with it.

It is currently quite MS html compatible, and my CHM viewer seems to have few problems rendering HtmlHelp pages using the KHTML/KJS functionality. Unlike Gecko, which is too 'standards compliant'... eg, it deliberatly doesn't implement any of the IE specific functionality.

The other issue I need to look into is where each part of IE functionality need to go. Implementing IWebBrowser is easy enough from my current work, however that is only the very top of the iceburg. The more important issue is to get all the various parts in the right dlls (shdocvw, shdoclc, jscript, ecetra). Many programs that embed IE use and/or subclass a large number of functions - mostly undocumented - from these dlls, as opposed to using IWebBrowser itself. There is also the problem of res:// inclusion of HTML templates embedded in shdocvw, ecetra.

This is, btw, another reason that gecko isn't very well suited. It would require a lot more work to butcher gecko (simply because of it's size and complexity) into these stub dlls, than it would to do so to KHTML/KJS. Either way, it's a lot of work that unfortunately I don't have all that much time to do at the moment.

Hopefully my job hunting will calm down soon, and I will have time to clean up the code to a state where I can at least post it for other people to work on... then again, if it calms down it means I've FOUND a job... so it could work both ways :)

Ender, you may be right that we might have to integrate something into the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year down the road? KHTML is very much a work in progress, who's gonna track it? We don't have any richedit control, heck even our bog standard edit box is not finished! And for how many years now?!? Just for curiosity's sake, can you give us a wc -l of the KHTML stuff?

If we do have to integrate something, I think we *have* to have a way to track the KHTML development. Just throwing something in the tree may actually be detrimental, if it remains unmaintained. To be able to track the KHTML development, we need to keep track of the revisions we worked off of, and we have to avoid touching their sources. To this end, I think we are much better off by implementing a QT subset:

• It should be a lot stabler than the KHTML stuff. It seems to me QT hasn't change that much from the 1.0 days, now it should be close to a libc in terms of interface stability.
• I haven't looked, but I assume KHTML can't use that many difficult to implement QT features
• Having a free QT/Windows implementation is generally useful to a lot of people, so we're likely to get more people to help

If our changes to the KHTML source are minor, I am certain the KDE people will help us by integrating them upstream. If in time we can work off of the same code base, we can simply delete our copy from the Wine tree.

There might be another way. Now that Safari is out and it's deQTfied, and having more and more people interested in KHTML, the KDE folk may decide to officially switch to a QT-free KHTML version, in which case we'll be saved the trouble of implementing a WQT (pronounced wicked :)).

As it seem there is some effort going on to create a native Win32 KHTML port using Apple's WebCore wrapper system I think I will take a break on my current code and play with that a little. Personally I didn't want to have to take on the chore myself, but this whole Safari thing IS creating more interest in non-X11/QT platforms... it definitely changes the playing field, and with the large speed and compatibility merges from Safari lately my current tree is hopelessly out of date anyway :)

So I think I will play with that and work on the DLL layout and COM interfaces until something eventuates... I've decided it's worth waiting to see what direction KHTML takes (portability wise) now that it is being use in a 'real' non-KDE application. There's no point rushing into a WINE-specific implementation if something more closely tied to the upstream code is released meer weeks later.

Of course there still a small problem of having to separate the code into MS compatible COM objects and DLLs... I will have to benchmark the speed impact of stubbing the MS dlls into khtml.dll/kjs.dll ecetra, instead of replicating the exports more natively.

There is actually two different HTML renderers that's used in GNOME gtkhtml and gtkhtml2

GtkHTML was originally a port of a very old version of KHTML to Gtk+. gtkhtml2 was written from scratch.

GtkHTML is used by evolution for both showing html (in html messages) and for editing, in the composer. I think there exist a browser somewhere which use this widget. But as far as i can say i don't think it renders web pages very good.

gtkhtml2 on the other hand is the library used by yelp, the GNOME 2 Help system which support css quite well. But no editing and is more or less unmaintained. At one point in the future it will be abandoned and GNOME will use GtkHTML in the help browser instead.

Some of the reasons are related to C++ itself: lack of standard ABI, large differences between compilers making it harder to write portable code. Other reasons would apply to any language: more complex build process, more external tool dependencies, harder to debug, developers need to be familiar with both languages, harder to copy code around, etc.

None of these are showstoppers, but it needs a *really* good reason to overcome all of them. So far I haven't heard anything convincing enough.

This is the initial version of wineboot, the next generation. It is a rewrite, using the old code as reference only.

• At this stage only wininit.ini processing has been written. Lots more work to do.
• _stricmp is not defined, and is called directly instead of as stricmp.
• As a result of the above, there is a compilation warning when compiling.

• Cleaned up the code (saving on chaining strings) by CDing to the system root directory before doing anything else.
• Will now rename wininit.ini to wininit.bak instead of erasing it as before.

• Implemented the "pending rename" registry processing.

• Added listing of what the boot process is like, listing what is and what is not (yet) done.
• Fixed incorrect statement in the "bugs" list.
• Added trace when everything is done.

• Added a "runCmd" function, which is a cleaned up version of Andy's "BOOT_CreateProcess" function.
• Added a function "ProcessRunKeys", to process all the keys that have the common "Run" syntax.
• Called the new function from main for all the various keys.

This app handles the various "hooks" windows allows for applications to perform as part of the bootstrap process. These are roughly devided into three types. Knowledge base articles that explain this are 137367, 179365, 232487 and 232509. Also, 119941 has some info on grpconv.exe The operations performed are (by order of execution):

Preboot (prior to fully loading the Windows kernel):

• wininit.exe (rename operations left in wininit.ini - Win 9x only)
• PendingRenameOperations (rename operations left in the registry - Win NT+ only)

Startup (before the user logs in)

• Services (NT, ?semi-synchronous?, not implemented yet)
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce (9x, asynch)
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices (9x, asynch)

After log in

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce (all, synch)
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run (all, asynch)
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run (all, asynch)
• Startup folders (all, ?asynch?, no imp)
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce (all, asynch)

Somewhere in there is processing the RunOnceEx entries (also no imp)

I updated the D3D status page ( http://www.bbrox.org/d3d_status.html ) with some new screenshots and some new demos. Nothing revolutionnary though :-)

Thanks to Christian for the 3D Mark 2000 paragraph.

I'm about to start serious implementation on the wintab32 dll. I now need some guidance as to how best to implement it's access to X11 calls.

My current thoughts on how to do this are given below. Are they reasonable??

I need to access a number of X11 calls, largely in the XInput extension. None of these are exposed by the x11drv dll.

My intention is currently to change nothing in the x11drv dll.

The only hints I can find about how to do this are from the direct draw and open gl dlls.

These dlls can do the following:

• Get the X11 Display object of a gdi context.
• Get the X11 window handle given a win32 window handle.
• Synchronise with the x11_drv code for multi threading.

My wintab code will do the same.

The one difference will be that wintab will create it's own X11 Display objects. It will interrogate a gdi's X11 Display object to ensure it talks to the same screen.

The wintab code will also require multiple message queues. To implement this I intend to use one display object per queue. (Much as wine uses one display object per thread)

That's what I thought, and I have proof of concept patch that hack the x11drv code to insert & read XInput events from wine's X11 event loop.

Unfortunately this doesn't fit well with the way wintab works. So, here's an explanation, why I've made these decisions. It's far longer than I'd wish, but the issues involved in the design are complex.

So here goes......

Quick recap of what wintab does The wintab dll will takes messages from a graphics tablet, and provides them to the user. But isn't that what a mouse does? A mouse provides information on the X & Y screen coords, and buttons pressed. A tablet provides all the above, plus extra axes defining the tilt of a pen, the pen's pressure, rotation of a mouse, (and possibly more). All this can be provided at resoloutions much higher than screen resoloution.

The XInput side of the implementation

The official way to get tablet data for an X display is to use the XInput extension.

The XInput extension defines a specialised set of event classes to represent tablet data, which enter the normal X11 message queue. These messages are initially disabled. XInput provides a function to enable them for a given display and window.

OK, So far it looks as if the XInput messages could be injected into the wintab messaging system. But note that this would reqire some patching to the x11drv dll to do the following

1. decode the messages.
2. enable the messages for a given window and display.

The wintab side of the implementation

To access tablet, a "tablet context" is created that maps a window to a particular tablet device.

For each tablet context the application is given a separate tablet message queue, which provides 2 ways to access the tablet message queue.

1. A set of functions that get or peek, or otherwise interrogate the message queue for queue size, message at index etc.
2. Posting messages into the windows(wine) message queue.

At present, I will only implement method a. as this is the one used by Painter5 and Photoshop6.

Now, as it turns out, the methods to interrogate a wintab message queue are extremely similar to those to interrogate an X11 message queue. So that's +1 to giving wintab it's own X11 message queue. (Or possibly even one X11 msg queue per tablet context!). A simple X11<->wintab mapping can be implemented, and no additional queue data structs are needed in the wintab implementation. As the wintab dll implements it's own message queue, an implementation using the wine message queue would give a number of problems:

1. All wintab messages would have to be hidden from the application's windows(wine) message queue. Could be done with one specific thread, or threads for wintab. This becomes similar, but more complicated to the X11 message queue implementation.
2. Filtering methods would have to be implemented to only access the messages appropriate to the reqired tablet context. X11 provides all the filtering necessary. While windows provides enough filtering for ranges of messages. But this would mean 3 message mappings X11->windows(wine)->wintab.
3. All the queue management functions, and any necessary data structs to manage the queue will have to be implemented specifically in wintab, as the windows queue doesn't give much control over the message queue, and what's more, may need to copy data into a wintab specific message queue before the application can access it.

I think after all that complexity, that's +4 or more to X11 message queue implementation, and for wintab at least, avoid the wine message queue.

Well, that's the end of my whistle stop tour of the issues I've been cosidering with this part of the design. I've omitted any reference to function names, to keep this document as breif and readable as possible. If you wish, I can annotate it with the relevant function names.

Please feel free to comment on anything.

And finally, Some references:

For the wintab spec see the following location:

http://www.pointing.com/FTP.HTM

For XInput see

ftp://ftp.x.org/pub/R6.4/xc/doc/hardcopy/Xi/lib.PS.gz
(Much of the doccumentation will probably be bundled with your xfree86 implementation too)

I agree you probably don't want to store wintab events in the Windows message queue. But that doesn't mean you have to create your own X connection and event loop, you can simply retrieve the events from the normal X event loop and store them into the wintab queue.

[That] is initially how I was going to implement it.

The issue I came up against is how to inject the messages into the wintab queue?

In wine, messages are currently injected into the for each thread, when GetMessage() is called.

As wintab has it's own equivalent of GetMessage (named WTPacketsGet) the which seems to have direct access to the driver, it would look like wintab needs an alternative method to inject messages into it's queue.

The only one I could come up with, in wine style, was to have a worker thread whose sole purpose is to inject messages into the wintab message queue. It might call GetMessage(), but all this would do is cause the wine message loop to insert a message into the wintab loop.

The problem with this system is that it means that the queue has to be accessed by multiple threads, and therefore will lead to the usual thread synchronisation hassles.

It was the fact that I could avoid synchronisation which lead me to think about building my own message loop.

Some program (VirtualDub) checks the fsname returned by GetVolumeInformation, to find the name of the file system, when it needs to write files that are larger than 2GB. It refuses to create the file when we return FAT but will successfully write the file when NTSF is returned.

Change Log: add configuration option to report NTFS as the file system type for a drive.

Hmm, I'm not sure whether we should increase the preexisting Filesystem type mess by doing that. I've hated the "win95", "vfat" etc. syntax almost from the beginning (well, to be fair, I think I'm not too innocent when it comes to its implementation, but at some time I just came to the conclusion that it sucked)

After all we're running on *Unix* file systems in many cases, so "win95" does have no place here at all ! (neither does "vfat") Not to mention that "win95" awfully collides with the "win95" winver...

And adding yet another "incorrect" "ntfs" setting makes my head want to go bonkey ;-)

So I guess that it might be a good idea to think about how to solve this configuration issue in a nicer way (and of course keep the old config capabilities for about 2 years in order to have backward compatibility).

We might even want to think of introducing "nameless" filesystem type settings (instead of having "broken" conflicting and "wrong" FS type names). And of course it seems as if we also need a separate FS *name* setting in order to have Wine return "NTFS" instead of "FAT" in your case...

So could we start a discussion about that perhaps ?

So we The way I see it Windows knows about the following file systems. CDFS, FAT, FAT23, NTFS and HPFS.

• HPFS is irrelevent.
• CDFS covers all CD like Media.
• FAT will deal with all drives less that 2 GB.
• NTFS can be used with drive over 10MB.
• FAT32 can be ignored.