Graphics screens are not displayed in Windows 10 Japanese environment

[Makoto WATANABE]

This bug is a Microsoft Japan issue.
I have reported it to Microsoft Japan, but there is no prospect to be modified.
I would appreciate it if FreeBASIC could support it in the next version.

1. Phenomenon (fact)
In Windows10 Japanese environment, screens of "2D Drawing Functions" and "Screen Functions" program example of "FreeBASIC Manual" are not displayed.
Add the following at the beginning of the program to display the graphics screen.
(This code was given by fxm.)

Code: Select all

' Sets the graphics method GDI
SetEnviron("fbgfx=GDI")


2. Cause I imagined
Since English alphabet characters are simple, they are displayed beautifully with "GDI" ClearType, which uses only x-direction anti-aliasing.
However, Japanese characters have a large number of strokes, they are used DirectWrite of "DirectX" instead of "GDI" to improve the character display in both X and Y directions.
Due to this fundamental difference in display, I think we have to explicitly specify "fbgfx=GDI" in FreeBASIC.

P.S.
Dear Kuan Hsu;
Are graphics screens appear in Windows 10 Traditional Chinese environment?

[Makoto WATANABE]

I add the behavior of the programs on Windows10 Japanese.

The "Windows version" of "FBWiki:CompilerRequirements" has the following description.
"The gfx routines will use DirectX 5.0 or later if found on the host system, otherwise they'll fall back on standard Win32 GDI which will work on any Windows system."

Windows10 Japanese does not support FreeBASIC even though it has "DirectX 12".
This may be that DirectWrite for Japanese display is preventing FreeBASIC from connecting to DirectX.
Therefore, by explicitly specifying SetEnviron("fbgfx=GDI"), FreeBASIC can use GDI rather than DirectX for screen display.
(Of course, if I specify SetEnviron("fbgfx=DirectX") on Windows 10 Japanese, the screen is not displayed.)

The following are the differences in screen display between Windows 8.1 and Windows 10.

environment\FB code .... ||Unspecified ||fbgfx=DirectX ||fbgfx=GDI
---------------------------------------------------------------------------------------------
Windows8.1 Japanese ... ||displayed... ||displayed..... ||displayed
Windows10 English mode ||displayed... ||displayed..... ||displayed
Windows10 Japanese .... ||Don't show.. ||Don't show.... ||displayed

If FreeBASIC finds DirectX but decides that it cannot display the drawing screen, it would be nice if FreeBASIC could switch to GDI and display the screen.

[dodicat]

Here 64 bits fb is always GDI (UK)
So you only have to deal with 32 bits.
To do it with minimum code (including NOT loading fbgfx.bi)

Code: Select all


#if sizeof(integer)=4 '=32 bits
screencontrol (103, "GDI") 'set driver name to GDI
#endif


screen 19
dim as string s
screencontrol (9 ,s) 'get driver name
draw string(200,200), s
sleep

 

[fxm]

As I wrote above, the minimum code for me is this only line:
SetEnviron("fbgfx=GDI")
compatible with -lang qb and -lang fb (32/64-bit).

[adeyblue]

DirectX works on Windows 10 Home 64-bit Japanese here. This is the code in dodicat's post without the GDI line
https://prnt.sc/uzgiky

Without the DirectX fix for 64-bit, the same code works, just says GDI instead
https://prnt.sc/uzgwg6

[Makoto WATANABE]

Dear adeyblue

Thank you for taking the time to build a Japanese environment and test it.
Thanks for your exertion.
DirectX is displayed in your Japanese environment !

Unfortunately, I was not able to display DirectX on the following 7 computers that I can use.

Model.......... ||Windows10... ||DirectX(dxdiag)
-------------------------------------------------------------
ThinkPad E570 ||64 Home 1909 ||DirectX 12
T552............ ||64 Home 1909 ||DirectX 12
ASUS V241..... ||64 Home 2004 ||DirectX 12
ThinkPad L540 ||64 Pro... 1909 ||DirectX 12
GLM-15......... ||64 Pro... 1909 ||DirectX 12
T100TA......... ||32 Home 1909 ||DirectX 12
PIPO X9........ ||32 Home 1909 ||DirectX 12

It may be that my commonly installed app is intercepting FreeBASIC.
Or maybe my favorite settings (e.g. IME settings) or something else is affecting it.
It's strange.

[MrSwiss]

Hi Makoto,

try the latest builds of FBC 1.08.dev (WIP) from: German FreeBASIC site.
Currently last build: 2020-10-14 (WIN 32/64 and others).
They contain the latest GFX-drivers from: adeyblue, committed by coderJeff.
Please, give us feedback from those tests ...

[Makoto WATANABE]

Dear MrSwiss

Thank you for providing the WIP information.

I tried it, but sadly not only DirectX but also GDI SetEnviron ("fbgfx = GDI") did not show graphics screens.
I'm shedding tears ;-(

[MrSwiss]

