Wine Traffic #11 For 4�Oct�1999

By Eric Pouech

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 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:

1. PrintDlg errors

�Archive Link: "PrintDlg errors"

People: 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 comments:

Current Status Wine:

Current Status Microsoft & Partners:

Future Wine:

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!

It's very likely some discussion will come out from this proposal. Don't miss next week's WWN !

2. DllGlue: a comeback ?

�Archive Link: "DllGlue: a comeback ?"

People: 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 (wn19990822_5.html#0) and ElfDLLs (cont'd) (wn19990905_7.html#0) ), Ulrich Czekalla tried to help moving ElfDll inside wine CVS tree. After a warm acknowledgement of Bertho Stultiens' work, he proposed the following stepped approach:
  1. Use lex/yacc for the .spec parser
  2. Switch to PE header generation instead of DLL descriptors and modify the built-in loader accordingly
  3. Add resource generation

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:
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.

3. Module loading

�Archive Link: "Module loading"

People: ,�Eric Pouech

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 requested.

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.

4. Cross-debugging

�Archive Link: "Cross-debugging"

People: 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.

5. Marcus in Denmark

�Archive Link: "Marcus in Denmark"

People: Marcus Meissner,�

Marcus Meissner gave some report on his recent (Wine oriented) trip to Denmark:
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 ( 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 ;)

6. COM headers

�Archive Link: "COM headers"

People: 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

    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.