All the news that fits, we print.
|
This week, 66 posts consumed 214 K. There were 27 different contributors. 16 (59%) posted more than once. 14 (51%) posted last week too. The top 5 posters of the week were:
|
| Page Maker and thunks | 28 Aug 2000 00:00:00 -0800 | Archive |
|---|---|---|
| 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 separate 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 | 29 Aug 2000 00:00:00 -0800 | Archive |
|---|---|---|
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 cannot 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:
| ||
| Scanner support | 31 Aug 2000 00:00:00 -0800 | Archive |
|---|---|---|
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:
| ||
| A way to speed up Wine | 29 Aug 2000 00:00:00 -0800 | Archive |
|---|---|---|
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:
| ||
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License,
version 2.0.