I tried it, but sadly not only DirectX but also GDI SetEnviron ("fbgfx = GDI") did not show graphics screens.

This is unfortunately not precise enough explained to 'get the full picture'.
Is there none graphics 'window' at all, or is it simply 'empty'? (nothing printed)

Does the exaple you are testing run properly, when you change the 'language setting' to english?
Alternative:
Does it run with all 'Text' translated to japanese? (all string contents & literals)

Which TTFont (TT = true type) is set on your system as default?

Does below snippet run correctly? Which settings work/don't work?

Code: Select all

' GFX_Font-Test1.bas -- (c) 2020-10-16, MrSwiss
'
' compile: -s gui                       ' WIN only
'

' screen constants
Const As UShort scr_w = 800, scr_h = 600, _         ' change as needed
                mxw = scr_w - 1, mxh = scr_h - 1, _ ' don't touch (never change)
                clrd = 32, pgs = 2, sflg = 64       ' change not needed typically

' color constants (mainly self explaining)
Const As ULong  white  = &hFFFFFFFF, black  = &hFF000000, _
                dgray  = &hFF3F3F3F, mgray  = &hFF7F7F7F, _ ' d = dark | m = medium
                bgray  = &hFFBFBFBF, bred   = &hFFFF0000, _ ' b = bright   
                bgreen = &hFF00FF00, bblue  = &hFF0000FF, _
                yellow = &hFFFFFF00, orange = &hFFFF7F00, _
                violet = &hFF7F007F, cyan   = &hFF00FFFF, _
                pink   = &hFFFF00FF, transp = &h00FF00FF    ' pink | FB's magic pink

ScreenRes(scr_w, scr_h, clrd, pgs)      ' sflg not wanted here (all opaque)
ScreenSet(1, 0)                         ' working-/display-page
Color(black, white) : Cls               ' fore-/background colors
Width scr_w \ 8, scr_h \ 16             ' force: 8 x 16 Font size

For i As UInteger = 32 To 127
    If i = 127 Then
        Print WChr(i) : Exit For
    End If
    Print WChr(i); ", ";
Next

Print : Print : Print "... done ... ";
Flip                                    ' aka: pcopy (show it all)

Sleep

[Makoto WATANABE]

Dear MrSwiss
Thank you for committing to the drawing screen display in the Japanese environment.

Does TTFont mean the font on this screen?
It is "MS Gothic".



The screenshot of the result of MrSwiss' snippet is as follows.

1. English mode (This screen is displayed instantly.)



2. Japanese mode
(1) In most cases, this white window appears and then the window disappears immediately.


(2) Sometimes a white screen (no response) appears and after a while the window disappears.


(3) While I tried many times, only once did the same screen appear as the English screen.

[MrSwiss]

Hi Makoto,

seems it is a 'language setting' problem (by your results).
Nothing to do with FB but the combination of Language and Font used by language selected.
(Chinese, Japanese and Korean languages seem to all need Unicode capable Font(s) to run properly.)

I've found a windows setting (control panel) that you can try, as a sort of last resort.
It is located in 'Region' in the Tab 'Administrative' at the bottom half 'Language for non-Unicode programs'.
See what it currently says (to go back there if test is a failure), then switch to 'english' and repeat the tests.
Only use the latest 1.08.dev compiler for testing.

Apart from that I'm really running out of ideas ...
(The only conclusion concerning FB so far is, that the GFX-drivers are of no consequence here.)

[adeyblue]

(The only conclusion concerning FB so far is, that the GFX-drivers are of no consequence here.)

Except if the GFX window disappears, it means the GFX driver thread exited, whether it was told to or it crashed. And if it doesn't get to the Sleep, it probably crashed.
Plus if the window sometimes says not responding, that means the GFX driver thread is alive (since the window is still there) but hasn't pumped messages for at least five seconds (i.e. it's gotten stuck somewhere) and a deadlock in the GFX drivers is a pretty serious problem.

Makoto, can you open Task Manager and go to the Processes tab (you may have to click More Details first), compile the code below and keep running it until it stops on the empty white screen or says Not Responding.
When it does, in Task Manager right click on the exe's entry and Create Dump File. It'll put it in your temp directory.
When that's done, if you could zip the dump file, the exe and any error.txt file together and upload it somewhere (there's https://www.filedropper.com if you don't have anywhere else)

Code: Select all

' GFX_Font-Test1.bas -- (c) 2020-10-16, MrSwiss
'' compile: -s gui                       ' WIN only
'
#include "windows.bi"
#include "crt/stdio.bi"

Function ExceptionHandler stdcall (pEp As PEXCEPTION_POINTERS) As Long

    ' Bypass FB file handling code because we don't want to try taking locks
    ' that might now be abandoned

    dim f as FILE ptr
    dim pEr as PEXCEPTION_RECORD = pEp->ExceptionRecord
    f = fopen("error.txt", "at")
    If f <> Null Then
        fprintf( _
           f, _
           "Caught exception of type %#x at %p\n", _
           pEr->ExceptionCode, pEr->ExceptionAddress _
        )
        fclose(f)
    End If

    Return 0

