Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Wine Traffic #42 For 8 May 2000

By Eric Pouech

Table Of Contents

Introduction

This is the 42nd 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).

Mailing List Stats For This Week

We looked at 84 posts in 236K.

There were 34 different contributors. 18 posted more than once. 20 posted last week too.

The top posters of the week were:

1. IsBadPtr and such

 Archive Link: "Problem with the new IsBad[Read|Write]Ptr() functions"

People: Peter Ganten, Ulrich Weigand, Alexandre Julliard, 

One of Alexandre Julliard's recent patch included a rewrite of the IsBadReadPtr functions. Those functions check if a chunk of memory defined by its address and size is readable/writable... The old implementation was parsing the /proc pseudo filesystem to get the memory mappings and to derive from it if the memory chunk was mapped, and if so, with the correct attributes (read, write). Alexandre changed it to use a read/write access to that chunk protected by an exception frame. This exception frame catches all undesired accesses, and thus provides the desired behavior.

Peter Ganten reported a changed behavior the loading mechanism:
When COMCTL32 is loaded, PE_LoadImage() checks, if this is a system DLL (base > 2GB), which it is, and thus checks if it is already loaded at that address. This check is done by first calling IsBadReadPtr() for the base address and then comparing the content of that address with the content of the library to load.

The old IsBadReadPtr() code returned true in this situation, while the new code returns false (the addresses and the relay output is identical up to this point). Most intersting is the fact, that the VirtualAlloc() call in PE_LoadImage() fails, _if_ IsBadReadPtr() has been called before. As a result, COMCTL32 will be relocated to another address and not shared, when it is loaded a second time later by the same process. COMCTL32 detects this situation and exits the process.

Ulrich Weigand gave a first explanation of what went wrong:
I guess what's happening here is that the base address of COMCTL32 (and the other system DLLs as well, b.t.w.) is just slightly below 3GB, and so the attempted access in IsBadReadPtr() falls into the unmapped range immediately below the Linux stack, which is mapped as VM_GROWSDOWN. Such accesses trigger automatic growing of the stack downwards to include the accessed address. Therefore, not only will the access succeed, subsequent attempts to use the range for mmap() will fail :-/

Ulrich and Alexandre discussed various solutions to solve this issue including:

2. Spying tools

 Archive Link: "Some useful info"

People: , Dmitry Timoshkov

Dmitry Timoshkov posted a link to some useful tools which can be of some help for people crafting Wine: http://members.xoom.com/EliCZ/import.htm

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.

Mirror provided by HKMirror. Sponsored by Porno Verzameling and webcamsex