Table Of Contents
|1.||Service thread (cont'd)|
|2.||CreateProcess for WineLib|
|3.||Port of Wine to different Un*ces|
This is the first release of Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).
Bertho Stultiens annouced that the Wine's CVS server should be up and running again, after he upgraded the Linux kernel of the server.
1. Service thread (cont'd)
�Archive Link: "Windows timer broken"
People: ,�Ulrich Weigand,�Eric Pouech
Ulrich Weigand reported that the latest modification to the service thread (being now instanciated in each process) broke the current windows's timer implementation. He also proposed a fix for this, but pointed out that the same type of error breaks current use of service thread (mainly multimedia timers and system time).
Eric Pouech then asked of the best way for a DLL to store information on a per process basis.
Ulrich Weigand then proposed (http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/1999-06/Subject/article-277.html) an extension of the module reference structure and a couple of functions to cope with this.
2. CreateProcess for WineLib
�Archive Link: "CreateP for WineLib"
People: Dave Pickles,�Ulrich Weigand,�Slava Monich,�
Dave Pickles, trying to use CreateProcess() from WineLib, asked whether "if it is actually necessary for a new instance of Wine to be created in this way" by forking a new Unix process, and also noted that "the new application does not inherit the DOS environment, current default drive and directory and the current directories on other DOS drives from its parent."
Ulrich Weigand explained the current evolution of Wine and WineLib regarding processes and address spaces:
Well, there used to be one fundamental difference between Wine and WineLib: in Wine, there was the 16-bit task scheduler running (doing cooperative multitasking implemented in user space by stack switching), while in WineLib, the scheduler was short-circuited (to avoid use of 16-bit code in WineLib). This made it fundamentally impossible to run more than one task in a single WineLib instance.
Just recently, though, the 16-bit task scheduler was removed also from Wine (all tasks now run in their own thread, and cooperative multitasking is simulated using synchronization primitives). This and other changes should reduce the differences between Wine and WineLib to the point where Wine itself will be just a normal WineLib application.
So, at this point it would be possible to run several Windows processes even in a WineLib instance. We're not quite there yet, however ...
(On the other hand, the preferred development would be in the other direction: in the end, even Wine should rather spawn new Unix processes for every Windows process to implement proper address space separation for Win32 processes.)
David Pickles acknowledged on the type of actions to be taken and Slava Monich asked "Making Wine Win32 processes run each in separate address space is good, no doubt. But here's a potential problem: I can name a number of apps that do CreateProcess and then want to communicate with the process they have created by doing things like FindWindow, Post/SendMessage and such. In other words, Win32 processes shouldn't be *completely* independent. There must be a way (at least) to send a message to another process. How about that?" ".
Ulrich Weigand concluded by listing the work to be done to achieve address-space separation for Wine processes:
Indeed. This is exactly the reason why we *don't* have separate address spaces yet ;-)
First, we'll need to make all necessary inter-process actions work. In part, this has already been done: in fact, one of the main reasons for introduction of the Wine server was that this makes it possible to use the Win32 synchronization objects correctly across address space boundaries. Shared memory mappings should also work already.
What remains to be done is mainly USER stuff: access to shared USER structures like windows, and inter-process message handling. There's two options how to do this: we might use shared memory (the 16-bit USER data segment could be shared, like all 16-bit segments will probably have to be, and the various USER data structures would then reside in this segment), or else we might employ the Wine server (e.g. for message passing).
Then there's also a lot of Wine routines that assume a single address space, e.g. by maintaining a linked list of objects of some sort, anchored in a global variable ... All this will have to be cleaned up.
So in short, properly implementing separate address spaces will be one of the next major projects ... It's necessary to do it, though, because of the problems caused by non-relocatable EXE files.
3. Port of Wine to different Un*ces
�Archive Link: "Winelib ports to other Unices"
People: Patrick Stridvall,�Zygo Blaxell,�,�Patrick Stridval
Alan Shutko volunteered to help porting WineLib to different Un*ces he has access to (DUX/Tru64, AIX, Solaris/Sparc, Irix and HP-UX), and asked for a contact point.
Patrick Stridvall answered by listing his undergoing activities:
and openly asked for suggestion to structure this porting acticity.
Zygo Blaxell (from Corel) shared with the wine developpers some inner parts of his private life and gave and outlook of his current activities: "For Wine I have some work in progress that improves the GDI-on-X11 drivers: just faster bitblt at first, then later improving font support and doing some of the weird things our apps want. For Winelib, I'm working on a set of perl scripts that make a stab at automatically translating NMAKE and .BAT files for building a Win32 application on Windows into GNU Make files and shell commands for building a Winelib application on Unix."
Patrick Stridvall closed the thread by explaining to Alan Shutko the potential pitfalls he wants to avoid in compiling WineLib on other Un*ces.
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.