This is the 154th release of the Wine's kernel cousin publication. It's main goal is to give you something to do on a Friday morning, preferably while drinking a cup of coffee. It also serves to inform you of what's going on around Wine (the Un*x windows emulator).
Zack Brown's Kernel Traffic web site has changed - it's now www.kerneltraffic.org. If you're reading the kernel cousin variant of this, you may want to update your links.
Maybe I should take this opportunity to explain a little about differences between the Wine Weekly News and Kernel Cousin Wine. For the most part, the content is the exact same. It's all XML based, but each uses a different parser. You may notice a difference in the publication times - I complete most of the issues on Thursday nights and mail them to Zack Brown (Kernel Traffic) and Jeremy Newman (WineHQ maintainer). Both are excellent at posting the latest issue, though for some strange reason they sometimes decide to go on vacation. So if don't see an issue appear on one site you may end up finding it on the other. If you haven't read the other version of this, try it out. Each one has it's own set of features.
Oh, and next week's issue will be finished on Saturday.
CodeWeavers released version 1.2.0 of their CrossOver Plugin product. This latest version has support for Active X controls embedded in web pages as well as improved support for Windows Media Player and Trillian. Another key feature is support for the newest Linux distributions. For $24.95 it can be yours immediately.
IT Week has a review of SuSE's Linux Office Office Desktop. In case you haven't heard, this product contains CodeWeaver's CrossOver Office 1.3.1 Their recommendation was for people "who only use Microsoft Word and Excel" which I found rather strange. Their conclusion:
Suse's Linux Office Desktop makes migration to Linux easier, but inexperienced users may still need more support than is necessary for Windows. We found no major problems with hardware support, but users with unusual configurations may have configuration difficulties.
Easy installation; runs common Windows applications.
Windows users may need some retraining.
Mathew McBride wondered about whether a kernel module would help
speed up Wine,
If we implemented a kernel module (keep in mind, it would have to be enabled
in the kernel and wine config file so it doesn't make wine directly attached
to Linux, e.g so people can port it easier to other Unixes), would that help
speed up some DirectX games? (as Linux display drivers don't implement
In reply, I referenced a post from December:
If you dig in the WWN archives you'll find mentions of it going back a few years. Much more interesting was this post:
The approach is a shared memory wineserver.
The kernel module idea has been covered before,
most recently in December
Dan Kegel thought the kernel module was the way to go, but Gavriel State gave some more detail about the shared memory approach:
Each approach has its own merits - you'll note in our paper that we also posted sources and design documentation for KWine, an alternative wineserver kernel module design that keeps Win32 HANDLE objects in a Linux file system. We spent some time on that as well before working on the ShmServer approach.
With a kernel module approach, hosting multiple wineserver environments becomes more difficult. A kernel module also brings with it a number of packaging issues, and would require significant work to be moved to non-Linux OSes. Lastly, the kernel module approach requires an all-at-once rewrite of the wineserver interactions, whereas the ShmServer can be implemented on a call-by-call basis. About the only thing a kernel module would have over the ShmServer on the performance front would be the ability to do PE relocation fixups at page-in time, like Windows does. The value of that feature is limited, IMHO. A kernel module may also have some benefits from the security perspective.
Regardless of which one is better, it would be nice to see more interest in this topic from other developers. If anyone else is interested in collaborating on the ShmServer or kernel module approaches, that would be great.
Dan felt the feel the contraints of a kernel module weren't that bad and might offer some advantages:
We don't need multiple wineserver environments, really, except in the same way that we need multiple linux environments (e.g. with chroot jails).
There might be some way of bringing in the kernel module incrementally. You'd know better than me, but still...
I suspect the kernel module would be better protected from wild memory accesses by the user processes as well.
Francois Gouget and Shachar Shemesh then debated what effects moving parts into a kernel module would have. Francois summarized what crashes based on where the bug is:
Current Kernel Shm Bug in a Wine library Process Process Wine Bug in a Windows application Process Process Wine Bug in the server Wine Machine Wine
He also added,
So you're better of with the kernel module if the bug is in the
application, and you're better of with shm if the bug is in the server.
Then it's a matter of which one is more likely. It's also a good
argument for having the option to keep using the current server so that
you can make the trade-off between speed and stability yourself.
Gav didn't think the table was completely accurate:
The ShmServer is designed with that in mind. The server code has been moved into a shared library, and the wineserver process still exists in the ShmServer model. While it's not actually available in the current code, it would be trivial to restrict access to the shm area to specific trusted processes and force other processes to go through the normal wineserver route.
Additionally, the ShmServer is designed so that the actual shared memory area can be write-locked until a server call is made. Thus it becomes very difficult, though not completely impossible, for an individual process to scribble over the server memory by accident. So the bottom right entry in your table should perhaps be changed to read '99% Process / 1% Wine'
What it does *not* prevent is a deliberately malicious app scribbling over server memory - certainly a problem, but for many uses of Wine, not a significant one.
Another key factor in favour of the ShmServer is that we've got a working prototype available right now that runs several real-world apps. 8-)
InstallShield 6, while better, continues to plaque Wine. This week Dan Kegel asked for some help:
So, how's that Installshield 6 support coming along? :-)
The company I work for uses Installshield to package up its windows stuff. Today I tried running its installer under cvs Wine, and shortly after it started running IKernel.exe, it dropped me into the wine debugger.
Bobby Bingham suggested trying the following,
InstallShield 6 can work if you copy stdole32.tlb from a real
windows to wine's system directory. maybe stdole.tlb and stdole2.tlb
too, but i don't know if they're needed or not, i just copy them just
Dan reported success, but with several caveats:
Yep, copying just that one file made things get a lot further! After futzing around for half an hour, I finally convinced our app to install. There appear to be a lot of rough edges here; I had to turn on ole logging and run just the extracted setup.exe (not the package-for-the-web wrapper) to get things to work, and even then, I had to move the big background window around, etc. Also, if things failed for any reason, I had to kill leftover wine processes, or the next run would fail. Still, this is progress!
That led Mike Hearn to ask,
Would this be fixed by the work that's being done on Wines RPC
Why exactly does an installer require such complex parts of OLE anyway?
That seems like overkill for a self-extracting exe to me.
Sylvain Petreolle wanted to know what was so special about stdole2.tlb and if there's any work being done to implement it. Marcus Meissner explained:
The TLB is a typelib file, which is compiled from a .IDL file.
So widl needs to generate it at one point.
Greg Turner, who's done extensive work lately with RPC code, mentioned:
Well, it's not hard to imagine why an installer might need some interprocess communicaiton. And since RPC is available for basically every MS OS out there, and even non-MS platforms, it's easy to see how they came to the decision to use it.
Then Ove Kåven, the other RPC guru, gave a detailed explanation:
I think the idea of using advanced COM stuff makes sense from the InstallShield point of view - all that COM/DCOM/RPC stuff is already on every Windows installation, so the installer executable does become smaller by using it instead of writing their own mechanisms to achieve the same thing.
The program you launch simply does the "Preparing InstallShield Wizard" thing, this is where interprocess COM call takes place. Once you get past that and start the actual installer, the main engine (ikernel) only uses threads (though unfortunately, interthread COM calls aren't quite implemented yet, so repainting suffers). However, that engine does export OLE Automation-compatible COM interfaces, probably so that app-specific installation routines can be written in any language, including Visual Basic, Java, C++, etc (not just iscript), and still be able to easily call the ikernel API. This sometimes calls for IPC, but again, this is all handled by the stuff that's already there in every Windows installation, so there's no reason for InstallShield to bloat itself with its own reimplementation of these mechanisms - other than "it causes headaches for those Wine guys", but that probably wouldn't be their primary concern...
Dan Kegel wanted to know,
What happened to fnt2bdf?.
It's still available, it's just no longer installed by default, as
part of the effort to clean up the namespace of things we install in
/usr/bin. Anyway these days you are much better off using client-side
fonts than trying to manually convert Windows fonts to X format.
Dan thought it was still useful:
Does that mean Wine can natively handle .fnt fonts (which X libraries can't natively, I believe) as client side X fonts? I suppose Wine would need some user-space app to manage these fonts, then?
Fonts are a total pain to support right. I think Red Hat 8.1 might be the first version of Red Hat to get it right... I can hope, anyway...
Alexandre answered both questions:
My understanding is that FreeType can support bitmap fonts, but that it's not implemented in Wine yet; Huw can give you the details. Anyway most of the need for fnt2bdf was to convert the Windows standard fonts, and these are basically all TrueType now.
I guess we could have a font control panel at some point, but there isn't that much to manage anyway. As long as the font files are somewhere on the font path everything should just work.
Huw Davies jumped in with a status update on some of the font work he's been doing:
Wine doesn't handle fnts quite yet. However I've just added the necessary functions to FreeType to enable Wine to get hold of all the information it needs and hopefully I'll get time to finish the Wine side of things soon.
The fonts we're missing out on are System, FixedSys, Terminal, Courier, Small Fonts, MS Sans Serif and MS Serif (note there's also a Microsoft Sans Serif, but that's TrueType and should work already).
There are also 3 'stroke' fonts called Modern, Roman and Script; FreeType doesn't support this format yet, but they're as ugly as hell so probably won't be missed.
We'll need to add support for using libfontconfig soon - that'll mean we don't have to set up a font path manually.
Dan was excited,
Yes! libfontconfig support in Wine will be wonderful,
it'll mean that any fonts the user adds in the "control panel"
in Linux will automatically be available in Wine,
and possibly vice-versa (!).
Dan Kegel, in his quest to make Microsoft's Visual C++ v4 work, put together some info on it and and asked about adding a new tool:
I collected my notes about getting msvc4's setup running under Wine at
I now have wordpad reading .wri files properly under Wine (needed for the "STL" button). The next problem is that the setup program does ShellExecute(..., "explorer.exe", ".", ...) to pop up an explorer window.
Well, wine has Winefile, but not explorer.exe. It looks like the path of least resistance is for me to write a trivial little explorer.exe that just cd's to argv and fires up winefile (which always operates on the current directory). I've written it, and I expect when I add the needed registry entry, it'll make msvc4's setup's "explore this cd" button work fine.
Anyone think that'd be a bad thing to put into the Wine tree?
Juergen Schmied replied:
I attached a small explorer like programm onto [ Bug #1227 ] maybe we could port it into c code and include it into wine. It might be a good starting point to start a full featured explorer like programm. (And it's a good test for built in shell32)
Sylvain Petreolle wasn't sure if that was the best
I think that Dan has a shorter and better solution.
After all its easier to fix the existing code and write a wrapper than
coding a new program.
Dan hacked up an example of his idea:
OK, then. Here's a patch that makes 'start explorer.exe d:\' work (needed by msvc4.0's setup program).
Note that winefile had not in the past been installed in the fake windows area. This patch causes it to be installed there, and indeed under the name 'winfile.exe'. Hope that's ok.
I'm tempted to wait until somebody else agrees that this works before posting it to wine-patches...
Greg Turner wanted to automate some work but was having a problem:
I am trying write scripts to mangle the output of MIDL. After MIDL runs, I need to do a tiny amount of post-processing using UNIX apps (convert from CRLF, for starters).
So, I have batch file that I run under wine to invoke MIDL and get the output I want; My question is: is there some way I can invoke my unix shell script from my .bat file in wine under wcmd?
If not, perhaps we should squeeze this functionality into Dan's start.exe implementation? How would you feel about this, Dan?
Alternatively, if I could invoke my .bat file from the UNIX command-line, this would be just as good... but so far, the only way I have found is to run "wcmd" and type. Does wcmd have some equivalent to bash's "-c" command-line argument? Surely real cmd.exe has some such feature?
Dave Pickles replied that the first idea wouldn't work, but the second one would:
wcmd relies on the implementation of CreateProcess to invoke a program, and as I'm sure we discussed here recently that doesn't handle unix binaries.
The "/c/index.html" syntax is supported, to execute one command then exit, but not "-c". wcmd was written to emulate the functionality of DOS 6, though some later features have since been added.
Lawson Whitney gave an example:
wcmd /c batfile
you may put it in a shell script, if you like. output is to stdout (no window is created).
I've never covered this forum before, but I happen to be bored tonight. Here's a question from comp.emulators.ms-windows.wine:
Is there a way to extract program icons from Windows executables? Wine obviously has the functionality somewhere: wineshelllink uses it to add menu entries with icons.
But often setup routines fail to interact with wine/wineshelllink so that a program is installed but no menu entry created.
So is there a way to access the "extract icons" functionality manually?
Windows program Irfanview can extract icons. It works with wine and is free.
Shachar Shemesh got Internet Explorer 5.5 to install. It seems like only a few months ago people were wondering how to get it to run at all, let alone install from scratch. Shachar's recipe:
I managed to install IE5.5 using the following procedure:
- Download the IE5.5 base install from MS
- Set .wine/config as suggested a few days ago (ver=nt40, setupapi=builtin, *=native,builtin)
- Using the latest Wine (20030115), run the setup tool
- I, personally, made two sessions. One downloading everything, and the other for installing.
- Install just the basic IE. No Connection wizard or anything else.
- When setup finshes (and you get an error in processing the reboot) - wait for all wine instances to exit
- run wineboot.
- One of the programs initiated by wineboot fails to run (starts winedbg), just shut it down.
- That's it - IE works, sortof.
I'm hoping this proves useful to everyone.
This came on the heels of a few other recent IE posts. A few weeks ago someone posted about installation problems. About the same time Frank's Corner published a short guide to installing IE using a cab extraction program.
Dan Kegel wondered about how solid Wine's memory management was:
Say, how much address space protection is there in Wine? If a Wine process follows a wild pointer or passes garbage arguments to a Windows function call, are Wineserver and the other wine processes protected?
Imagine a user running Word, and also some less reliable windows program. When that other program crashes, it shouldn't take Word with it.
One way to check that kind of protection is with programs like 'crashme': http://people.delphiforums.com/gjc/crashme.html
Has anyone tried running crashme on wine yet?
Alexandre's response was that it had already been taken into account,
Yes, everything is protected. The only exception is when using some of
the native Win9x dlls that have shared data sections, in that case a
wild pointer can crash other processes. But otherwise it shouldn't
happen; and the wineserver should never crash no matter what the app
CVS has been in the news this week with security problems
that have prompted several distributions to
release updates of the package. Sylvain Petreolle forwarded
an email from Robert Penz wondering if Wine's CVS was
vulnerability. Jeremy Newman replied,
Thanks! The version of cvs on WineHQ.com is patched for this issue.
Mike Hearn asked about an old Wine mailing list,
On the Wine release notice it talks about a mailing list for large diffs
between the releases, which would be useful for me (no cvs access at the
moment at work), but the list appears to be dead, with no archives
available. Is it still in use?
Alexandre wasn't sure about a wine-releases archive, but
mentioned it was still around,
It's in use, I'm not sure why the archives are empty. But note that
the diffs I send there are the same than what you can get on sunsite,
so archives wouldn't be all that useful anyway.
Jeremy Newman found the problem with the mail archives and
I took a look into this and found the problem. We use hypermail for our
archives, there wasn't a config file for that list. I created one just
now. So hopefully, the next post to that list will get the archives
going. I don't know if that will bring back the old posts to the list
though. I'll dig through the hypermail docs some more to see if there is
anything else I need to do.
For those interested, you can find the archives at: http://www.winehq.com/hypermail/wine-releases/.