Joao Clemente reported some issues with his Portuguese keyboard: I am trying to use wine (I installed this week's package) but once again I found my keyboard doesn't work properly...

I can't have the following chars right: \ | ` ' » «

I think that it's a problem related with "dead keys" (? I'm not even sure of WHAT are dead keys, sorry...) 'cause I've looked somewhere in windows/keyboard.c and it has there a comment saying something like "It works except for dead keys"

A dead key is used to generate complicated characters from the keyboard. For example (in French, sorry I couldn't resist), the ê character (e with diaresis ^), can be generated by hitting on the keyboard the ^ key, then the e key. The first hit will generate a dead key, meaning it has not to be treated as a regular character but rather as a modifier on the next character to be entered.

Dmitry Timoshkov answered a bit to Joao's questions: Actually support for dead keys can be implemented now, since Alexandre added support for composite unicode characters. I even wrote several tests to prove the concept and do 2->1 and 1->2 character conversions in WideCharToMultiByte and MultiByteToWideChar. But I have some problems:

1. Actually I don't know how to generate dead key sequence that will modify next character, because cyrillic has no this "feature".
2. Accent characters in different code pages has different mappings to unicode characters. Perhaps we just have to create internal table with mapping [combining character in code page] -> [combining character in unicode]?

Ove Kaaven went even further: It's really not that hard... under Windoze, the keyboard driver keeps some internal static variable that holds the last deadchar used (the last deadchar fed to ToAscii/ToUnicode).

When a deadkey is given to ToUnicode, it stores the deadchar into its static variable and returns -1 and the dead character. When the TranslateMessage code sees a return value of -1, it generates a WM_DEADCHAR using the returned character.

On the subsequent ToUnicode invocation, it sees that a deadchar has been stored, and tries to combine it with the incoming character. If it's able to combine them, it returns the combined character and the return value 1. If not, it returns both the uncombined dead character and the incoming character, and the return value 2. Also, it clears the static variable, of course...

TranslateMessage does send two WM_CHARs when ToAscii/ToUnicode returns 2, if I remember right, though this case is often accompanied by a beep under Windows.

Then, Dmitry (with some indication from Ove) tried to iron this out. After some first unfruitful tries, and the help of some other Russian folks, Dmitry felt he had enough information to implement proper dead keys support. However, as Ove already put up, there was two possible paths to follow: There are two approaches in implementing support for dead keys:

1. Do all the character composing in Wine itself, completely ignoring X. It will allow Wine to have full control over keyboard, but will completely ignore characters about Wine is unaware and any custom composing, that the user could have in his/her Compose file.
2. Delegate all the character composing tasks to Xlib. This will allow the user to have his/her familiar environment, but will lead to some cases, when some keyboard activity will be interpreted differently in Wine then in Windows: for instance Ctrl<T><plus><plus> will produce "#" numbersign instead of, say, call font selection dialog on Ctrl<T>. But this misinterpretations could be easy fixed by the user, because only he/she knows what behavior they want to have.

Dmitry (as Ove at first glance and Joao) preferred to use second option, even if, as Dmitry noted later on, Having Xlib to do all dead key composition is an easy way to go. But there are (at least in theory) another drivers (EdNote: for display, like a pure console one). Having dead key support in Wine itself will simplify creating those drivers, assuming that new driver should not worry about character composing, only deliver keystrokes. But such an internal support for dead keys in Wine core should not affect any driver at all: driver just will never say "I have dead key for processing", it just will silently process it itself.

However, no patch has been committed yet regarding this missing feature...

On the matter of internationalization, Howard Chan stressed some other areas: I was playing with wine and try to get some Chinese windows games working (old games in the win95 era), but it seems that there are problems with Chinese support. In particular, fonts are not right and I can't get it to display the correct font. I'm using wine-20010112 snapshot.

While hacking around (the docs on winehq has not much use since it is too outdated and file locations are totally changed) it seems that the cht (zh_TW locale) is using the wrong codepage (traditional Chinese should be using codepage 950) and it seems that the definition is not complete. I would like to help but the docs are outdated and I can't do much without understanding how the locales work on wine. I tried to change the dlls/kernel/nls/cht.nls to use codepage 950 but still it can't get the font works. Since my fonts work in X11 and mozilla I think it's wine that is causing the problem.

BTW, Japanese support seems OK since I can successfully load Japanese window games with correct text displayed, so the multibyte character locale support should be no problem.

Aric Steward welcomed the help on this area of Wine. Aric also suggested to map some Windows font to their X11 counterparts (using the [fonts] section from the ~/.wine/config file), and suggested using the -isas-song ti- X11 fonts for this purpose.

Howard didn't like the proposal: -isas-song ti- is a GB font, which is used in Communist China (zh_CN). Taiwan and Hong Kong (zh_TW and zh_HK) uses big5 fonts *-big5-0 which is not included in the standard XFree86 distribution.

One thing that may be of interest. xselfont cannot display my Chinese fonts also (just blank on the sample text area), but mozilla and windowmaker can use it without problem.

So further posts appeared, still meaning that the Chinese (including Taiwan and Hong Kong variants) needs some more work to be done.

Martin Pilka wrote: File ~/.wine/userdef.reg is quite mysterious to me. It seems it contains some keys from HKEY_LOCAL_MACHINE, HKEY_USERS/.DEFAULT, HKEY_USERS/%username%. HKEY_LOCAL_MACHINE is also contained in system.reg file, and HKEY_USERS/%username% in user.reg file. what is that duplicity good for? which value takes precedence?

Alexandre Julliard answered: userdef.reg is supposed to contain only HKEY_USERS/.Default; but it seems a typo crept it at some point that causes it to contain the whole registry.

Alexandre provided a one line patch to solve this. Martin confirmed it solved some issues. However, he continued Ok, I see. That patch helped a bit. However:

system.reg   --> HKEY_LOCAL_MACHINE
userdef.reg  --> HKEY_USERS/.DEFAULT
user.reg     --> HKEY_USERS/%username%

Where is the place for HKEY_USERS/Software/... key? My native windows registry contain one. I'm able to load it properly where it belongs, but after wine exit that key will end in userdef.reg file. Next time i run regedit (and load only from home registry) the key is under HKEY_USERS/.DEFAULT again, What is wrong.

Ove Kaaven answered:There shouldn't be such a thing. What kind of idiot program created that? The closest correct thing would be HKEY_CURRENT_USER/Software, which would map to HKEY_USERS/%username%/Software...

Juergend Schmied went further:The crapy program is the microsoft dialer. HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Telephony\HandoffPriorities

Think we can ignore this key safely.

Josh DuBois still struggling to let Wine run on PPC wrote: How closely is Wine tied to the ELF format? I've (finally! :-) ) got the apps in the programs/ dir running on linuxppc, so I tried to scoot the code over to OSX just to see what happened. Of course no dlopen on OSX ==> no compilation. OSX uses Mach-O binaries, rather than ELF. A dlopen() "equivalent" for Mach-O exists, but I've never called dlopen() in my life, so I'm not sure on what criterion to compare them. Does anyone know, broadly, what the hot spots will by trying to make wine use a different shared object format?

Ulrich Weigand answered: Well, Wine only needs the basic functionality of dlopen, dlclose, dlsym, which are rather equivalent to LoadLibrary, FreeLibrary, and GetProcAddress. Anything that allows some sort of run-time dynamic linking must really provide this functionality IMO... You should be able to implement the corresponding routines in library/port.c.

There might be some further dependencies to the ELF format, however: e.g. we rely on the fact that the .init and .fini sections can be used to implement global constructors / destructors. (This is not a feature of the ELF format, strictly speaking, but of the way ELF loading is done by the Linux toolchain and dynamic loader. OSX probably has something similar.)

David Goodenough did some testings with Wine 20010112 and tried the Windows 1.1.8 java runtime environments: The Sun one fails with the GetFastQueue16 error that I mentioned with the last drop. Does anyone know what needs to be done to build a default queue. I put in a suggestion last time but no one reacted to say whether it was the right approach. Also there was the question about how it should be deleted when the thread is cleared. The Windows SDK file I have does not seem to list GetFastQueue16, so I do not know what the rules are.

The IBM one just hangs. No errors, no GetFastQueue16 error, but a hard and solid loop. I will try to use trace to see what is happening.

Ulrich Weigand went on with some explanation: GetFastQueue16 is an undocumented kernel routine that is used in Win9x to implement the specification that all threads except the main thread by default don't have a message queue; when they call the first 'GUI' routine that requires a message queue, one will be created on the fly.

This is done by having every routine that needs to access the thread's message queue call GetFastQueue16 to retrieve the queue. If the queue is already present, it will be simply returned. If the thread doesn't yet own a queue, one will be created.

GetFastQueue16 only gives the warning message if it tried to create a message queue, but this failed for some reason. This is a situation that should never occur, really ...

In fact, the only situation I could understand GetFastQueue16 to fail would be if the application doesn't load the USER subsystem, so that the callout from KERNEL will not be present.

The callout mechanism provides a way for KERNEL DLL pair to call functions in USER even if dependencies between DLL would be the other way around. It's just a table of function pointer which are filled with the addresses of the needed USER functions when USER is loaded.

Ulrich then asked from some traces to shed some light. Gérard Patel continued the testing and confirmed Ulrich's thoughts: I did not include the trace as it's rather large but what happens is clear enough: the main exe loads implicitly KERNEL32 but not USER - USER is loaded implicitly by a DLL loaded by LoadLibrary.. So when the kernel initialization is done, USER is not yet loaded. It's unusual but seems perfectly valid IMO.

Ulrich answered: Hmmm. Strictly speaking, if an app dynamically loads USER, it can also dynamically unload USER; we'd have to take care that we invalidate the Callout pointers if this happens.

and provided a patch to fix the issue. Gérard confirmed this actually fixed the problem.