Wine Traffic #26 For 17�Jan�2000
Table Of Contents
This is the twenty sixth release of the Wine's kernel cousin
publication. It's main goal is to distribute widely what's
going on around Wine (the Un*x windows emulator).
WineHQ is still having some trouble after the upgrade 2 weeks
ago. Most of the servers are up and running, even the NNTP got back
its posted articles; however the NNTP server is no longer
updated. This is worked upon, but, unfortunately, not yet done.
Mailing List Stats For This Week
We looked at 159 posts in 589K.
There were 37 different contributors.
22 posted more than once.
20 posted last week too.
The top posters of the week were:
- 19 posts in 75K by Ulrich Weigand <email@example.com>
- 18 posts in 43K by Eric Pouech <Eric.Pouech@wanadoo.fr>
- 16 posts in 38K by Alexandre Julliard <firstname.lastname@example.org>
- 13 posts in 42K by Patrik Stridvall <email@example.com>
- 8 posts in 21K by Uwe Bonnes <firstname.lastname@example.org>
- Full Stats
WineLib apps, C++ and global constructors
�Archive Link: "Again WineLib problems"
,�Ulrich Weigand,�Bertho Stultiens,�Eric Pouech
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:
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.
- Outer entry point
- main() which calls all the winelib initialisation code
- main calls WinMain() which contains all the program code.
Odin project license change
�Archive Link: "Odin's changed license"
Rein Klazes,�,�Rein Klaze
This may be the latest license discussion with the Odin project (see
issue #25 (wn20000110_25.html#0)
issue #21 (wn19991213_21.html#0)
) for the previous
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
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
.spec files everywhere
�Archive Link: "RFC: Auto-registration of built-in DLLs"
Ulrich Weigand,�Alexandre Julliard,�
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:
The only known drawback is a dependancy on a gcc feature, (the
__attribute__((constructor)) telling that a function has to be called
before main() is entered; this is used in this case to register the
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:
- 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
- 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 ;-)
Since Alexandre didn't start working on that, it's likely Ulrich will
provide this feature very soon.
- 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
PCI access thru BIOS
�Archive Link: "Re: PATCH: ignore int in 32bit mode"
Ulrich Weigand,�,�Ove K�ven,�Marcus Meissner
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.
Sharon And Joy