Wine Traffic #59 For 4 Sep 2000

By Eric Pouech

Table Of Contents


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

Jutta Wrage announced that the latest version of the Wine-HOWTO is available at (

Mailing List Stats For This Week

We looked at 66 posts in 214K.

There were 27 different contributors. 16 posted more than once. 14 posted last week too.

The top posters of the week were:

1. Page Maker and thunks

28 Aug 2000 - 31 Aug 2000 (8 posts) Archive Link: "Thunking problem is partially solved"

People: Ulrich WeigandDmitry Timoshkov

Dmitry Timoshkov has been busy trying to have Page Maker up and running. Dmitry first discovered a strange behavior: Page Maker was crashing while using the Win95 thunks. Dmitry thought that a simple workaround was to use -winver nt40 switch, but the program still crashed. In fact, Page Maker guesses the Windows version from the presence of Win95 thunks. Since Wine provides all the possible thunks mechanisms, Page Maker is fooled.

However, by removing the Win95 thunking entry points, Dmitry got Page Maker to come up finally. But that left the crash in Win95 thunking unexplained. With some further investigations, Dmitry proved that the crash was due to some bad arguments popping when the thunk is returned.

Ulrich Weigand gave the full explanation:
The problem is that we implement thunks differently than Win95 does, with the most important difference being that we actually have two seperate stacks per app, a 16-bit one and a 32-bit one, where Win95 has only one stack: 16-bit apps have their 16-bit stack, and when thunking to 32-bit, ESP is simply set to the appropriate 32-bit flat pointer pointing to the current 16-bit stack location; 32-bit apps have their 32-bit stack, and when thunking to 16-bit, a temporary SS selector is allocated that covers the current 'window' on the 32-bit stack.

This means that Win95 does not in fact copy any arguments in QT_Thunk and the other thunking routines; they simply stay on the stack. Similarly, all modifications made to SP by the called routine are preserved, so if the 16-bit routine pops N argument bytes, those arguments will also be popped on the 32-bit stack after return of QT_Thunk.

We, on the other hand, have to copy arguments to the 16-bit stack. Unfortunately, we don't know how many arguments to copy, thus we copy in fact the largest possible size (i.e. from ESP to EBP-0x40. EBP-0x40 is because the region EBP-0x40..EBP is a parameter block for use by QT_Thunk that has to be set up by the caller). As we don't know the actual argument size, we don't know how much to pop off the 32-bit stack either.

This works fine if the caller of QT_Thunk is one of the thunk stubs generated by the MS thunk compiler (which is supposed to be the only code that ever calls QT_Thunk), because these stubs don't have any other local variables on the stack, and return to their caller immediately after QT_Thunk returned.

Apparently, your app calls QT_Thunk manually, from within a routine that does in fact care about the proper ESP value after return of QT_Thunk. This unfortunately doesn't work with the current Wine code. To fix this, we'd need to find out how many bytes the 16-bit routine popped off the stack, which is currently not possible.

Ulrich Weigand went on explaining the current difficulties of Wine being aware of the actual size of arguments to pop off, but no solution has been found so far.

2. Enhanced CVS commits overview

29 Aug 2000 - 30 Aug 2000 (6 posts) Archive Link: "Generating patches from commit logs"

People: Dimitrie Paun

Dimitrie Paun proposed some ideas to enhance CVS commits follow up:
For the longest time I wanted to be able to look at some of the changes that make it into the repository. It is a great way to review code, follow the latest changes, and understand/learn new code areas.

For the time being, one can (partially) do that by reading the diffs sent out by Alexandre with each release. However, they are _very_ big, and one can not easily separate the logical changes from one another.

Instead, what I was looking for was more on the lines of somehow being able to easily look at the diff associated with any of the email messages sent to wine-cvs list. That is, have a link sent out together with the message on which I can click to view the respective diff.

Now, wanted this feature so badly that I actually went ahead and implemented it! :))) Here is the idea:

