�
Kernel Traffic
Latest�|�Archives�|�People�|�Topics 		Wine
Latest�|�Archives�|�People�|�Topics 		GNUe
Latest�|�Archives�|�People�|�Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
�

Wine Traffic #26 For 17�Jan�2000

By Eric Pouech

Table Of Contents

Introduction

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:

1. WineLib apps, C++ and global constructors

�Archive Link: "Again WineLib problems"

People: ,�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:

  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.

2. Odin project license change

�Archive Link: "Odin's changed license"

People: Rein Klazes,�,�Rein Klaze

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.

3. .spec files everywhere

�Archive Link: "RFC: Auto-registration of built-in DLLs"

People: 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 module).

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:

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

4. PCI access thru BIOS

�Archive Link: "Re: PATCH: ignore int in 32bit mode"

People: 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
�

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.