Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #198 For 28 Nov 2003

By Brian Vincent

Table Of Contents


This is the 198th issue of the Wine Weekly News publication. Its main goal is to eat the giblets. 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

Mailing List Stats For This Week

We looked at 224 posts in 717K.

There were 56 different contributors. 28 posted more than once. 28 posted last week too.

The top posters of the week were:

1. News: SuSE Wine Rack

22 Nov 2003 - 28 Nov 2003 (1 post) Archive Link: "News"

Topics: News

People: Franks CornerMicrosoftIvan Leo Murray-SmithNews

It's been a while since I visited Frank's Corner and I was pleasantly surprised to see he's revamped the site. For a while there wasn't much available besides the user forums. It's a wonderful resource for the Wine community. I found this news article to be interesting:

Beginning December, customers of SUSE LINUX 9.0 Personal or Professional will be able to purchase an add on called SUSE LINUX Wine Rack. For $ 39.99 you will get WineX, CrossOver Office, CrossOver Plugin and the game Marble Blast.

SuSE's press release contains more details including a link to a product information page.

This is more of an interesting link than real news. Ivan Leo Murray-Smith posted a link to page describing Microsoft software that never saw the light of day. Longhorn debuts at the top of the list.

2. WineHQ Officially

25 Nov 2003 (3 posts) Archive Link: "Re: winehq name"

Topics: Project Management

People: Dimitrie PaunDimi Paun

A long, long time ago on a mailing list far, far away someone decided that Wine's official domain name would be (of course, wine.[com][org] was already taken). Over time, was also registered. This has led to a nice philosophical debate about the virtues of both. Rather than raise the issue on wine-devel and start another flamewar, Dimi Paun just submitted a patch to change the reference in the source files:

I know we've discussed this before, but I feel things have changed and it's worth another try :) Namely, have the name be the default one. It seems virtually everybody (except you) prefer the .org name over the .com name, it's way more community friendly, and it seems to be the default one on WineHQ for a while, without any negative side effects. As we are gearing up for the .9 release, I feel we should clean up this annoying bit. Quite frankly, I think that the .com suffix raises all sorts of nasty questions that are better avoided.

We wouldn't be the first project to have to related names for their site, and I see no potential danger in making the change, just an upside. Please consider it.


Alexandre committed it and remarked, " It's not that I prefer the .com name, frankly I couldn't care less, it's just that I think it's silly to change a perfectly good name that everybody was used to, simply to achieve some questionable ideal of "purity" of the domain name; and even more silly to have to change all references to try to reduce the confusion that would never have happened if we hadn't changed it in the first place. But I don't really care enough to keep fighting about it, so I put your patch in..."

Got that? If you reference WineHQ on your web site you should probably update it to be Of course the old .com is still registered and will continue to work.

3. Lecture Slides Available

27 Nov 2003 - 28 Nov 2003 (3 posts) Archive Link: "More slides - final draft?"

Topics: Documentation

People: Shachar Shemesh

Shachar Shemesh is giving a presentation on Wine and made his slides available:

This time, I actually installed a spell checker. Believe it or not. holds the PDF and the openoffice of the slides. I'm hoping this is the last draft. You know youv'e stayed up for too long when you start putting stuff into your sig.

A huge thanks for everyone for their input.

Shachar noted that the presentation is meant to be accompanied by a demonstration of real programs running under Wine.

4. Running PhotoShop Plugins in the GIMP With Wine

26 Nov 2003 - 28 Nov 2003 (12 posts) Archive Link: "Fun projects?"

Topics: Project Management

People: Rob CollinsDimitrie PaunMike HearnDimi PaunMarcus Meissner

I love people thinking a bit out of the box about how to exploit Wine to make Linux or [insert-favorite-OS-here] better. Over the years there's been tons of neat ideas that have faded into nothingness. I'm sure someone out there has contemplated the benefits of using Wine to somehow interface with a coffeemaker. Generally I don't cover these topics because they don't offer much in the way of details and seem to be just a bunch of fantastic dreaming. I expect the outcome of this thread to be no different, however it's definitely worth covering because of the level of detail provided and the potential for enhancement.

