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--