[LWN Logo]
[Timeline]
Date: Wed, 06 Sep 2000 06:08:30 +0000
From: Eric Pouech <Eric.Pouech@wanadoo.fr>
Newsgroups: comp.emulators.ms-windows.wine
To: "Wine announce (WWN publish)" <wine-announce@winehq.com>
Subject: Wine Weekly News #59 (2000 Week 36)

This is a multi-part message in MIME format.
--------------BAE0B46552527ED6BB338407
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

please find enclosed this week edition
A+
-- 
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
--------------BAE0B46552527ED6BB338407
Content-Type: text/plain; charset=iso-8859-1;
 name="wwna.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="wwna.txt"


                              Wine Weekly News
                                      
   All the News that Fits, we print.
   
   Events, progress, and happenings in the Wine community for September
   4, 2000.
     _________________________________________________________________
   
   
     _________________________________________________________________
   
Headlines
     _________________________________________________________________
   
     * Jutta Wrage announced that the latest version of the Wine-HOWTO is
       available at [1]http://www.la-sorciere.de/Wine-HOWTO/index.html
     _________________________________________________________________
   
Keeping Track of Wine
     _________________________________________________________________
   
     * Andreas Mohr made tools/wineinstall remove any existing RPMs
       before installing (just in case), fixed some messages and
       spelling, and did some bugfixes to common controls, message
       queues, file dialog, process command lines, ...
     * Peter Ganten made it possible to override DLLs using complete
       paths.
     * Peter Hunnisett let Wine emit a better message if Direct3D support
       is not available, and did a bit more DirectPlay groundwork.
     * Alexandre Julliard restructured some wineserver request mechanisms
       to work better with exception handling, and fixed a buffer
       overflow.
     * Hidenori Takeshima improved DBCS support.
     * Lionel Ulmer added some more DirectDraw/Direct3D features.
     * James Abbatiello fixed a DirectSound threadsafety bug, added
       VXDLDR stubs, and fixed a debugger bug in "nexti".
     * Marcus Meissner made the Win32 console driver less dependent on
       user32.dll, and made it track mouse movement, not just clicks.
     * Mike McCormack fixed a common control sorting problem that caused
       infinite recursions.
     * Patrik Stridvall did the usual winapi_check updates.
     * Phil Cole fixed a couple of bugs in tools/wineinstall and
       tools/wineconf.
     * Gerald Pfeifer fixed a compilation issue.
     * Albert den Haan (Corel) fixed some Unicode and X11 encoding
       issues.
     * From Macadamian:
          + Francois Methot: Toolwindow fix.
          + Jean-Claude Batista: Animation common control improvements.
          + James Hatheway: Implementation of ole32.CoGetPSClsid().
          + Stephane Lussier: Winsock error handling fix.
          + Francis Beaudet, Henning Hoffmann: MDI fixes.
     _________________________________________________________________
   
Discussions on wine-devel
     _________________________________________________________________
   
   This week, 66 posts consumed 214 K. There were 27 different
       contributors, 16 (59%) posted more than once, and 14 (51%) posted
       last week too.
       The top posters of the week were:
       
     * 6 posts in 14 K by "Dmitry Timoshkov" <dmitry@sloboda.ru>
     * 5 posts in 13 K by Eric Pouech <Eric.Pouech@wanadoo.fr>
     * 5 posts in 11 K by "Alexandre Julliard" <julliard@winehq.com>
     * 5 posts in 10 K by gerard patel <g.patel@wanadoo.fr>
     * 5 posts in 10 K by David.Goodenough@dga.co.uk
     * 4 posts in 14 K by Gavriel State <gav@transgaming.com>
     * 3 posts in 8 K by lawson_whitney@juno.com
     * 3 posts in 8 K by "Dimitrie O. Paun" <dimi@cs.toronto.edu>
     * 3 posts in 38 K by David Howells <David.Howells@nexor.co.uk>
     * 3 posts in 17 K by Albert den Haan <oponvybl@umail.corel.com>
     * 3 posts in 10 K by "Jeremy White" <jwhite@codeweavers.com>
     * 2 posts in 6 K by Osvaldo Fornaro <ofornaro@exa.unicen.edu.ar>
     * 2 posts in 6 K by "Patrik Stridvall" <ps@leissner.se>
     * 2 posts in 5 K by Marcus Meissner <marcus@jet.franken.de>
     * 2 posts in 4 K by Andreas Mohr <a.mohr@mailto.de>
     * 2 posts in 3 K by "Ove Kaaven" <ovehk@ping.uio.no>
       
   Page Maker and thunks Issue
   
   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.
   
   Enhanced CVS commits overview Evolution
   
   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:
       
     * 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
       
   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: 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/C
       VSROOT/evolvelog&id=967585195303215279709548
       Revision  Changes    Path
        1.19     +38 -20    evolve-client/com/esolutions/mdl/dbaccess/Abs
       tractUpdater.java
        1.8      +4 -2      evolve-client/com/esolutions/mdl/dbaccess/Cli
       entUpdater.java
        1.9      +88 -125   evolve-client/com/esolutions/mdl/logger/Creat
       eLog_XML.java
        1.4      +7 -7      evolve-client/com/esolutions/mdl/logger/LogRe
       cord.java
        1.7      +23 -20    evolve-client/com/esolutions/mdl/logger/Updat
       eLog.java
       
   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.
   
   Scanner support Evolution
   
   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.
   
   A way to speed up Wine Evolution
   
   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:
       
     * 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.
   
   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
   
        Credits: [2]Doug Ridgway, [3]Eric Pouech, and [4]Ove Kåven.
     _________________________________________________________________

References

   1. http://www.la-sorciere.de/Wine-HOWTO/index.html
   2. mailto:ridgway@winehq.com
   3. mailto:pouech@winehq.com
   4. mailto:ovek@winehq.com

--------------BAE0B46552527ED6BB338407--