All the news that fits, we print.
This is the 153rd release of the Wine's kernel cousin publication. Its main goal is to give you something to do other than work or study. It also serves to inform you of what's going on around Wine (the Un*x Windows emulator).
This week, 299 posts consumed 915 K. There were 80 different contributors. 48 (60%) posted more than once. 38 (47%) posted last week too. The top 5 posters of the week were:
|
News: Wine-20030115; TransGaming Update; CodeWeavers Partnership | 11 Jan 2003 00:00:00 -0800 | Archive |
---|---|---|
News
Alexandre caught up to more patches that came in while he was on vacation and released Wine-20030115. The following changes were noted: WHAT'S NEW with Wine-20030115: (see ChangeLog for details)
TransGaming posted an update to say what they've been up to. The highlights from that:
They had a little more news splashed on their front page too. If you're headed off to a Linux conference in the near future, be sure to where your TransGaming t-shirt. Gav and Vikas will be handing out gift certificates if they see you in one. WineX 3.0 is on the way, stay tuned to TransGaming's web site for more info. CodeWeavers announced a strategic partnership with Shaolin Microsystems. From the press release: 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. CodeWeavers gets an early nomination for the Most Cryptic Press Release award. As near as I can tell, CodeWeavers is going to supply software to an amorphous middleware company I've never heard of to do unspecified things that possibly involves Windows connectivity. Oh, here's my favorite sentence, [ShaoLin] makes the most reliable, manageable, secure and open platform alternative to high cost and heavy administration traditional PC's. A visit to ShaoLin's tells a little more. What appears to be going on is a way to distribute Windows apps to Linux workstations. The Aptus line of products concentrates the management of applications to the server side. Basically it acts very similar to the Linux Terminal Server Project software except it doesn't require a boot ROM and is more of a client side approach to the same problem. |
IWebBrowser Status / More Ideas | 10 Jan 2003 00:00:00 -0800 | Archive |
---|---|---|
Status Updates
Integration
The IWebBrowser interface continues to plague developers. I most recently covered it back in December, <kcref></kcref> and previous to that I gave a pretty good explanation of the issue back in late October <kcref></kcref>. Back in October I wrote, IWebBrowser is a set of interfaces Microsoft defined for Internet Explorer that allow you to embed it within another program. It provides methods navigation, hyperlinking, etc. Increasingly it's being used to add help pages to applications or web functionality. Just to recap the story so far, it's come down to two ideas for creating the IWebBrowser processing engine. The first is to use Mozilla, the second is to use KHTML. Mozilla has pretty much been ruled out - it's way too big and maintaining the code within Wine's CVS would be next to impossible. KHTML has the advantage of being a lot smaller and easier to integrate. According to the developers it would also handle the eccentricities of IE better. KHTML's problem is historically it's been tied to Qt. In addition, both of them suffer from being written in C++ (see the next thread for info on that.) There was more discussion this week about the details. Ender jumped in and discussed some of the work he's been doing: 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 :) Dimi Paun raised a valid point with maintaining any code integrated into Wine: 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:
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 :)). Ender thought taking a break from it right now might be the best thing to do. Perhaps things will change with KHTML for the better: 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. Mike Hearn then threw out a completely different idea for implementing IWebBrowser, GTK-HTML doesn't get the same amount of press that KHTML does, but it's written in C and is actually a fairly capable embedded html renderer. It relies upon GTK/GDK which already has a port to Windows, the GNOME help system uses it for rendering afaik so it should be easier to integrate with Wine. Finally it supports editing, which might come in useful in future. Johan Dahlin gave a little more detailed explanation of GNOME's renderers: 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. Ender quickly shot down the idea, GTK-HTML is far too basic for our needs. We need at least DHTML and JS support for any IWebBrowser/IE replacement to be useful. So it appears the way things stand, no work is going to be done in the immediate future. Hopefully the Qt bits of KHTML will be separated out and the remaining parts will be ported to Windows. If that happens, then Wine won't need to replicate the KHTML code. I'll be a little lazy and include references here rather than hyperlinked above:
|
No C++ in Wine | 08 Jan 2003 00:00:00 -0800 | Archive |
---|---|---|
Integration
Project Management
Recently a couple people have asked for the reasoning behind the policy of not having C++ code in Wine's CVS. The main reason is because of the IWebBrowser stuff discussed above. The best fit for implementing is with existing projects based on C++. Alexandre's response is best found in a different thread than the one referenced in the archive link above. The rationale: 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. Several people pointed out that the ABI is standardizing and gcc 3.2 (and to a greater degree gcc 3.3) supports a standard that Intel and SGI (et al) are trying to conform to. Alexandre didn't completely rule it out though, I'd prefer to avoid C++, but if there's no other choice then of course we'll have to do it. Anyone got a fully functional web browser library (written in C) in their back pocket? |
Wineboot Progress | 06 Jan 2003 00:00:00 -0800 | Archive |
---|---|---|
Status Updates
Configuration
Utilities
There's been work done lately on creating a new Wine tool named "wineboot". This tool handles setting up the configuration of Wine when it's started. It also will eventually handle things like parsing the registry for the RunOnce keys and other things needed by installation programs. Shachar Shemesh started out adapting some code from Andi Mohr and is now in the process of doing a completely new implementation. This is pretty big deal - when all of the configuration is moved into the registry it will allow graphical Winelib configuration tools to be written (in fact, some of that work is reportedly underway). Below are some of changes Shachar has noted in patches: Jan 1, 2003: This is the initial version of wineboot, the next generation. It is a rewrite, using the old code as reference only.
Jan 6, 2003:
Jan 10, 2003:
Jan 14, 2003:
Jan 14, 2003:
In the one patch referenced above, Shachar added the following notes about the Windows boot process and exactly what wineboot does: 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):
Startup (before the user logs in)
After log in
Somewhere in there is processing the RunOnceEx entries (also no imp) The "no imp" reference in the last line means "not implemented". Alexandre has committed all of the patches submitted so far. |
D3D Status Page | 13 Jan 2003 00:00:00 -0800 | Archive |
---|---|---|
Status Updates
Lionel Ulmer posted an updated status page on his Direct3D work: 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. The purpose of the page isn't really to inform you of how well a game works (that's the purpose of the App DB ). It's more or less to let you know what programs the D3D guys are doing testing with and the specific problems they're running into. The links give you a way to download the demos in case you wanted to hack on Wine. |
Accessing X11 Calls | 13 Jan 2003 00:00:00 -0800 | Archive |
---|---|---|
IO
Robert North wanted to know how to go about creating a DLL that needs to hook in to the current X11 display code: 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:
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) Alexandre didn't like the part about using different message queues and asked for more detail concerning wintab. Robert replied with a lengthy email on exactly what he's doing: 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
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.
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:
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: For XInput see
(Much of the doccumentation will probably be bundled with your xfree86 implementation too) Alexandre looked at the specs and suggested something slightly different and a little less complex: 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. Robert wasn't sure that was the correct approach: [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. Robert also wanted everyone's thoughts on the separation of wintab - what parts needed to go into x11drv and what parts needed to go into wintab.dll. X11drv doesn't have many exposed interfaces, so Robert thought he was going to run into problems with that. The easy solution would be to just dump a lot of the new code into x11drv. He looked at how the DirectDraw code worked but Lionel Ulmer cautioned him not to use that as a guide. Ever. |
NTFS Filesystem Type | 13 Jan 2003 00:00:00 -0800 | Archive |
---|---|---|
Filesystems
Tony Lambregts submitted a patch that added a new filesystem type: 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. Mike Hearn thought it might just be a good idea to always return NTFS if asked. Andreas Mohr disagreed and felt the whole concept was flawed: 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 ? From there the discussion delved into exactly what type of filesystems Windows knows about. There was some speculation on exactly how and when they differ. For example, what type of filesystem is reported on DVD's? Tony summed it up: So we The way I see it Windows knows about the following file systems. CDFS, FAT, FAT23, NTFS and HPFS.
|
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License,
version 2.0.