Wine Traffic #75 For 25 Dec 2000

"Wine certification" effort, i.e. a sticker on their product that says something like "yes, it runs on Wine".

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 ;-)

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.

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:

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

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

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.