Wine Traffic #59 For 4 Sep 2000
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
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:
- 6 posts in 14K by Dmitry Timoshkov <email@example.com>
- 5 posts in 13K by Eric Pouech <Eric.Pouech@wanadoo.fr>
- 5 posts in 11K by Alexandre Julliard <firstname.lastname@example.org>
- 5 posts in 10K by gerard patel <email@example.com>
- 5 posts in 10K by David.Goodenough@dga.co.uk
- Full Stats
Page Maker and thunks
28 Aug 2000 - 31 Aug 2000
Archive Link: "Thunking problem is partially solved"
Ulrich Weigand, , Dmitry 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
Ulrich Weigand gave the full explanation:
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.
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
This means that Win95 does not in fact copy any
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
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.
Enhanced CVS commits overview
29 Aug 2000 - 30 Aug 2000
Archive Link: "Generating patches from commit logs"
Dimitrie Paun proposed some ideas to enhance CVS commits follow up:
Such a message could look like (examples are from Dimi's production
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
- 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
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.
ChangeSet ID: 967585195303215279709548
Module name: evolve-client
Changes by: firstname.lastname@example.org. 00/08/29 17:39:55
Sync: fixed problem when there are more than one meta columns with the same table/field names in a meta object.
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
31 Aug 2000
Archive Link: "Implementing TWAIN support in Wine"
Jeff Tranter made the following announcement:
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.
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:
- TWAIN implements a graphical user interface. There are two
different approaches that could be used for implementing it:
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
- Implement the UI as WIN32 code in Wine
- Use an external SANE application like xscanimage
- 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.
- 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
- 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.
A way to speed up Wine
29 Aug 2000
Archive Link: "Possibility for massive wineserver speedup"
David Howells posted a thread that may end up in re-architecturing
Wine (a bit):
Even if first benchmarks are promising (3% over Win2000, up to 20% for
some test programs over Win2000 ; 900% over current Wine
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
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
At the moment it does the following:
- WaitForMultipleObjects (mostly)
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.
Sharon And Joy