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

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.

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.