Opened 7 years ago

Closed 7 years ago

#24 closed defect (fixed)

Input of umlauts (å, ä , ö) sometimes does not work

Reported by: dmik Owned by:
Priority: blocker Milestone:
Component: odin Version:
Severity: Keywords:


A user reports ( that he cannot enter umlauts with the recent Odin release under some circumstances.

This is clearly a regression of r21529.

Change History (7)

comment:1 Changed 7 years ago by dmik

There are actually two problems that reappeared after r21529 (i.e. Odin release 2010-12-30):

  1. Entering umlauts (and other national characters) gets broken in Firefox once the Flash 10 plugin gets activated. (The original problem of melf).
  1. Umlauts (and other national characters) are incorrectly shown in the window title of OpenJDK6 Beta and Win32 applications run under Odin. (The problem found by Silvan).

comment:2 Changed 7 years ago by dmik

Tracking it down reveals that both problems showed up because I changed the USER32 initialization code (InitPM()) so that it switches the main thread to the Windows ANSI codepage (cp1252 for Latin countries).

In case of Flash, this means that the Firefox main thread gets unexpectedly switched from the OS/2 codepage to the Windows ANSI codepage (cp850->cp1252 for Latin countries) once the Flash plugin gets loaded and drags USER32.DLL in. This completely confuses Firefox which still assumes it gets input in cp850. Hence, the invalid character translation. I will avoid switching the main thread's codepage in such a case; the rest of my code in r21529 expects this situation and will still work correctly.

In case of Window titles, it seems that the SetWindowText?() implementation in Odin unconditionally assumes that the window thread is in the OS/2 codepage and therefore when it gets actual input in the Windows ANSI codepage it performs a wrong conversion. This is also proven by the fact that rolling back r21529 only fixes windows created on the main thread; windows of other threads (e.g. *all* Java windows) still remain broken (and I actually remember the very same problem with Innotek Java). The proper fix here is keep r21259 and fix SetWindowText?() instead.

comment:3 Changed 7 years ago by dmik

Small addition. All Java windows are broken because Java creates all GUI windows on additional threads and because Odin has been always switching all additional threads to the Windows ANSI codepage even before r21529.

comment:4 Changed 7 years ago by dmik

Issue 1 is fixed in r21543. I had to disable the main thread's code page switch since there is no good way to detect if it's us who initializes it (i.e. a normal Windows/Odin? executable) or it's a foreign non-Odin thread (e.g. Firefox). After all, the code will still perform the correct conversion of WM_CHAR messages from the OS/2 to ANSI code page when needed. This additional footprint for the main thread is not that critical (it's the user input).

comment:5 Changed 7 years ago by dmik

Issue 2 is fixed in r21544.

The new user32.dll with both issues fixed is available as Please check and report the results.

comment:6 Changed 7 years ago by diver

ok i testet all 3 cases. java, odin app and flash. i did not see any wrong characters.

comment:7 Changed 7 years ago by dmik

  • Resolution set to fixed
  • Status changed from new to closed

Good. Closing.

Note: See TracTickets for help on using tickets.