Somewhat disappointing experiences with Winelib and WTL

[Robert Shearman]

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

http://www.winehq.org/site/docs/winedev-guide/dbg-others

>    - 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
>better).
>
>
>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
>background ...
>  
>

http://wiki.winehq.org/Winelib_binaries_as_ELF_executables_not_%2eexe%2eso

>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.

-- 
Rob Shearman