Wine Traffic #57 For 21 Aug 2000
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:
- 11 posts in 27K by Alexandre Julliard <julliard@winehq.com>
- 6 posts in 16K by Patrik Stridvall <ps@leissner.se>
- 5 posts in 13K by Eric Pouech <Eric.Pouech@wanadoo.fr>
- 4 posts in 9K by David Howells <David.Howells@nexor.co.uk>
- 4 posts in 8K by Dimitrie O. Paun <dimi@cs.toronto.edu>
- Full Stats
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
- email address
- machine class
- version of Linux
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.
2.
Suicidal tendencies and NE loader
12 Aug 2000 - 14 Aug 2000
(7 posts)
Archive Link: "MMSYSTEM.Suicide()"
People:
Eric Pouech, Alexandre Julliard, Andreas 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
- LibMain: is called to set up the DLLs itself, the first time
the DLL is loaded into memory (as all 16 bit processes share the same
address space, this is only done once even if several processes load
this DLL). Usually, the DLL used this call to initiate its data segment
(remember the old Windows 3.x: in a DLL ds != ss).
- DllEntryPoint: this optional function, when present in the DLL,
lets the DLL be notified when a process loads / unloads the DLL.
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:
- lazy instance data initialization
- implicit loading of the other DLL in the pair (but import is
not supported for 16 bit DLLs)
- smart use of 'owner' field in BUILTIN16 descriptor (so far it's
not used, but I assume that Alexandre will shortly use it for his
elfdll implementation)
- do the PE pair loading in LibMain instead of DllEntryPoint
(would require init directive to be added to 16 bit modules)
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 Stridvall, Doug Ridgway, , Patrik Stridval, Douglas Ridgway, Gavriel 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
Mirror provided by HKMirror. Sponsored by Porno Verzameling and webcamsex