Wine Traffic #11 For 4�Oct�1999

Before the patches, the printer dialog was just empty (no printer). T-TARIF.EXE doesn't invoke the dialog on printing, so it just works fine with native printer or wine postscript printer.

Current Status Wine:

• 16-bit Windows printing support is (a little) broken, if it has worked ever (I don't know, I'm only a year with the project)
• Huw DM Davies has written a 16-bit-style Postscript printer driver, which has recently gained some attention from Corel.
• Klaas is working on the 32-bit Common Print Dialog, and has been writing some other functionality here-and-there to have this dialog function. Printing using 32-bit built-in winspool is currently still not possible, and will not be in the near future.

Current Status Microsoft & Partners:

• Over the years, Microsoft has revised the printer driver system many times, introducing the need for printer manufacturers to supply very different drivers for the different Windows versions:
  • Win 3.x
  • Win NT (any differences between NT 3.x and 4?)
  • Win 95
  • Win 98/2000 (As far as I can remember, M$ promised to have these two use the same driver system)
  • Win CE (???)
• The interfaces to these drivers can be split into three classes:
  • 16-bit
  • 32-bit (NT 4 / 95)
  • 32-bit Mk II (98/2000)
  but the latter two have a lot in common.
• The 32-bit systems are organized around 'mini-drivers', which are essentially generic renderers for Postscript, PCL 2 (old LaserJets), PCL 4 (DeskJets) and PCL 5 (LaserJets). (Maybe there also is an HPGL mini-driver) The different driver manufacturers need to supply a very detailed configuration file to this mini-driver which tells the renderer about the possibilities of the printer. Also, they can supply enhancements to the renderer and a GUI for setup & monitoring.
• There are other drivers from other manufacturers, e.g.
  • Adobe's own Postscript driver
  • Software 2000's Inkjet driver (at least used by Lexmark) and software packages which act as an printer:
  • Microsoft's HTML generator
  • Adobe's PDF generator
  • Envoy (back to the old WordPerfect-for-Windows-days)

Future Wine:

• To have Wine emulate all above OS'es their printing code, will be an enormous task, if possible at all... M$ hasn't tried to do it themselves! Therefore, we must make a choice for one (or two) of the following alternatives:
  • Native only: We concentrate on allowing Wine to interface to the different native windows DLLs - which will be difficult. Printer drivers which access a VXD (like e.g. my DeskJet 540) won't ever work. This solution does not produce a printing solution for both WineLib nor Linux-only installations. Currently Wine development moves towards this option: only 16-bit has been developed.
  • Postscript only: Wine only uses the Postscript driver to produce PS files, which are fed to e.g. Ghostscript for support to non-PS printers. This reduces the number of renderers to work on to only one, and gives us freedom to skip most of the underlying winspool code. This will result in a solution which works for most OS'es and printers in the shortest time. This solution will never allow for the above mentioned PDF/HTML/Envoy generators.
  • Wine-internal driver system: It is possible to develop our own PCL4 & 5 renderers (a great job for a student end project ?). This would also imply that writing our own HTML/XML/PDF generators is possible/necessary. There would have to be a generic printing layer in which plug-ins can be written. And the greatest trick would be to persuade all Windoze programs that there is a genuine printing system below the interface.
  • Composite: We could try to develop a combination of the first two. If we choose to implement the Win98/2000 version of printing, and modify the PS-driver to act like such, we can use the native DLLs as example and maybe have the plug-ins also. Note that drivers accessing VXD's still won't work, but most users should access their printers via LPR anyway. This also impacts the way Wine handles native DLLS, as it is not possible to use Win 95 DLLs for Win 2000 printing code. Native DLLs will only be of use for a limited number of people. Unfortunately, the Win98/2000 solutions is the most difficult one around :-(
• Still I suggest we move to the last option (composite), and have a serious look at keeping the 16-bit code happy...

This move will have a large impact on several parts of Wine, so I'd like to hear comments from all major developers, Alexandre and Gav!

I don't really care where you put what. If you absolutely want a separate dllglue program, OK I can live with that, even though I don't see the reason for two separate tools where one would work just as well.

What I insist on is that the development of this program, be it called build or dllglue, must be done in incremental steps; this means that every new feature and every structural change is submitted as a separate patch, reviewed, committed, tested and used by everybody before moving on to the next step. Trying to push a finished dllglue down my throat is not going to work.

And if you try to follow this incremental process, you'll find that it's more logical to put things into build, simply because making incremental patches against something that already exists is vastly easier than incrementally creating a new tool from scratch.

We've been looking into the idea of running the MSVC cross-debugging nub under WINE so that we can do binary debugging from the NT side. I've had some initial success (after getting over the utter shock that most of the underlying code needed to support running debuggers under WINE was already there - thanks Alexandre!), but I've come across something that I need some help with.

I was invited to give two talks in Denmark last weekend (by the FLUG and DKUUG, but the latter skimmed out), which I did.

The first talk was saturday at Odense in front of approx 50 people of the FLUG (www.flug.dk). I did hold a talk about WINE (mostly a general introduction with emphasis on technical status and how a normal user can help) and did a small demonstration afterwards. (WinWord, Internet Explorer (did not work as well), playing .avi files using a Linux program linked to WINELIB (aviplay) and the installer of the StarWars:The Phantom Menace Demo (which I got on the way to denmark at Pizzahut in Hamburg as special deal ;))

I could not demonstrate "Lucas Arts:The Curse Of Monkey Island" at this time, because the laptop did not have a supported soundcard ... Which lead to a "10 minutes" (== 1 hour) fix, where I made DirectSound work without soundcard ;)

Sunday I held the talk in Arhus at the Linux User Group there in front of approx 30 people. The talk and demos went a bit better than Saturday.

Thanks again to Jesper "jews" Pedersen for inviting me, him and his girlfriend for providing hospitality over the weekend, the people of the FLUG/ALUG and the sponsors ;)

1) The pointer to the virtual table, "lpvtbl" in wine, is "lpVtbl" in all DirectX header files. An annoyingly small change which needs a lot of wine code changed.

2) The macro constructs the function name as fn##functionName whereas MS DirectX header files construct them as just functionName.