Wine Traffic #75 For 25 Dec 2000
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:
- Several DIB bitblt optimizations.
- New configuration file format and location.
- Faster initial registry loading.
- Unicode edit control.
- Lots of bug fixes.
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:
- 13 posts in 53K by Jon <email@example.com>
- 9 posts in 32K by Alexandre Julliard <firstname.lastname@example.org>
- 6 posts in 44K by Patrik Stridvall <email@example.com>
- 6 posts in 19K by firstname.lastname@example.org
- 6 posts in 16K by Francois Gouget <email@example.com>
- Full Stats
19 Dec 2000
Archive Link: "Wine Certification Label"
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
Andi proposed to use the Wine glass from the WineHQ site:
/ / Yes, it runs on Wine
|__/ [optionally mention Wine version here]
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.
- "Best Served With Wine"
- "soberly runs on Wine"
"Runs on Wine
Consume without moderation"
- or with a general surgeon quote: "Warning: Prolonged use may
cause allergy to Windows."
19 Dec 2000 - 21 Dec 2000
Archive Link: "Diffing Windows and Wine (part2)"
Jonathonm Griffiths, Patrik Stridvall, , Francois Gouget, Patrik Stridval, Jon Griffiths
In some follow-up discussion on Windows' API coverage in Wine (see
BROKEN KCREF), Jon Griffiths
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:
Jon required a C-function parse in perl. Patrik Stridval pointed out:
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 :-)
I have (almost) [written one]. Just look in
wine/tools/winapi_check/winapi_parser.pm., and proposed to
adapt it to Jon's needs.
Patrik whips it out which let Jon announce:
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.
After Patrik's quick work on writing function_grep.pl, things get a lot more
Heres the current version of specmaker. It currently works in two basic modes:
- Generate a stub-only dll suitable for winebuild to link to, so that a
Winelib app can call functions from a native DLL.
- 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 :-)
Wine and fonts
20 Dec 2000 - 21 Dec 2000
Archive Link: "XFree 4.x Render extension"
Lionel Ulmer, Huw Davies,
Lionel Ulmer wrote:
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
Huw Davies replied:
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 :
Unlike the core protocol, Render provides no font support for
applications, rather it allows applications to upload glyphs for
display on the screen. This allows the client greater control over
text rendering and complete access to the available font information
while still providing hardware acceleration."
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 :-)
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
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
Sharon And Joy