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 #25 For 10 Jan 2000

By Eric Pouech

Table Of Contents

Introduction

This is the twenty fifth 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 129 posts in 670K.

There were 34 different contributors. 22 posted more than once. 21 posted last week too.

The top posters of the week were:

1. Better support for Cyrillic fonts

 Archive Link: "CodePages and internal unicode support"

People: Dmitry Timoshkov, Ove Kåven, , Huw Davies

Dmitry Timoshkov proposed for discussion a patche to enhance the display of Cyrillic characters in Wine. This patch is covering quite a few parts of Wine:

Even if Dmitry reported better results display results with
Charmap.exe (16 bit) from Russian Windows 95 and PageMaker 6.5 Russian Edition (32 bit)
, he requested for some feedback.

Ove Kåven quite didn't like the configuration options suggested by Dmitry and proposed some alternatives:

Then, Ove suggested to
deduce the codepage information from the UNIX locale information (at least if the registry key is unavailable) ? (We could get rid of the -lang command line switch once and for all while we're at it).

Dmitry agreed on it. Later on, Dmitry also discussed with Huw Davies some details of mapping the unicode characters strings to the X11 loaded fonts (especially when those were not unicode).

As a conclusion, Dmitry has still some polishing to do to his patch, but this will sure help for a better displaying of Cyrillic fonts in Wine..

2. Retrofitting Odin project's modifications

 Archive Link: "Unidentified subject!"

People: Alexandre Julliard, Rein Klazes, 

Rein Klazes sent a patch containing the enhancement brought by the Odin project (see Issue #21, Article #1) to the treeview common control.

Alexandre Julliard rejected the patch because the current Odin license doesn't allow back porting the Odin's changes to Wine. The good part of the thread, is that the Odin's folks are under the process of changing their license so that retrofitting to Wine will be possible.

Some talks followed trying to make clear whether or not modifications existing before the license change could be retrofitted or not, and this will depend on the choice of the Odin developers.

3. Improving PE loader

 Archive Link: "PE Loader speedup patch (it works!)"

People: Jürgen Schmied, Ulrich Weigand, , Gav State, ReactOS

Guys from Corel have kept working on improving the PE loader (see Issue #20, Article #2). They finally reached a stable solution. Gav' State reported some new figures on the speed-up: they achieved on one application a reduction from 11 seconds to 5 seconds to get it started.

However, Gav had to make his patch to add some Wine specific flags to existing Windows APIs. This allows to adapt the behavior of those APIs to the needs of the loader improvement (mainly not to consider the default alignment and granularity while mapping part of files).

Some discussion went on trying to provide better ways of doing it (there is always risk to change/extend the semantics of an existing Windows API), and also some re-architecturing of Wine's internal parts related to memory management and mapping ; to name a few:

Some pointers and URLs have been also exchanged to get the relevant information of those API (some are poorly documented). Amongst the provided ones, we can list:

Later on, Gav State also asked whether the base relocation of the DLLs should be done in the seg-fault handler as Windows does (see also the previous issue for the details).

Ulrich Weigand replied, but with a more pessimistic tone than he did some months ago,
Well, I'd originally thought it would be easy, but then I noticed that there are of course rather ugly race conditions involved (two threads executing the same page: one faults, the handler loads the page and starts applying fixups; the second doesn't fault because the page is already there, and executes code with fixups only half applied :-/).

To make it works, this would imply a closer link between the OS memory manager and the user space routines, which is rather not doable. Ulrich suggested (at least for Corel applications) to base all their DLLs at different addresses so that they can be loaded without applying any relocation.

 

 

 

 

 

 

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