Kernel Traffic
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #12 For 11�Oct�1999

By Eric Pouech

Table Of Contents


This is the twelfth release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

Well, this week has been very calm here on wine-devel, perhaps the first bit(e)s of cold, forcing the bears to hibernate.

Mailing List Stats For This Week

We looked at 47 posts in 145K.

There were 22 different contributors. 10 posted more than once. 14 posted last week too.

The top posters of the week were:

1. Wine and printers

�Archive Link: "Wine and printers"

People: Huw Davies,�Richard Browne,�,�Klaas van Gend

After Klaas van Gend proposal's from last week, a lot of comments / enhancements have been provided by the Wine developers' community.

Jutta Wragge, Huw Davies updated the current status of printer support:

Huw Davies gave some more details on the status:

So what this means is that you can print from 16 and 32 bit apps using either the builtin ps driver or for example the win3.1 or win95 ps driver, given that you have the right things in the registry.

Native 16bit printer drivers (these include some of those shipped with win95 like the PostScript driver) should work to some extent. The ones that generate some kind of printer control language (PS, PCL, HPGL) will work a lot better than ones that simply send a bitmap to the printer, because of the complete lack of either the dm* Brute functions or a dibeng.dll. While I may carry on trying to get some of these more advanced drivers to be more functional I don't see this as a high priority. As other people have said let's leave this to ghostscript (and yes I have thought about getting gs to load native windows printer drivers, but this still doesn't help non-intel systems without an emulator).

Native winspool while probably never work. It tries to load vxds and to be honest is probably not worth the effort. This is the sort of level that we should probably rewrite anyway. The builtin winspool is probably at the stage where it's fairly useful for most simple printing situations, though there are improvements which I need to make.

The builtin version of PrintDlg16 is actually not too hard to fix, before I left I had a semi-working version that basically just called PrintDlgA. When my laptop arrives (my other linux box is in Oxford and it's too painful to edit anything over this link) I'll finish it off.

I'm fairly happy with the builtin ps driver as it is, I did start working on device setup property sheets and such but ran out of time before I got anything apart from paper size/orientation done. EPS generation is probably next (this should be easy enough).

As a summary, best bets to print are either to use a 16 bit native PCL driver - with PCL capable printers -, or to use the builtin PS driver and use GhostScript as the renderer / printer for the output.

So, the next important step is likely to be being able to add decent configuration for printers in the registry (Huw Davies provided a patch that should solve the broken PrintDlg16 issue).

Richard Browne disagreed also on Klaas' overview of printing in Windows and provided some corrections:

2. WRC enhancement

�Archive Link: "WRC enhancement"

People: ,�Bertho Stultiens,�Joshua Thielen

Joshua Thielen reported an issue with wrc (the Wine resource compiler) which doesn't allow two resources of different types to have the same name.

Bertho Stultiens agreed on the bug, and said he'll provide a new version of wrc, correcting this problem as well as user-type patch.

3. InstallShield bug-fix

�Archive Link: "InstallShield bug-fix"

People: Andreas Mohr,�,�Ulrich Weigand

Andreas Mohr reported an issue he had with some InstallShield programs. He provided an in-depth analysis of what's going wrong:

basically, a 32 bit program called setup.exe was trying to launch a 16 bit program, called setup.exe, but sitting in a different directory. The loader, when checking if the module of the second setup.exe has already been loaded, incorrectly believes the first setup.exe is the correct one, hence resulting the second setup.exe not to be ran as expected.

Ulrich Weigand confirmed Andi's analysis and explained how to fix the issue in the NE loader.

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.