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

Wine Traffic #75 For 25 Dec 2000

By Eric Pouech

Table Of Contents


This is the 75th 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).

Wine 20001222 has been released. Main changes include:

Mailing List Stats For This Week

We looked at 89 posts in 353K.

There were 35 different contributors. 14 posted more than once. 17 posted last week too.

The top posters of the week were:

1. Guaranteed vintage

19 Dec 2000 (5 posts) Archive Link: "Wine Certification Label"

People: Andreas Mohr

Andreas Mohr reported that some people were looking for a
"Wine certification" effort, i.e. a sticker on their product that says something like "yes, it runs on Wine".

Andi proposed to use the Wine glass from the WineHQ site:

Other slogans floated around:

There haven't been an agreement yet on the final quote (if you have some other proposals, feel free to send them), but lots of people found the idea appealing.

2. SpecMaker

19 Dec 2000 - 21 Dec 2000 (23 posts) Archive Link: "Diffing Windows and Wine (part2)"

People: Jonathonm GriffithsPatrik StridvallFrancois GougetPatrik StridvalJon Griffiths

In some follow-up discussion on Windows' API coverage in Wine (see BROKEN KCREF), Jon Griffiths announced:
I have written a stub dll generator which will read a win dll, and generate a compilable [dll].spec [dll]_main.c and [dll].h from it. I was hoping to eventually add include directory parsing to allow generating the c stubs as well, but haven't gotten around to that yet ;-)

Francois Gouget got a quick look at it and regretted that Jon's tool didn't support API exported by ordinal only. But, Francois felt it wouldn't be too difficult to add.

Jon thought it would be a bit more trickier:
What I'd really like to be able to do is scan a directory to get the prototypes for functions out of headers. Once you have those you can automatically write the prtotypes, the implementation, parse and dump the arguments in a TRACE, and return a dummy value (of the correct type) if needed. That would be cool.

Also you could LoadLibrary the real dll and have each function call through, dumping its return value as well as the inputs. A nice, unobtrusive way to see what a dll does, allowing you to re-implement the functions one at a time, while your program keeps working (well, I can dream).

Only problem is, I suck at perl, and writing it in c would be a chore :-)

Jon required a C-function parse in perl. Patrik Stridval pointed out:
I have (almost) [written one]. Just look in wine/tools/winapi_check/
, and proposed to adapt it to Jon's needs.

Patrik whips it out which let Jon announce:
After Patrik's quick work on writing, things get a lot more interesting :-)

Heres the current version of specmaker. It currently works in two basic modes:
  1. Generate a stub-only dll suitable for winebuild to link to, so that a Winelib app can call functions from a native DLL.
  2. Generate a compilable dll code base with code for function stubs, Tracing arguments and correct return values (compiles 'out of the box'). This is for re-implementing a dll for Wine or a Winelib app.

I am be adding the final mode now, which is to TRACE arguments, then call the native DLL through GetProcAddress and return the results. This is like building a 'snooping' wrapper around the native DLL so the functions can be implemented piecemeal, even if multiple functions depend on DLL internal states to work.

For mode 2, specmaker takes an argument specifying a file or list of files to search for prototypes (the fewer files to search, the faster, by an order of magnitude). Using Patrik's script, any matched exports from the DLL are converted into prototypes and stub code is generated. Before you can compile the generated code, you'll either need to #include the dll headers you used to generate the dll, or add the definitions of any DLL specific types used to <outputname>_dll.h. If your DLL uses standard types you won't have to do anything, except maybe add some windows includes. Generated code should build with -Wall,-W without any warnings.

As an example, running ./specmaker -d imagehlp -t -I ~/develop/wine-new/include/imagehlp.h

Generates a compilable imagehlp with every function but one implemented (because it has no prototype). I deleted dlls/imagehelp/* and copied the generated files in. Then I added "#include imagehlp.h" to imagehlp_dll.h (to get the definitions of imagehlp types), and could build it with a top level ./configure, make. Total time, about 5 minutes :-)

Jon knew of some existing bugs, but asked for feedback on the current design (and implementation flaws).

SpecMaker (0.2) has been added to the Wine CVS tree under the tools/specmaker directory. The README file gives all the insight of using it (and also using existing DLLs in any WineLib program). Have fun using it.

3. Wine and fonts

20 Dec 2000 - 21 Dec 2000 (3 posts) Archive Link: "XFree 4.x Render extension"

People: Lionel UlmerHuw Davies

Lionel Ulmer wrote:
Now that XFree 4.0.2 is out, the new Render extension (more details here : will be available on many (most ?) Linux desktops.

What could be interesting for Wine is resumed in the X release note :

This could solve many problems Wine has for font displaying. I know this argument (ie client-side font rendering) was already discussed at length (and rejected due to the 'remote displaying' argument). But now that the possibility of client-side glyphs is in the X protocol itself, we could have the argu^H^H^H^Hdiscussion again :-)

The font support in Wine is a long standing issue. Even is some X11 font servers support True Type fonts, Wine needs the correct information on the loaded fonts (glyphs...), and also needs the ability to add on the fly new fonts to the server.

Corel had implemented this using a proprietary extension to X Font server they use in their CorelWine. Wine hadn't started a final implementation of this, waiting for a sufficient support from the X11 site.

Huw Davies replied:
Indeed, I've been looking into this. I don't think we ever rejected client-side rendering, it was just noted that there will be a slight hit for remote displays ['slight' because the server will cache the rendered glyph so it's not that bad]. In fact we were probably going to go down the client-side rendering route anyway, XRender now just makes it rather easier.

In the next few weeks I'll try to get a Wine internal font-engine api evolved, once we have that we can get a XRender module into the x11drv.

So, don't hold your breath on it, but it seems that Wine is likely to have a fully working True Type support in the coming months (if you're using XFree >= 4.0.2). However, the question remains for non XFree powered desktops.







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.