[Bug 28861] Final Fantasy XI hangs after character selection

https://bugs.winehq.org/show_bug.cgi?id=28861

--- Comment #14 from Mike Tedder  ---
Ok, time to resurrect this bug and post my findings.

This bug is still reproducible with wine-1.7.28-107-g0eec97e, built on OSX
10.9.5, with a new install of FFXI (JP version) and all of the expansion packs
and updates into a fresh, clean WINEPREFIX.  It does not matter what the
Windows version is set to.  (I tried XP, Vista, and 7.)

During the black screen, I noticed a new log message I had not seen before:

err:ntdll:RtlpWaitForCriticalSection section 0x7bcab2ac "loader.c:
loader_section" wait timed out in thread 0041, blocked by 000b, retrying (60
sec)

This message is repeated every 60 seconds until I kill the pol.exe process.

Thanks to Chiitoo's findings however, I can confirm that removing those two
lines from ImmGetContext() fixes this issue:

diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c
index 2fa31ac..b3e9277 100644
--- a/dlls/imm32/imm.c
+++ b/dlls/imm32/imm.c
@@ -1424,8 +1424,6 @@ HIMC WINAPI ImmGetContext(HWND hWnd)
     rc = GetPropW(hWnd,szwWineIMCProperty);
     if (rc == (HIMC)-1)
         rc = NULL;
-    else if (rc == NULL)
-        rc = IMM_GetThreadData()->defaultContext;

if (rc)
     {

I also noticed two other minor issues this fixes:

1) After clicking on the SquareEnix password box (at the PlayOnline login
screen) and the on-screen keyboard pops up, it is possible to simply type in
one's password at that point on Windows, and with this patch.  Without the
patch, the keyboard focus doesn't seem to be correct, and the password cannot
be entered without first clicking on the password input box inside the pop-up
window.

2) After starting FFXI and getting to the main menu (before selecting a
character), attempting to return to the PlayOnline viewer simply results in a
hang with a black screen, with the same log message as above every 60 seconds. 
The above patch also fixes this issue.

It looks like commit b72dcd114d1c622b3046506563cc91fc38d40835 way back in 2008
updated the IMM code to store a context per thread using TLS.

What strikes me as odd though is if a context doesn't exist in the thread's
local storage, one is automatically created regardless (lines 1421-1422).  This
created context is then returned to the application, however ImmGetContext()
should return NULL if the window handle isn't owned by the process.

That might be what the -1 return result is from GetPropW(), but I'll have to
debug this a bit to make a better guess.

If anything, I would propose that a context isn't generated unless the window
handle is valid.  I'll hack at this a bit and see if I can't find a solid patch
for it.