WWN Issue 1

This is the first release of Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (the Un*x Windows emulator).

Bertho Stultiens announced that Wine's CVS server should be up and running again, after he upgraded the Linux kernel of the server.

Service thread (cont'd)	Archive
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 an extension of the module reference structure and a couple of functions to cope with this.

Service thread (cont'd)

CreateProcess for WineLib	Archive
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.

Archive

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.

Port of Wine to different Un*ces	Archive
Alan Shutko volunteered to help porting WineLib to different Unces 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: Platforms (Linux, Solaris, FreeBSD, BeOS etc). I have done/am working on some minor fixes. Architectures (Intel, Sparc, Alpha, MIPS etc). I have been working very little on this part. The only non-Intel machine I have access to is a very slow Sparc. Compilers/Code analysis tools (GNU C, Solaris C, GNU C++, Solaris C++, Lint etc). I have done/are currently working on these issues even though parts of my C++ efforts are not appriciated by all. :-) (I have not given up on C++ quite yet, I still hope to get in acceptable code even if I probably have to motivate each change one by one). Libraries (X11, Berlin, GGI, OpenGL etc) I have separated the X11 part from Wine in to a separate driver that will make it possible to write drivers for other graphics systems (and even run in text-only mode :-). 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 Unces.

Port of Wine to different Un*ces

World Wine News