WPS 3.0 For DOS unabled to show the Chinese input method toolbar.

[happymimimix]

As described, the Chinese input method toolbar that supposed to appear on the bottom of the screen is not showing.
Please fix this, if possible?

Also I would like to ask if using Tame DOS on Windows 10 22H2 would be possible? If yes, how?

[happymimimix]

WPS_v3.0_CD.zip

Here is the installer, if you need it.

[leecher1337]

Weird, the program uses SVGA mode 12h (640x480x16).
With SVGATEST, the mode shows just fine:

However in WPS 3.0, lower part of video memory seems to be blanked. I wonder why...

[leecher1337]

It seems to me that the problem is related to the video memory layout as specified by the Memory Map Select MISC-Register:

Works (SVGATEST sample above):

yoda> dump_EGA_CPU
rame=1 wmode=0 rot=0 s/r=0000 s/re=0000 sr=0 func=0 bp=0 pe=1
EGA memory is 0xa0000->0xaffff plane offset is 0x8101000
set/reset value: 0 sr_nmask: 0xffffffff sr_masked_val: 0
bit_prot=0xffffffff,data_and=0xffffffff,data_xor=0,latch_xor=0xffffffff
handlers are of type 0

Cuts off Video memory (WPS 3.0):

yoda> dump_EGA_CPU
rame=1 wmode=0 rot=0 s/r=0000 s/re=0000 sr=0 func=0 bp=0 pe=0
EGA memory is 0xa0000->0xbffff plane offset is 0x8101000
set/reset value: 0 sr_nmask: 0xffffffff sr_masked_val: 0
bit_prot=0xffffffff,data_and=0xffffffff,data_xor=0,latch_xor=0xffffffff
handlers are of type 0

I wonder if this a bug in the original CVIDC or just in my reconstruction, hmmm...

[leecher1337]

Looking at the SPDOS.COM (Super Chinese System), which causes the switch to the wrong memory area, we can see:

seg000:9E7A                 test    al, 8
seg000:9E7C                 jz      short loc_19E77
seg000:9E7E                 mov     dx, 3CEh
seg000:9E81                 mov     al, 6
seg000:9E83                 out     dx, al          ; EGA: graph 1 and 2 addr reg:
seg000:9E83                                         ; miscellaneous graphics control.Data bits:
seg000:9E83                                         ; 0: 1=graphics; 0=enable char gen (text)
seg000:9E83                                         ; 1: 1=chain odd maps after even maps
seg000:9E83                                         ; 2: memory mapping for CPU
seg000:9E83                                         ;    00=a000H (128K);   01=a000H (64K)
seg000:9E83                                         ;    10=b000H (32K MDA);11=b800H (32K CGA)
seg000:9E84                 inc     dx
seg000:9E85                 mov     al, 1
seg000:9E87                 out     dx, al          ; EGA port: graphics controller data register

So by writing the value 1 to the Port, it sets the "Memory Map Select" to 00 and therefore causes a wrong memory area to be selected, as Mode 12h, which the application is in, should always be 01 (just the 64kb area is used to draw the planes).
The NTVDM VGA emulation doesn't like this at all when there is a wrong memory area selected.
I wonder why SPDOS.COM does this?

You could patch spdos.com to make a mov al, 5 instead of a mov al, 1 and it should work.
As long as it's not known why spdos.com does it, there is also no point in patching ntvdm, as the purpose of the change in the memory map is still unknown.

[leecher1337]

This article states that the behaviour of memory maping mode 0 is not really defined:

Note that there's one value, 00b, that maps the entire A0000h-BFFFFh
range to video memory. Unfortunately, what happens when you access memory
in the region B0000h-BFFFFh with this value selected doesn't seem to be
well defined in actual hardware.

One possible implementation is that access to B0000h-BFFFFh simply wraps
around to A0000h-BFFFFh, that is, CPU address bit 16 (A16) is simply
ingored by the VGA card. So a write to address B8000h (and A8000h) would
map to VGA address 8000h, right in the middle of mode 13h frame buffer.
The other is that the A16 bit is decoded and allows access to SuperVGA
memory (> 256kb). So a write to address B8000h would map to SVGA address
18000h, which is outside the mode 13h frame buffer.

Therefore it may be the best solution to just ignore this mode alltogether in the VGA emulation.

[happymimimix]

Looking at the SPDOS.COM (Super Chinese System), which causes the switch to the wrong memory area, we can see:

seg000:9E7A                 test    al, 8
seg000:9E7C                 jz      short loc_19E77
seg000:9E7E                 mov     dx, 3CEh
seg000:9E81                 mov     al, 6
seg000:9E83                 out     dx, al          ; EGA: graph 1 and 2 addr reg:
seg000:9E83                                         ; miscellaneous graphics control.Data bits:
seg000:9E83                                         ; 0: 1=graphics; 0=enable char gen (text)
seg000:9E83                                         ; 1: 1=chain odd maps after even maps
seg000:9E83                                         ; 2: memory mapping for CPU
seg000:9E83                                         ;    00=a000H (128K);   01=a000H (64K)
seg000:9E83                                         ;    10=b000H (32K MDA);11=b800H (32K CGA)
seg000:9E84                 inc     dx
seg000:9E85                 mov     al, 1
seg000:9E87                 out     dx, al          ; EGA port: graphics controller data register

So by writing the value 1 to the Port, it sets the "Memory Map Select" to 00 and therefore causes a wrong memory area to be selected, as Mode 12h, which the application is in, should always be 01 (just the 64kb area is used to draw the planes). The NTVDM VGA emulation doesn't like this at all when there is a wrong memory area selected. I wonder why SPDOS.COM does this?

You could patch spdos.com to make a mov al, 5 instead of a mov al, 1 and it should work. As long as it's not known why spdos.com does it, there is also no point in patching ntvdm, as the purpose of the change in the memory map is still unknown.

WOW! You are really a pro at reverse engineering!
This is insane.
Would you like to join the development of one of my projects?
The aim is to make an operating system with the crazy compatibility and easy to use of windows, at the same time the freedom of Linux. aka Lindows!
But I'm having troubles removing some of the stupid limitations in Windows such as the checksum verification of winload.exe and ntoskrnl.exe. Also the signature verification and all sorts of integrity checks of some of the critical system components.
Again, I don't mind reverse engineering and patching any of the system files. In fact, this is how the whole project is going to work. I just want to bring the freedom that every Windows user supposed to have back no matther what absurd methods we use.
Such as I used a symbolic link that points to C:\System Volume Information to hack the writing limitation to that folder.

Add me on discord if you are interested.
My username: happy_mimimix.