Such a message could look like (examples are from Dimi's production site):

ChangeSet ID: 967585195303215279709548
CVSROOT: /usr/local/cvsroot
Module name: evolve-client
Changes by: 00/08/29 17:39:55

Modified files:

Log message:
    Sync: fixed problem when there are more than one meta columns with the same table/field names in a meta object.

http://cvs/patch?root=/usr/local/cvsroot&logs=/usr/local/cvsroot /CVSROOT/evolvelog&id=967585195303215279709548

Revision  Changes    Path
 1.19     +38 -20    evolve-client/com/esolutions/mdl/dbaccess/
 1.8      +4 -2      evolve-client/com/esolutions/mdl/dbaccess/
 1.9      +88 -125   evolve-client/com/esolutions/mdl/logger/
 1.4      +7 -7      evolve-client/com/esolutions/mdl/logger/
 1.7      +23 -20    evolve-client/com/esolutions/mdl/logger/

No strong objections appeared, but some polish may be needed even if Dimi runs his script on a production site, mainly around server load. We'll keep you posted if this feature is put in place.

3. Scanner support

31 Aug 2000 (1 post) Archive Link: "Implementing TWAIN support in Wine"

People: Jeff Tranter

Jeff Tranter made the following announcement:
I want to give a heads up on some Wine development we are doing, in case anyone else is looking at something similar or wants to help.

We would like to implement support for scanners. The Windows way to do it is with TWAIN. The native Linux way to do it is with SANE. We're looking at implementing the TWAIN API in Wine on top of SANE. A co-op student here spent a few weeks researching this and has some prototype code. His research identified a number of design issues:
  1. TWAIN implements a graphical user interface. There are two different approaches that could be used for implementing it:
    1. Implement the UI as WIN32 code in Wine
    2. Use an external SANE application like xscanimage
    We are leaning towards the first option because it will support the same look and feel as Wine, avoid legal issues with using SANE code, and keep everything under our control. But this leads to the next issue...
  2. TWAIN devices typically have a custom UI for each device, provided by the vendor. The SANE approach is to poll the device for its capabilities and dynamically build up the UI. This means the UI only has to be implemented once, but it is more work.
  3. There are a fixed number of device capabilities specified by the TWAIN Specification. However, device capabilities are dynamic in SANE and there isn't a standard about the capability names. It would be difficult to negotiate capabilities in TWAIN given that we don't know what capabilities a SANE driver would provide. One possible solution is to use a device configuration file to describe the mapping between capabilities supported by a SANE driver and those specified by TWAIN.
  4. We have to check the legal issues with using the TWAIN header file and linking with the SANE library.

We have some prototype (alpha quality) code. It currently doesn't do very much. It is in our current corelwine CVS in dlls/twain but is not normally enabled. You're welcome to look at it.

A work term report should be coming in the next couple of weeks that will document more of what was done and where the work can proceed from here. We expect someone else at Corel will be assigned to continue this work.

That's good news for Wine, it will further extend the Wine capabilities. So, if you're interested in this area, feel free to help polishing/testing the work underway.

4. A way to speed up Wine

29 Aug 2000 (3 posts) Archive Link: "Possibility for massive wineserver speedup"

People: David Howells

David Howells posted a thread that may end up in re-architecturing Wine (a bit):
I've made a start on a kernel module implementing some wineserver-type functionality, and I think that I've reached a reasonable point to put it up for discussion.

At the moment it does the following:

Unfortunately, it can't actually be integrated into Wine just yet, since it only supports three of the many 'kernel' object types, and WaitFor*() can't be shared between implementations.

Even if first benchmarks are promising (3% over Win2000, up to 20% for some test programs over Win2000 ; 900% over current Wine implementation).

Of course, this has to be studied in details (test programs are not real life programs, so your mileage may vary ; how can this be ported / maintained across non Linux platforms).

Anyway, it opens the door to Wine's speed improvement (at least 900% can be achieved on low level synchornization) and WWN will surely cover the first bits of the technical discussion next week. xs







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.