Wine Traffic #11 For 4�Oct�1999
Table Of Contents
This is the eleventh 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).
There's been lots of network issue in Danemark this week, leading up
to an almost inaccessible www.winehq.com site. As of today, the
situation doesn't look any better.
Mailing List Stats For This Week
We looked at 76 posts in 235K.
There were 31 different contributors.
18 posted more than once.
18 posted last week too.
The top posters of the week were:
- 11 posts in 29K by Ulrich Weigand <firstname.lastname@example.org>
- 9 posts in 25K by Eric Pouech <Eric.Pouech@wanadoo.fr>
- 5 posts in 15K by 'Peter Hunnisett' <email@example.com>
- 5 posts in 11K by Alexandre Julliard <firstname.lastname@example.org>
- 4 posts in 9K by Marcus Meissner <email@example.com>
- Full Stats
�Archive Link: "PrintDlg errors"
Jutta Wrage,�Klaas van Gend,�,�Huw Davies
Jutta Wrage reported a crash with a 16 bit dialog printer. She added
that it was working correctly before Wine 990723, and provided a list
made of culprit patches:
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.
Huw Davies and Klaas van Gend both admitted that current
implementation of PrintDlg16 was rather broken, but none of them would
put this item high on their priority list (starting with PrintDlg32).
Jutta also reported that she had no good solution to install a new
printer under Wine because the control panel was needed for this
operation (this program doesn't currently run well). Klaas proposed to
add a new project for supporting the control panel. Any volunteer ?
Klaas also wrote a documentation/status/print note and requested
Current Status Wine:
It's very likely some discussion will come out from this
proposal. Don't miss next week's WWN !
Current Status Microsoft & Partners:
- 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.
- 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:
but the latter two have a lot in common.
- 32-bit (NT 4 / 95)
- 32-bit Mk II (98/2000)
- 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,
- 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)
- 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
Therefore, we must make a choice for one (or two) of the following
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
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.
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
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
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.
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!
DllGlue: a comeback ?
�Archive Link: "DllGlue: a comeback ?"
Ulrich Czekalla,�Alexandre Julliard,�,�Ulrich Weigand,�Bertho Stultiens
After a few weeks of calm regarding DllGlue (for more on this, look at
those Elfdlls are coming and
ElfDLLs (cont'd)), Ulrich Czekalla
tried to help moving ElfDll inside wine CVS tree. After a warm
acknowledgement of Bertho Stultiens' work, he proposed the following
Bertho and Ulrich Weigand reiterated their previous vision of the
process, and, as before, didn't come up to any agreement (Bertho wants
all the .spec handling being moved outside of the 'build' tool into a
new tool, and not having intermediate development being not, and
Ulrich proposing a composite approach - i.e. put several DLLs into a
single ElfDll module, because the DLLs couldn't be easily splited).
Alexandre Julliard gave his view on the subject:
- Use lex/yacc for the .spec parser
- Switch to PE header generation instead of DLL descriptors and
modify the built-in loader accordingly
- Add resource generation
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.
�Archive Link: "Module loading"
Eric Pouech reported a bug in builtin modules loading: the current
code wouldn't let msacm.drv and msacm.dll be considered as two
different modules, but could let one be loaded when the other was
After some discussion with Ulrich, it turned out that the a solution
was to use the filename (and no longer the module name) as the key
while trying to load builtin modules.
Some fixes were needed throughout the code. Most important part is
that from now on, all builtin modules (16 and 32 it) with a non .dll
extension (e.g: .drv, .exe) must have a 'file' directive in their
.spec file, and be loaded by filename and no longer by module name.
�Archive Link: "Cross-debugging"
Gavriel State,�Alexandre Julliard,�,�Ulrich Weigand
Gavriel State came up with an interesting idea:
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.
Gavriel pointed out to a deadlock in process creation. Alexandre
Julliard and Ulrich Weigand acknowledged the problem. This deadlock
appears because the various events generated upon process start-up
(the one linked to the process creation and the ones linked to DLL
loading for this process) were not sent in the correct order. A proper
solution is known, but Alexandre proposed a quick hack to let Gav' to
further (but that could make native USER no longer work).
Later on, Gav' pointed out that (Get|Set)ThreadContext were not
implemented under Wine. Gav' proposed a possible solution. Alexandre
accepted it, with some restriction regarding its complete adequacy
to the current semantic of the API, and gave some direction on a
better long term solution.
As a conclusion, this cross-debugging effort seem on good tracks. We
should have some good news in the following weeks.
Marcus in Denmark
�Archive Link: "Marcus in Denmark"
Marcus Meissner gave some report on his recent (Wine oriented) trip to
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 ;)
�Archive Link: "COM headers"
Peter Hunnisett,�,�Francois Gouget
Peter Hunnisett, while trying to port existing Windows code thanks
WineLib, reported the following problems:
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.
Francois Gouget said that normally behaved COM application should not
address directly the fields of COM objects (which is implementation
dependent), but rather use the ad hoc macros. Anyway, the first point
is rather easy to solve, whereas the second can generate name-space
collision (Francois found examples were it did).
Peter also reported some issues with type-casts not being applied, but
without strong feeling whether this should be done by the caller of the
macro or inside the macro itself.
Francois provided several patches to help porting applications, even
if the 0-source modification rule is not reached yet (especially with
badly written apps).
Sharon And Joy