Matthew J. Francis reported a crash in GetCommandLine for a C++ program he tried to make working using winelib. After some investigations by Ulrich Weigand, it turned out that this program has global objects whose constructors call into Windows APIs. While completly correct under Windows, this doesn't work under Wine.

The initialisation sequence of a Winelib program is:

1. Outer entry point
2. main() which calls all the winelib initialisation code
3. main calls WinMain() which contains all the program code.

The C++ global objects' constructors get called between step 1 and 2, and winelib isn't initialized, hence the error.

Matthew and Eric Pouech tried different methods to solve this issue, (like using a C++ global object to initialize winelib, or use GCC extensions like __attribute__((constructor)) functions) but none of them seemed conclusive. Matthew ended up rewriting part of the program to no longer have global objects, but instead pointers to those objects which would be allocated while in WinMain.

This solution is, at least for now, the only known one. However, Bertho Stultiens proposed a GCC very specific hack (tweaking with GCC init sections) he had made when he worked on the import mechanism for DLLs in .so shared libs. This has not been further worked upon.

This may be the latest license discussion with the Odin project (see issue #25 and issue #21) for the previous episodes.

Rein Klazes reported some very good news coming from the Odin folks: Project Odin Software License has been changed. Changes are not radical and are included only for the purpose of better compatibility with licenses of other open source projects and sharing of code with them. For example, the original license didn't allowed reuse of work done for Odin in Wine, even if the component was originally ported from Wine.

Basically, Odin project now allows some directories to be governed by another license than the Odin's one. Rein also reported that, currently, the OLE directories contain such a license (which is the Wine's one), allowing to back port Odin's enhancement to OLE DLLs back to Wine.

Alexandre Julliard and Ulrich Weigand stepped on each other toes this week. Ulrich proposed a mechanims to no loner use a global list of all builtin modules (there are in fact two: one for the 16 bit modules, and another one for the 32 bit modules). According to Ulrich, there are lots of benefits:

• no need for global knowlegde about built-in DLLs
• could potentially be used for WineLib executable modules as well, removing the need to handle WineLib resources via strange special case constructions
• could be used as a first step to splitting into shared libraries (imports will need to be handled extra)
• it's simple (mostly removes code ;-)

Alexandre then said he already implemented this very mechanism.

But, Ulrich continued on his idea and proposed also to use equivalent mechanism for WineLib apps. Basically, every WineLib should have a .spec file. From this .spec file, a winestub.c file would be constructed, allowing to:

• special-cased resource handling (LIBRES) could finally die
• WineLib apps would have standard PE (or maybe NE) module
• imports section could cause DLLs to be preloaded so that apps relying on GetModuleHandle(...) don't fail
• complete unification of Wine and WineLib startup possible

Since Alexandre didn't start working on that, it's likely Ulrich will provide this feature very soon.

Olivier Galibert asked why interrupts were not supported while executing 32 bit code. Ove Kåven, Marcus Meissner and Ulrich Weigand mostly said this was not allowed. But, it turned out that all were considering the DOS interrupts. Olivier's problems came from the PowerDVD application, using int 1a / b101.

Ulrich gave more thought on this:Argh! Those are the PCI BIOS calls... If I read the specs correctly, those use 'lar' to check the big bit of the current stack selector, and perform a 16- or 32-bit lret depending on the mode they were called from. I had thought, however, that this could only be used from, say, 32-bit DOS-extended apps, but if this call is performed by a Windows app, it would appear that it is active under Win9x as well.

Running the application with an NT emulation (instead of a Win 9x) no longer shows this behavior.

There was then a discussion on how to get the relevant information on the PCI boards (by reading /proc/pci or /proc/bus/pci files under Linux). If the application only needs informative data (read only), then this can be supported by Wine. If the application also need write access, it's likely it won't be supported.