On the Fun Projects> page is an idea suggested by Marcus Meissner to investigate using native PhotoShop plugins with the GIMP. This week Rob Collins provided some details on interfacing with PhotoShop plugins:>

Photoshop plugins are DLLs, with all calls from the host using 1 entry point ( main ). But hopefully, we won't have to look at the P$ internals, because: The GIMP for Windows has partial support for P$ plugins; the plugin host being pspi.exe (source is available, but you need the SDK's header files to compile it). My thought is to look into altering pspi to work with the UNIX gimp

By "partial support", I mean it handles many PiPL filter plugins (.8BF). To my knowledge, it does not support pre-P$ v2.5 plugins (PiKI), nor does it support the Automation, Selection, or Color Picker modules that are sometimes a part of P$ plugins. Also some filter functionality is missing (likely missing the system and Adobe color pickers, for example). Otherwise it works great (at least partial success with Flaming Pear, Xeno's (compiled FilterMeister) filters, Luce, Stroik's Rubber, etc). Notable for not working is Nic's various filters (which work in a checkboard fashion, some regions with filter applied/applied only partially, some without).

Based on the date of the pspi source on his webpage, I'd bet he used either the 5.x SDK or the 6.0 SDK.

In pspi's README, he says:

[see that thread; GimpPlugInInfo is documented in /build-dir/devel-docs/libgimp/html/libgimp-gimp.html#GimpPlugInInfo, but it is not the solution Tor used for gimp-pspi-1.0.2, which is the latest I could find]

So, a (the) big question is, how can we get this windows app to compunicate with UNIX processes?

This unleashed a bunch of speculation. Dimi Paun wondered:

Well, indeed, this is the $10000 question. I don't much care at this point wether Gimp can work with the Plugins or not, what I care about is to export their interface in a an ELF library so that Unix processes can call them. This is non-trivial, so the first question is:

That's not really public knowledge and Rob wrote back:

Well! It would do this project no good if I were to break the agreement I made with Adobe in regards these SDKs (I have the AE and Premiere ones too). So, until I get a responce from Adobe or their maillist (I lost that agreement), I won't directly provide any details from the SDK itself. There's still plenty of information available online, though.

To answer your question, check out this link:

The PICA API document is still freely available, and is a pie-in-the-sky review of plugin programming (containing none of the headers, etc, that one needs to actually build a plugin, or investigate specifics). Section 2.3 describes the interface.

The actual prototype for the main entry point is not in this section (of course, it is in the API guide in the SDK), but it is a pretty good and basic read.

You'll also want to review the gimp-pspi (v1.0.2) source... it's available at Cinepaint's sourceforge downloads page, among other sites. The /pspi-source-root/src/pspi.c has the struct for the entry point.

We certainly won't get 100% compatability: some/maybe many P$ filters call other DLLs ... not just windows DLLs but their own ; possibly to extend their functionality, but likely as a part of copy protection.

But the idea of implementing the entirety of interaction between host and plugin first seems a bad way to go about this (don't you think?). I would suggest we build a minimal DLL that is interactive (returns ++integer), and work on the UNIX end and Wine-dows host application from there. Afterwards, we can come back and make the Adobe plugin host... this has some notable advantages:

Either way, is fine really ... I'll happily follow your lead. Just my 2 cents.

Mike Hearn suggested an approach that may be easier though a lot more clunkier, " It's tricky. The easiest way is simply to convert the Gimp into a Windows program by compiling it with WineLib. No, I don't know how to do that, Dimi is the expert here. That means that in order to use Photoshop plugins in the Gimp you'd need a special build of the Gimp and Wine installed and setup correctly. That might well be acceptable, I don't know."

Boaz Harrosh thought looking at how MPlayer developed their Windows' DLL interface might help. He suspected (correctly) that it used a stripped down version of Wine's loader mechanism. Rob took a look at it:

I'm looking at the loader section of MPlayer now ... (all docs plus the archive still barely give you any idea what it is they are doing) They have what is called mini-wine (in the list it was referred to as this, at least)

Since the documentation is so sparse, I was going to look around in other projects. Xine uses their win32 stuff, so I'll start looking there. In the meantime, any other projects you can think of that do this sort of thing? (ndiswrapper is a kernel module).

Just for some basic info ... MPlayer fakes responces to system API on a per-codec-DLL basis, which means, for each new DLL, they add the necessary callbacks. I think this could eventually wind them into trouble if the dlls they want to use grew in the wrong way. But, the advantage, they don't have to process a video stream through a full wine, which gives them speed enough to make the DLLs useful.

I don't know if speed will be such an issue for my purposes; I'm not outputting unencoded video ... hopefully this flexability (a full wine) lends enough compatability that I only need .specs for supporting DLLs for the plugins. Since their port includes the interface to the DLLs, it's still another resource to look at.

That brings up the second question I have ... I'm not a windows person. Is there some tool that can query a DLL, kinda like objdump?

Andi Mohr pointed him to tools/winedump or pedump to peer into the imports and exports of a DLL. All in all, this could be a really cool project that could bring a lot of attention to both Wine and the GIMP. It will be interesting to see if anyone takes up the challenge.

5. NetBIOS Functionality

26 Nov 2003 (2 posts) Archive Link: "Re: netapi32: implement Netbios()"

Topics: IO

People: Juan LangUwe Bonnes

On Wednesday, Juan Lang posted a nearly 4000 line patch with new NetBIOS functionality:

Apologies for the size of the patch, I didn't see any useful way to shrink it.

ChangeLog: implement rather a lot of Netbios()

I could say a bit more than that, but it wouldn't mean much to most people. Where there was nearly none, now there is some.

Thus far the patch is uncommitted. Uwe Bonnes asked for some more details:

Saying a little more may help.

What's needed to test you patch? What programs show improvement? Any configuration items needed in a .ini file or the registry?

Just some thoughts.

And thanks for your work :-)

Juan described the direction he's heading:

Good questions. I have little test programs that I've been using, but NetBIOS is hard to test without knowing something about your network configuration, so they're not much use for netapi32/tests.

I don't know of any programs that work now that didn't, except what I'm working on: I'm trying to implement the Network Neighborhood. I've been tweaking WINE's SMB code to use Netbios() rather than implementing the netbios-over-tcpip stuff directly. That work isn't done yet, watch this space for more :)

There was an article a while back linked here about some HP management program (for their NAS appliance) that didn't discover their box under WINE because of lack of NetBIOS support. I suspect this may now work, but I don't know.

Regarding configuration, he added, " should work as-is. You may configure some things in the registry if you need to. Many are configured in the same way as Win98's reg, but not all. I didn't know a good place to document these; comments in winedefault.reg???"

The article Juan referred to may be a mention in HP World concerning the management software for FIA's POPnetserver NAS 4600 model 720. The article did cite a workaround, but perhaps the issue needs to be revisited now?

6. Default Printer Question

27 Nov 2003 (3 posts) Archive Link: "Default printer and patch management"

Topics: Configuration

People: Mike HearnHuw Davies

Mike Hearn asked two separate questions in an email. For clarity's sake I'm splitting them into different sections. First, Mike ran into a problem when there was no default printer:

Currently the default printer is read from win.ini - setting this is annoying and doesn't work out of the box. I think it'd make more sense to have it also in the wine configuration, so if no win.ini string is retrieved it'll still work. I have an app here that dies if there is no default printer. Is it acceptable to make a fallback in the registry/config branch? The default would be "Wine Postscript Driver", though I guess we could be clever - enumerate the printers actually installed and pick the first. I don't know enough about printing to say. Huw?

Huw Davies replied with a description of the process Wine goes through to set up printers:

We should be doing this already. If cups is installed then we use the cups default, otherwise for printcap systems we use the PRINTER env variable or if that isn't set the first entry in /etc/printcap. Take a look at dlls/winspool/info.c

Mike didn't have any of that:

Well, at least in the copy I have WINSPOOL_EnumPrinters has this:

ie it's a no-op. Bear in mind I don't have any printers installed, the only driver available is the Wine PostScript driver so neither CUPs nor printcap is set up.

So keep that in mind - an app may need a dummy entry in /etc/printcap just to start up.

7. Closed Source Patch Management

27 Nov 2003 - 28 Nov 2003 (4 posts) Archive Link: "Default printer and patch management"

Topics: Licensing

People: Mike HearnAlexandre JulliardIvan Leo Murray-Smith

The second question dealt with some legal aspects of doing commercial development:

The reason I've been so quiet on the winecfg front lately (ignoring university) is because I'm working on porting an app commercially. As a part of that process, I'm generating patches and committing to a private branch. However, I'm not sure how best to manage patch submission. There are a few alternatives:

Does anybody have any experience of this? What is the best approach?

Ivan Leo Murray-Smith responded first and pointed out potential LGPL violations with options b) and c). Alexandre came out against b) too:

