Wine Traffic #59 For 4 Sep 2000

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.

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:

• generate a ID for each message sent out
• include it in the message along with a summary of changes
• include a link in the message that passes to a CGI program the ID of the commit
• the CGI program searches the commitlog, extracts the summary info and generates the patch

ChangeSet ID: 967585195303215279709548
CVSROOT: /usr/local/cvsroot
Module name: evolve-client
Changes by: fchung@redpill.redcelsius.on.ca. 00/08/29 17:39:55

Modified files:
 com/esolutions/mdl/dbaccess: AbstractUpdater.java
                              ClientUpdater.java
 com/esolutions/mdl/logger: CreateLog_XML.java
                              LogRecord.java UpdateLog.java

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

Patch:
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/AbstractUpdater.java
 1.8      +4 -2      evolve-client/com/esolutions/mdl/dbaccess/ClientUpdater.java
 1.9      +88 -125   evolve-client/com/esolutions/mdl/logger/CreateLog_XML.java
 1.4      +7 -7      evolve-client/com/esolutions/mdl/logger/LogRecord.java
 1.7      +23 -20    evolve-client/com/esolutions/mdl/logger/UpdateLog.java


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.

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:

• CreateEvent
• OpenEvent
• PulseEvent
• ResetEvent
• SetEvent
• CreateMutex
• OpenMutex
• ReleaseMutex
• CreateSemaphore
• OpenSemaphore
• ReleaseSemaphore
• WaitForMultipleObjects (mostly)
• CloseHandle

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.