Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
Git
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins
 

Wine Traffic #57 For 21 Aug 2000

By Eric Pouech

Table Of Contents

Introduction

This is the 57th 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).

Mailing List Stats For This Week

We looked at 79 posts in 256K.

There were 34 different contributors. 18 posted more than once. 18 posted last week too.

The top posters of the week were:

1. Some more Winelib usage

13 Aug 2000 (1 post) Subject: "Request for Alpha sites"

People: Ed Snow

Ed Snow made the following request on comp.emulators.ms-windows.wine
A wine based application is about to begin an alpha test cycle. We are looking for people interested in performing an install, testing functionality, and providing feedback. The approach of using Wine was based on speed to market, cost, and ability to stay synchronized with the Windows based offering. This approach has worked extremely well, principally due to the maturity of wine and the efforts of the Wine community. However, the testing of a Wine based application is something that we will need your help with. The alpha test cycle will be by invitation (you send your email, we will send a pointer to get the install kit) and will be limited in size. This will be followed by a public beta. The emphasis is to get feedback on a wide selection of machines/environments quickly before the public beta.

To become an alpha site you need to have a multimedia enabled PC, and provide the following information As an alpha participant, we're asking you to spend at least 30 minutes using our application, and then to fill out a short Customer Satisfaction Survey.

Good to see some other companies using Wine as their base porting tool. If you're interested don't hesitate to get in touch with Ed (alphatest@ttmengineering.com).

2. Suicidal tendencies and NE loader

12 Aug 2000 - 14 Aug 2000 (7 posts) Archive Link: "MMSYSTEM.Suicide()"

People: Eric PouechAlexandre JulliardAndreas Mohr

Andreas Mohr reported a failed assertion in Wine code while using some (old) 16 bit application. Some DLLs (like MMSYSTEM in this case) store per process information ; those per process structures are allocated and initialized when the DLL is mapped into the process address space (and added to its list of loaded modules).

The triggered assertion occurred because some MMSYSTEM APIs were called before this initialization was done.

After some investigation, it turned out that quite a few Wine's DLL can be affected by the symptoms described by Andreas.

As Eric Pouech explained it, native 16 bit (NE) DLLs can have two types of "init" functions

As of today, some Wine builtin DLLs use the second function to create the instance data. However, Andreas' program was directly calling into MMSYSTEM after MMSYSTEM's LibMain has been called but before the DllEntryPoint was invoked, hence the error.

On the other hand, Wine builtin 16 bit DLLs don't support the LibMain function (but don't be confused, the Wine loader, while attaching a 16 bit native DLL will call its LibMain function).

In fact, the situation is just a bit more complex: lots of Wine's builtin DLL come in pairs (the 16 bit and the 32 bit DLL). As Wine's core tends to be more and more a 32 bit system, the 32 bit DLL can work without their 16 bit counterpart, whereas a 16 bit DLL relies on the 32 bit to do the horse work. In the area of initialization, a Wine builtin 16 bit DLL will load its 32 bit counter part, which in turn will do the initialization of the two DLLs.

This two DLLs are also physically stored in the same ELF .so file.

Eric Pouech listed a few options to solve Andreas' issue:

Alexandre Julliard agreed on one of them:
Yes, the idea is to use it (Ed Note: the 'owner' field) to load the 32-bit dll that contains the 16-bit one, since only 32-bit dlls will be able to import functions from other dlls. Once this is done it should be possible to do all dll initialization in the 32-bit dll which will (hopefully) ensure they are always done in the right order.

No patch has been issued yet.

3. Rumors

14 Aug 2000 - 15 Aug 2000 (8 posts) Archive Link: "Corel porting WordPerfect Office to the MacIntosh"

People: Patrik StridvallDoug RidgwayPatrik StridvalDouglas RidgwayGavriel State

Patrik Stridvall quoted a peguinista.org article:
According to an Email from a Corel development engineer in early 1999 to the Wine Project's public mailing list server for developers, Corel had begun work by then on porting the Wine tools themselves to the Mac PowerPC platform. Corel has left no doubts that its cross platform goals extend beyond the Windows and Linux platforms.

Unofficial Corel's answer rejected those allegations. Lots of people remembered a post from Gavriel State, while at Corel, reporting some success with Winelib port to LinuxPPC (hence the confusion).

Anyway, the discussion evolved a bit on the technical details of really doing the job (using X11 server plus MacOS/X or even a native Mac driver). The MacOS/X seems to provide all the needed "common" Unix API (Patrik reminded that BeOS is almost stuck because of the lack of such features - like mmap or {send|recv}msg with file descriptor as parameter).

Douglas Ridgway had the final word
Remember also that Corel supports Draw on the Mac. Since this would share most of the codebase with Draw Windows, there already exists a Win32-on-the-Mac compatibility layer, developed in house long before Wine entered the picture. Certainly the last quoted sentence is true (their cross platform goals extend to the Mac) and it would seem to be a good idea to only have to rely on one cross platform Win32 layer.

Of course, there's a difference between good ideas, good ideas that they are working on, and good ideas that they are working on that they are willing to talk about. Based on what Jeff says, this is probably just a good idea, nothing more.

 

 

 

 

 

 

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.