Don't do that. Patches that aren't released under a free license should be treated as if they didn't exist; we don't want to discourage people from working on something just because someone has a patch that may or may not be released at some indeterminate point in the future.

This may cause some duplication, but it's always better to have two implementations of something than to risk having none at all if it turns out that you can't release the patch in the end.

Also make sure that you get the customer's agreement before releasing anything; most likely if you are doing work for hire they own the copyright and you can't release it without their permission (of course once they distribute the result it has to be LGPL, but they don't necessarily want to distribute it).

As someone who's gotten screwed over handshake agreements in the past, I'd caution any who's doing commercial development on the side to get written notification concerning the work to be completed. In most communities you can find free legal advice and it's worth searching out. At the very least a simple document outlining the scope of work and payment terms should be drawn up. Besides covering your ass and making you sleep better at night it also looks more professional.

In Mike's case he probably has some small patches ancillary to the main work he's doing. It might be convenient to get them checked in immediately and deal with any large additions later. Diverging codebases can be a nightmare to manage and things can easily slip between the cracks.

8. Icon Cache Problems

26 Nov 2003 - 28 Nov 2003 (4 posts) Archive Link: "Mysterious icon-change"

Topics: Graphics

People: Jakob ErikssonMike HearnRolf KalbermatterIvan Leo Murray-Smith

Jakob Eriksson posted link to a mysterious icon change:

I am told this is what the Internet Explorer icon looks like after winetests.exe is run. Strange eh?

Mike Hearn took a stab at where the problem was occurring, " The Windows icon cache has always been one of the buggiest pieces of code. I always assumed they fixed it for NT/2000/XP but it wouldn't surprise me in the slightest if it still gets corrupted at times. "

Ivan Leo Murray-Smith reported a similar problem with various apps getting their icons rearranged. Rolf Kalbermatter provided more insight into the problem:

It does on my W2K SP4. At random the icon cache gets mixed up and suddenly a lot of icons don't match anymore. It is especially bad with Icon Overlays.

I use Tortoise CVS, a CVS shell extension, and their newest version has a special command built into their context menu to rebuild the icon cache. I do have some suspicions that Tortoise CVS may be responsible for some of the icon distortion but it happens regularly even when using normal MS applications.

9. Winearts With KDE 3.2 Beta

26 Nov 2003 - 27 Nov 2003 (2 posts) Archive Link: "winearts & KDE 3.2-beta1"

Topics: Multimedia, Integration

People: Kevin KoltzauK. VogelUnknown

Kevin Koltzau ran into a problem with winearts - the Wine sound driver that interfaces with KDE's aRTS framework:

I decided to give KDE 3.2-beta1 a try (just for reference I'm using the Gentoo ebuild), and found a problem with compiling winearts

under KDE 3.1 "artsc-config --cflags" gives me

but under KDE 3.2-beta1 I get

which causes a problem because this value is passed to makedep during compilation, which fails with "Unknown option '-pthread'"

K. Vogel posted a hack:

Quick and dirty patch:







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.