Topic: Simutrans GDI cannot run on Windows 10 1809 ?

[z9999+]

I updated Windows 10 on my two PCs to 1809.
Simutrans SDL version run without problem, but Simutrans GDI version quits after opening its window. I tried on both PCs and the same result.

Does this problem happen only to me ?
Does anyone success to run Simutrans GDI version on Windows 10 1809 ?

[DrSuperGood]

Does anyone success to run Simutrans GDI version on Windows 10 1809 ?

I use 1803 and have no problems running Simutrans GDI, both from the official download and from MSVC self-built and both in windowed and fullscreen mode.

1809 is either an early preview build or you are just one of those people Microsoft decided to randomly give a more up to date version to (they stagger rollouts). As such it cannot be ruled out that this is a Windows 10 version specific issue. If/when I update to at least 1809 and this problem manifests I will debug it.

[Ters]

I suspect 1809 means the version of Windows released in September 2018. Due to staggered rollouts, it will take about a month for everyone to get it. I have 1803, which I think I got in April.

(This means that there is a PC-less day for me in the near future. These bi-yearly Windows updates take an insanely long time to install.)

[DrSuperGood]

I do not see any reason why 1809 should be breaking GDI.

Have you tried restarting (not shutdown as that does something different) your computer? There are some rough references to GDI having a handle limit so maybe some other application leaked enough GDI objects that the OS is depleted of them, if that even makes sense.

[Ters]

GDI handles are supposed to be per process in Win32. That GDI and USER handles are limited to 16k (or maybe 32k) each only apply to 16 and 32-bit Windowses (the latter due to compatibility with the former).

The strange thing is that Simutrans supposedly just drops dead without any error messages. Crashes usually come with some error message.

[DrSuperGood]

Crashes usually come with some error message.

Not really... Encountered these a lot with Simutrans Extended. For example the most recent one was a NULL dereference.

[Ters]

This is strange. I just tried to create a program that did just that, and although it is marked as a GUI application, the error message is printed to stdout/stderr rather than pop up a crash dialog like Windows has done since at least Windows 3.1. Why has it suddenly been decided that users do not deserve to know why the OS terminates their programs, or even that it has? One thing was that they removed all the technical stuff from the dialog box a while back. The error is still logged in Windows' Program event log, for what it's worth. (And I wonder if anyone at Microsoft is looking at the error report apparently being automatically sent by Windows Error Reporting.)


Edit: Looks like it is MSYS2/bash that is printing the error message, regardless of whether the program was compiled with its GCC or Microsoft's compiler. I'm not sure how it knows what happened.

[DrSuperGood]

The change is likely due to Windows trying to push better data gathering such as used by Google Store and such. One can specify that published store applications collect the error reports in the cloud so they can be reviewed at a later time. Additionally all that tech mubo jumbo that popped up when someone's favourite program crashed probably caused too many IT illiterate kids to suffer mental breakdowns at the sight of such nerd stuff that it just had to go!

I do not think anything stops one from writing a custom fatal error handler which could create a log file or a popup of sorts. I think that was kind of the intention by the change as well, programmers actually have to think how their program should handle crashes more than "let the OS deal with it and hope the user is vaguely IT literate".

[Ters]

Actually, after doing lots of searches trying to figure out why things changed, it seems more like it was IT administrators that pushed for the removal of the dialog because it caused their automated scripts to stop in the middle waiting for them to dismiss the dialog when one of the steps crashed. Almost every search I try only brings up load and loads of questions on how to disable that dialog. The registry key mentioned in at least some of them does not even exist on my system. However, a consent setting for Windows Error Reporting was set to send all data always. I've tried setting it to always ask, if only to stop pestering Microsoft with my experiments, although I may have to restart my computer (or perhaps some service) for it to take effect. (My experiments have also caused my system's reliability index to drop significantly.)

I'm not so sure Microsoft expects developers to make their own error handlers, because they seem to have realized that developers in general can't be expected to do anything right. And I suspect that error handlers are more tricky to write than most code, as you can not expect any other part of the application to be in a working state.

[Frank]

german Windows 10 1809 and Simutrans 120.4.1 GDI works

[z9999+]

german Windows 10 1809 and Simutrans 120.4.1 GDI works

Thank you. That is very useful information.

Ok first, I tried to install English language pak in my Windows 10.
Second, I switched input language to English with [Win+Space] keys.
Third, start Simutrans GDI.

Yes, this works. Simutrans GDI starts without problem. But when I chang back input language to Japanese, Simutrans GDI quits.
I tested and this problem affects all of Simutrans GDI versions, 99-17-1, 100-0, ... 120-4-1.

I remember some of Steam games have this kind of problem. When we use Japanese for input language, the game doesn't start or causes random crash while playing the game.

Unfortunately I don't know how to fix this problem but a big clue.
Thank you anyway.

[Ters]

So there is apparently something wrong with how Simutrans interacts with the IME, or Microsoft has screwed up on their side. Some sites listing changes in Windows 1809 do mention changes to IME, although not in any detail. If SDL is using the same underlying API, that would suggest an error in Simutrans' Windows backend (although not technically involving GDI). Since a developer needs not only Windows 1809 to look into this, but also some experience with Japanese or something requiring similar input methods, this might take a while.

