vdos.2020.03.01 can run under win10 but 2022.05.01 can't

[Jos]

Getting somewhere...
I'll send you a third vDos.exe to log the DOS_SetupTables routine(s).

Jos

[atis]

Third exe log:
vDos 2022.xx.xx
CodePage: 852
IDLELOW set at 12345
DOS_Init
DOS_SetupTables
dos_infoblock.Init
startPt: 726
startPt: 72a
sftOffset: 7cc
DOS_SDA.Init
pt: 820-26
SetupTables1
absAddr: c4000
absAddr: c41a0
absAddr: c4330
absAddr: c4430
country_info: 2ca510
cbID: 20

[Jos]

That is quite unexpected: "cbID: 20" comes from the end of the offending routine, and shouldn’t be reached at all.
Almost seems like the CPU stack would be mangled, causing vDos to return to some random address.

I have to send you a fourth vDos.exe that checks the return address of the routine.

Jos

[atis]

vDos log:
vDos 2022.xx.xx
CodePage: 852
IDLELOW set at 12345
DOS_Init
DOS_SetupDevices
RetAddr: e3e9d9
DOS_SetupTables
dos_infoblock.Init
startPt: 726
startPt: 72a
sftOffset: 7cc
DOS_SDA.Init
pt: 820-26
SetupTables1
absAddr: c4000
absAddr: c41a0
absAddr: c4330
absAddr: c4430
country_info: e8a510-e7f098
cbID: 20
RetAddr: e30000

[Jos]

Closing in. The last reported return address of 3e0000 is obviously incorrect. The low order word overwritten with 0.
You get a new vDos.exe reporting the return address at more instructions along the routine.

Jos

[atis]

Log:
vDos 2022.xx.xx
CodePage: 852
IDLELOW set at 12345
DOS_Init
DOS_SetupDevices
RetAddr: 17e9d9
DOS_SetupTables
RetAddr: 17e9e8
dos_infoblock.Init
startPt: 726
startPt: 72a
sftOffset: 7cc
RetAddr: 17e9e8
DOS_SDA.Init
pt: 820-26
RetAddr: 17e9e8
SetupTables1
RetAddr: 17e9e8
absAddr: c4000
RetAddr: 17e9e8
absAddr: c41a0
RetAddr: 17e9e8
RetAddr: 17e9e8
absAddr: c4330
RetAddr: 17e9e8
absAddr: c4430
RetAddr: 170000
country_info: 1ca510-1bf098
RetAddr: 170000
cbID: 20
RetAddr: 170000

[Jos]

Thanks for your patience, I surely wouldn’t have found the cause on my own.

As of version 2022.05.01 vDos uses the MS recommended GetLocaleInfoW() API function instead of GetLocaleInfo() to retrieve how dates are to be formatted, and the decimal, thousand, date and time separators.
GetLocaleInfoW() always expects to store the result in a wchar_t (2 bytes) buffer of a given length. While GetLocaleInfo() by default expected a char (1 byte) buffer.
The provided buffer (local on the stack) was 4 bytes, given length 4. Should still work for the 1 character separators, a zero is appended, resulting in 2 or 4 bytes.
But one of the four separators apparently gives a 2 character result (?).

I’ll send again a vDos.exe to test. And if correct, remove the added tests.

Jos

[atis]

You found the problem , vDos working now. Problem solved.
Log:
vDos 2022.xx.xx
CodePage: 852
IDLELOW set at 12345
DOS_Init
DOS_SetupDevices
RetAddr: 28e9d9
DOS_SetupTables
RetAddr: 28e9e8
dos_infoblock.Init
startPt: 726
startPt: 72a
sftOffset: 7cc
RetAddr: 28e9e8
DOS_SDA.Init
pt: 820-26
RetAddr: 28e9e8
SetupTables1
RetAddr: 28e9e8
absAddr: c4000
RetAddr: 28e9e8
absAddr: c41a0
RetAddr: 28e9e8
RetAddr: 28e9e8
absAddr: c4330
RetAddr: 28e9e8
absAddr: c4430
RetAddr: 28e9e8
country_info: 2da510-2cf098
RetAddr: 28e9e8
cbID: 20
RetAddr: 28e9e8
DOS_SetupMemory
RetAddr: 28e9f7
C: => (Local) c:\vDos\
XMS_Init
EMS_Init
SHELL_Init

3.54 LOADEXEC: DP26YI.EXE /s
4.02 Delayed logging, set w/o DOS call:
INT 1B => 2962:0004
4.53 FINDFIRST failed: DP{S0001.TMP(18)
OPENFILE failed: DPTEST\DP{S0001.TMP(2) => c:\vDos\DPTEST\DP{S0001.TMP(2)
FINDFIRST failed: DP{T0001.TMP(18)
OPENFILE failed: DPTEST\DP{T0001.TMP(2) => c:\vDos\DPTEST\DP{T0001.TMP(2)
FINDFIRST failed: DP{I0001.TMP(18)
OPENFILE failed: DPTEST\DP{I0001.TMP(2) => c:\vDos\DPTEST\DP{I0001.TMP(2)
6.14 Record locking verified for DOS C:
12.06 Delayed logging, set w/o DOS call:
INT 1B => original
14.16 vDos ended by EXIT (0)

[emendelson]

It looks as if the Hungarian date separator MAY now be a period followed by a space - two bytes. At least that's what seems to be described here for Java:

community.oracle.com/tech/developers/discussion/4074048/hungarian-date-format-changed

[guidol]

Dec 1, 2022 14:15:57 GMT 1 Jos said:

Strange, I tested with codepage 852. No problems.

Only to narrow down where vDos seemingly stalls or quits:
Add the line IDLELOW=12345 to config.txt, and see if the log contains IDLELOW set at 12345.

Jos

Hi Jos,
today I did also test the version 2022.05.01 from the webpage and it also closes directly after the start for me.
The former version I had running here - for personal useage - was 2021.05.01



         vDos 2022.05.01
    0.01 CodePage: 850
         IDLELOW set at 12345

Maybe you didnt uploaded the corrected version to the webpage?




[Jos]

I missed atis’ confirmation the fix worked.

vDosSetup.exe is patched accordingly.

Jos

[guidol]

Dec 10, 2022 19:30:34 GMT 1 Jos said:

I missed atis ’ confirmation the fix worked.
vDosSetup.exe is patched accordingly.
Jos

Ok   I can confirm - also for me - its now working/starting fine.
Many Thanks for the quick reply.
Guido

[micros]

I can also confirm that this version runs fine for me!

I found only one small problem compared to the 2021 version, and this is the capital letter "Ó" CHAR(224) used in the Hungarian language does not work on the Hungarian keyboard layout in the 2022 version of VDos.

Thank you very much!

[Jos]

ASCII 224 (Hex E0) has a special meaning in the BIOS, the lead-in for an extended key combination.
Version 2021 translated that to ALT+(KeyPad)224. For whatever reason I commented that out.
I reinstated it for the next version, hopefully to find out in time why it was commented out…

Jos

[fnavarro]

Dec 14, 2022 18:16:50 GMT 1 Jos said:

hopefully to find out in time why it was commented out…

FWIW may this post has that answer or was something even before that?

vdos.proboards.com/thread/590/keys-work-codepage-866