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 #28 For 31 Jan 2000

By Eric Pouech

Table Of Contents

Introduction

This is the twenty eighth 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 95 posts in 278K.

There were 40 different contributors. 21 posted more than once. 26 posted last week too.

The top posters of the week were:

1. Wine is a slashdot nominee

26 Jan 2000 (2 posts) Archive Link: "Slashdot awards"

People: Alexandre Julliard, 

Alexandre Julliard proudly announced that Wine
has been nominated for the Most Improved Project slashdot award, the press release is here:

I encourage you all to go to slashdot and vote; $30k would make a hell of a Party Fund ;-) And if you are in NYC next week there is free beer at the slashdot party so even if we don't win we can still have a drink there...

2. DIB sections

27 Jan 2000 - 30 Jan 2000 (5 posts) Archive Link: "DIB problems and the faulthandler"

People: Ulrich Weigand, Alexandre Julliard, , Gav State

Bradley Baetz reported a(nother) bug in DIB sections handling (you can check issue #34 for more on this matter). The following code fragment works under Windows and not in Wine:

hBufferObject = CreateFileMapping(
        (HANDLE)0xFFFFFFFF,
        NULL,
        PAGE_READWRITE,
        0,
        size,
        NULL);

lpvBuffer = MapViewOfFile(hBufferObject, FILE_MAP_ALL_ACCESS, 0, lBufferOffset, size);

...

hdcCompatInput = CreateCompatibleDC(hDCWindow);

hbmInput = CreateDIBSection(hdcCompatInput,
        (LPBITMAPINFO)decompressedFormat(),
        DIB_RGB_COLORS,
        &lpvInput,
        hBufferObject,
        offset);

As already explained, each DIB in Wine is associated to a X11 Pixmap. Writing directly to the DIB data section "dirties" the DIB (in fact the data section is protected against write and trying to write to it triggers a fault handler which does the job), which then knows that the X11 Pixmap must be updated to reflect the modification to the DIB data section. In that case the DIB data section is mapped twice in the process address space (once with MapViewOfFile and the second time with CreateDIBSection), hence fooling the DIB fault handler.

Ulrich Weigand tried to find some ways to solve this:
Unfortunately, this would appear to be hard to fix. To keep the protection mechanism working, we'd have to protect all aliased addresses pointing to the same data. I'm not sure whether there is even an easy way to find out if a given file region is already mapped :-/

There might be one work-around: according to the docs, Windows does not guarantee automatic synchronization between GDI and direct accesses to a DIB section; the user has to ensure it by calling GdiFlush(). If your app does in fact do this, we could maintain a list of currently-mapped DIB sections, and get them all in sync whenever GdiFlush() is called ...

In another thread related to DIB sections, it occurs that some protections were missing while updating the Pixmap linked to a DIB section (when Wine directly modifies the Pixmap, it must reflect those changes to the DIB data section). This is properly done for the blit operations, but not for the other ones (like lines, fonts...). A patch circulated long ago for it, and Bradley asked why it has never been applied. Gav State said that this very patch has been in Corel's tree for a while and with good success. Alexandre Julliard didn't find any reasonable reasons to reject it, so he asked someone to resubmit it.

3. COM implementation and WineLib

28 Jan 2000 - 29 Jan 2000 (3 posts) Archive Link: "COM implementation problems"

People: , Francois Gouget, Gav State

Michael Kowalski reported some issues with a C++ WineLib program using the MFC. Michael investigated the case and it turned that this is caused by a wrong compatibility (in WineLib case) with MFC. For alignment reasons (and to get MFC compatible COM virtual tables), some dummy entries have to be added at the beginning of the vtable. There's a macro (ICOM_MSVTABLE_COMPAT) in include/wine/obj_base.h that takes care of that.

However, Gav State pointed out that some internal (built in) vtables didn't make a correct use of this padding (as, for example, the file dialog browser).

Francois Gouget, grep:ing faster that the rest of the developers, found some other areas were this error exists. He shall fix this really soon.

 

 

 

 

 

 

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.