☰
WineHQ

World Wine News

All the news that fits, we print.

10 Jan 2000 00:00:00 -0800
by Eric Pouech
Issue: 25

XML source
More Issues...

This is the twenty fifth release of the Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (the Un*x Windows emulator).

This week, 129 posts consumed 670 K. There were 34 different contributors. 22 (64%) posted more than once. 21 (61%) posted last week too.

The top 5 posters of the week were:

  1. 15 posts in 57K by Patrik Stridvall
  2. 13 posts in 36K by Alexandre Julliard
  3. 10 posts in 19K by Ove Kaaven
  4. 10 posts in 33K by Ulrich Weigand
  5. 7 posts in 49K by Bradley Baetz

Better support for Cyrillic fonts Archive
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:

  • setting up the code pages and various locale in Wine's configuration file,
  • character conversion routines from and to Unicode (this uses conversion tables from unicode.org)

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:

  • either use the information from the Windows registry if it's available,
  • or deduce the information from the UNIX locale environment variables (LC_ALL, LC_CTYPE, LANG, checked in that order), by using the setlocale() call

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


Retrofitting Odin project's modifications Archive
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.

Improving PE loader Archive
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:

  • mmap() from the underlying OS,
  • the windows API (MapViewOfFile, VirtualAlloc...)
  • the Windows API from the VxDs
  • the NT DLL APIs (NtCreateSection...)

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:

  • SysInternals web site
  • Links from MSDN help pages to ZwMapViewOfSection, ZwOpenSection, ZwUnmapViewOfSection APIs.
  • Jürgen Schmied even did some advertising for MS: Another good source is (by surprise):

    Inside Microsoft NT Second Edition by Microsoft Press (!)
    ISBN 3-86063-435-6
  • and the implementations of the ReactOS project (for informative purposes only, as ReactOS is GPL'ed, its source cannot be ported to Wine).

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.

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.