Somewhat disappointing experiences with Winelib and WTL
rob at codeweavers.com
Mon Feb 6 11:49:24 CST 2006
Claus Fischer wrote:
>Since I'm not familiar with the Wine debugger, it
>would have been very helpful to be able to use
>gdb on the resulting executable.
>However, gdb reported that it didn't know
>the file format.
>==> Wishlist to Wine:
> - Make gdb work on Winelib programs
> - Document Winelib and the build process better
> (the documentation is outdated, though the
> tools are good).
>All in all a reasonably successful endeavour,
>and the application runs stable and looks fine
>except for the font (that probably can be configured
>BUT: ... BIG SHOCK: That's not a single ELF executable,
>it's a weird mixture of PE and ELF and a .so file and
>a wrapper program that apparently starts wine in the
>That doesn't fulfill my goals of building a native
>Linux exe with no dependencies except libc.
Maybe your goals are wrong.
>It's also quite slow when loading.
Have you tried using oprofile? Is it the Wine code that is slow or the
libc dynamic loader?
>4. What is needed
>What would be needed to support static linking against
>Winelib (if that's decided to be a supportworthy goal):
>- Infrastructure to build static libs
> - separate out DllMain
> - separate out some 16 bit functions
The isn't going to work for any application which needs COM or that
needs multimedia, due to their dependence on using DLLs as function tables.
>- Possibility to provide heap based allocation
> through straight malloc()
What does this give you?
>- Infrastructure for proper initialization of modules
> e.g. through one setup function for each DLL
> and one common setup function that calls the others
> in some natural order
> The overall initialization function should be
> configurable so that programs that need only
> a few DLL's (user, gdi, crtdll, kernel, ntdll)
> don't need to link everything
>- Infrastructure to allow faking registry calls
> for those calls initiated by Winelib internal
> stuff (and possibly also ATL/WTL internal stuff)
>- Infrastructure to handle Window class registration
> etc. (i.e. reduced Wine server support in the app)
You really don't want to try without wineserver support. Nearly
everything depends on at least one feature that the wineserver provides.
If you try to make your own version of wineserver that is somehow
statically linked into the application you will have to completely
change how it works and maintain that version on your own.
You're doing a noble thing in trying to get your Winelib application
easy to deploy, but I think you're going about it the wrong way.
For maintainability, take a look at using the WINEPREFIX environment
variable and use dynamic libraries. That way you can deploy upgrades of
your application in a small installer, whilst not needing to update the
Wine libraries. If you need a bug fix in a Wine library, then you can
just update the one dynamic library that has changed.
If the startup speed isn't good enough for you, you can use oprofile (or
some other profiling framework) to work out which functions are taking
up time. We would welcome any fixes to improve the startup speed.
Optionally, you could comment out functions do things that you don't need.
More information about the wine-devel