[Ters]

Now even longer, since Microsoft has stopped rollout of 1809 because it for some reasons apparently likes to delete a lot of documents.

[prissi]

Simutrans SDL version is the SDL2 version and should also support IME, so it cannot be the IME alone. However, it seems SDL2 leave the IME handling more or less alone.

I did in the SDL2 code (very deep), and the biggest difference is that SDL2 totally ignores WM_IME_SETCONTEXT messages, and never send them onward from the procedure. (Although it might still happen, if it is called inside a modal handler (bcause of returnurn zero), but I am not sure of the status of the SDL2 window at that time.)

Probably one has to return 1 on WM_IME_SETCONTEXT or never call DefWindowsProc like SDL2 ... It seems to work without this call. Check r8606 please.

[z9999+]

Thank you. I tried r8606 but it still quits.

And the last message in simu.log is ...

Code: [Select]

Message: simmain: simgraph_init disp_width=704, disp_height=560, fullscreen=0

So, problem might be happened while initializing graphics.
Sorry for confusing, but this doesn't need to hurry, it is ok after someone confirmed the problem.

[prissi]

This is when the window is openend and recieves its first "WM_IME_SETCONTEXT" message. Thus I suspected the code, and changed current code to the same as the SDL2 code. Maybe I need different window attributes. However, I lack a computer with windows 10 1809 for further testing.

[z9999+]

Now Microsoft released 1809 again. This is the note for how to reproduce the problem.

How to confirm this problem.
1. Add Japanese language to your user account. (*1)
2. Confirm that "Use different method for each app window" option is disabled. (*2)
3. Start File Explorer and open Simutrans folder.
4. Press [Win]+[Space] key and select Japanese input.
5. Double click on Simutrans.exe icon and start Simutrans.

(*1) How to add Japanese language to your user account.
1. Open "Settings" App and click "Time & Language".
2. Click "Language" tab.
3. Click "Add a language" and select Japanese.
4. Click "Next" and disable "Set as my Windows display language".
5. Click "Install".

(*2) How to confirm that "Use different method for each app window" option is disabled.
1. Open "Settings" App and click "Time & Language".
2. Click "Language" tab and click "Spelling, typing, & keyboard settings" on right pain.
3. Click "Advanced keyboard settings".
4. Disable "Let me use a different method for each app window" option.

If this option is enabled, Simutrans will always start with your default language. So problem doesn't happen to you.

[prissi]

Sorry, does this mean the nightly still crashes for you?

[Ters]

I hope this was just one of the errors in 1809 and that Microsoft has managed to fix it by now.

[z9999+]

Sorry, does this mean the nightly still crashes for you?

Yes, r8633 still quits.

I hope this was just one of the errors in 1809 and that Microsoft has managed to fix it by now.

Yes, this is the Windows' bug but they never fix this kind of minor problem.
Simutrans needs workaround.

[Ters]

To try and narrow in what the problem is, a first workaround might be to disable all the IME related stuff. If that still crashes, I'm unsure what else there is to do.

[z9999+]

Debugger says ...

Code: [Select]

write access violation
AllDib was nullptr

simsys_w.cc:618
AllDib->bmiHeader.biHeight = (WindowSize.bottom*32)/y_scale;
I hope this helps.

[EDIT]

Code: [Select]

182 if(  fullscreen  ) {
183 create_window(WS_EX_TOPMOST, WS_POPUP, 0, 0, MaxSize.right, MaxSize.bottom);
184 }
185 else {
186 create_window(0, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, MaxSize.right, MaxSize.bottom);
187 }
188
189 WindowSize.right  = MaxSize.right;
190 WindowSize.bottom = MaxSize.bottom;
191
192 AllDib = MALLOCF(BITMAPINFO, bmiColors, 3);
I set breakpoint at 186 and 189.
After stopped at 186, I clicked "continue", then program called WindowProc() before 189. And AllDib was NULL pointer.

But if I click "step in", program go to 189. And Simutrans start without problem.

[Ters]

So Windows has started sending WM_PAINT messages before CreateWindow returns now? It would surprise me if Simutrans was the only program caught of guard by that. The documentation is quite detailed on when WM_PAINT is sent, and the cases are very restricted.

[DrSuperGood]

I am guessing the WM_PAINT message is being generated by the IME in response to windows creation.

Since context has not yet been created I think the simplest solution is to add a check for NULL inside WM_PAINT. It is technically slower but can be considered trivial and is likely required so that IMEs work correctly. If one wants speed one can use the SDL2 backend.

I will commit this change for testing if the issue is fixed.

[Ters]

I am guessing the WM_PAINT message is being generated by the IME in response to windows creation.

That is my guess, too.

Since context has not yet been created I think the simplest solution is to add a check for NULL inside WM_PAINT. It is technically slower but can be considered trivial and is likely required so that IMEs work correctly.

That was one of my two ideas. The other was to simply set up the DIB before creating the window. Checking for null first anyway just to verify the diagnosis is however a good idea.

[z9999+]

Thank you. r8634 works for me. 

I downloaded Google Japanese IME and switched to it. Then problem didn't happen.
So, MS-IME is the reason.