End Function

' screen constants
Const As UShort scr_w = 800, scr_h = 600, _         ' change as needed
                mxw = scr_w - 1, mxh = scr_h - 1, _ ' don't touch (never change)
                clrd = 32, pgs = 2, sflg = 64       ' change not needed typically

' color constants (mainly self explaining)
Const As ULong  white  = &hFFFFFFFF, black  = &hFF000000, _
                dgray  = &hFF3F3F3F, mgray  = &hFF7F7F7F, _ ' d = dark | m = medium
                bgray  = &hFFBFBFBF, bred   = &hFFFF0000, _ ' b = bright   
                bgreen = &hFF00FF00, bblue  = &hFF0000FF, _
                yellow = &hFFFFFF00, orange = &hFFFF7F00, _
                violet = &hFF7F007F, cyan   = &hFF00FFFF, _
                pink   = &hFFFF00FF, transp = &h00FF00FF    ' pink | FB's magic pink

AddVectoredExceptionHandler(1, @ExceptionHandler)

ScreenRes(scr_w, scr_h, clrd, pgs)      ' sflg not wanted here (all opaque)
ScreenSet(1, 0)                         ' working-/display-page
Color(black, white) : Cls               ' fore-/background colors
Width scr_w \ 8, scr_h \ 16             ' force: 8 x 16 Font size

For i As UInteger = 32 To 127
    If i = 127 Then
        Print WChr(i) : Exit For
    End If
    Print WChr(i); ", ";
Next

Print : Print : Print "... done ... ";
Flip                                    ' aka: pcopy (show it all)

Sleep


[Makoto WATANABE]

Dear adeyblue
Thank you for committing to this drawing screen display in the Japanese environment.

I sent the result of running the test program.
http://makoto-watanabe.main.jp/freebasic/GFX_Font-Test.ZIP

The file names with a description of 108 are FreeBASIC1.08 WIP and the one without are FreeBASIC1.071.

[MrSwiss]

Error numbers tested, as in the log files reported (the same both compiler versions!).
Pretty funny results obtained by using M$'s Err_6.4.5.exe tool:

Code: Select all

C:\DEV_TOOLS\util>Err_6.4.5 0x40010006
# for hex 0x40010006 / decimal 1073807366
  DBG_PRINTEXCEPTION_C                                           ntstatus.h
# Debugger printed exception on control C.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_RPC (0x1), Code 0x6
# for hex 0x6 / decimal 6
  ERROR_INVALID_HANDLE                                           winerror.h
# The handle is invalid.
# 2 matches found for "0x40010006"

C:\DEV_TOOLS\util>Err_6.4.5 0xc0000005
# for hex 0xc0000005 / decimal -1073741819
  ISCSI_ERR_SETUP_NETWORK_NODE                                   iscsilog.h
# Failed to setup initiator portal. Error status is given in
# the dump data.
  STATUS_ACCESS_VIOLATION                                        ntstatus.h
# The instruction at 0x%p referenced memory at 0x%p. The
# memory could not be %s.
  USBD_STATUS_DEV_NOT_RESPONDING                                 usb.h
# as an HRESULT: Severity: FAILURE (1), FACILITY_NONE (0x0), Code 0x5
# for hex 0x5 / decimal 5
  WINBIO_FP_TOO_FAST                                             winbio_err.h
# Move your finger more slowly on the fingerprint reader.
# as an HRESULT: Severity: FAILURE (1), FACILITY_NULL (0x0), Code 0x5
  ERROR_ACCESS_DENIED                                            winerror.h
# Access is denied.
# 5 matches found for "0xc0000005"

C:\DEV_TOOLS\util>

[adeyblue]

Dear adeyblue
Thank you for committing to this drawing screen display in the Japanese environment.

I sent the result of running the test program.
http://makoto-watanabe.main.jp/freebasic/GFX_Font-Test.ZIP

The file names with a description of 108 are FreeBASIC1.08 WIP and the one without are FreeBASIC1.071.

Thanks. It looks like the crashes are happening because the Microsoft Office IME? (something involved with IMEs anyway) causes some messages to pumped on window creation. As the drivers create the windows visibly, pumping messages causes a draw message to happen. Unfortunately, since the DirectX driver creates the things it needs /after/ it creates the window, if it gets a draw message before window creation finishes, all the things it needs to draw haven't been made yet and it crashes.

Normally this is fine because no messages are pumped and no draw messages are generated until after everything has been created. This is probably why its fine in English mode, since I guess that doesn't use this specific IME stuff (I don't know, I can't read Japanese, I just know which buttons to press to install Windows 10).

It seems like the crash could be fixed by just creating the windows invisibly then making it visible when everything has been created but I don't know if DirectX needs it to be visible when its' stuff is created. I'll see if I can fix it.