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/winapi_parser.pm.

, and proposed to
adapt it to Jon's needs.

Patrik whips it out which let Jon announce:

After Patrik's quick work on writing function_grep.pl, things get a lot more
interesting :-)

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.

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.

Now that XFree 4.0.2 is out, the new Render extension (more details here :
http://www.xfree86.org/~keithp/render/ (http://www.xfree86.org/~keithp/render/)
) 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 :-)

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.