Problem with Dbx database editor

[micros]

Hy Jos!


A few days ago, I noticed an operating error in the latest VDos version (2018.05.01).

DBX.EXE database editor (written in Clipper 5.01) does not start VDos 2018.05, but freezes the entire VDos.


In previous versions of VDos (2016.10.01), there was no such problem.

I attach a program to the post.


Best regards,

Micros

[Jos]

The most frequent used routine in vDos is that fetching the (next) CPU instruction to be executed.

Before version 2018.05.01 vDos tested if the code was eventually located in EMS, and if so, addressed EMS, not physical memory. Version 2018.05.01 introduced a shortcut to speedup loading that code: It didn’t consider program code to be located in EMS. That saves a test (and so conditional jumping) for every fetch operation. So code was simply supposed not to be executed in EMS.

That only created an issue with the Btrieve TSR, doing a far call to code in EMS. To remedy, vDos traps that far call and does a onetime copy of the current EMS pages to the physical memory segments (0xE000-0xEFFF). DBX however doesn’t a far call, but a far jump. Second, it also frequently replaces/swaps the code in EMS after the first far jump. To remedy that, every far jump into EMS has to be preceded by a copy of the current EMS pages.

For now, you can’t use vDos 2018.05.01 with DBX since jumping to code in EMS will result in executing bogus code.

Jos

[lohen]

Hi Jos,

Could this also explain why the Clipper Referral demo of my _o_ceans project falters under 2018.05.01? I haven't really looked further into the issue, reported back in may, but as far as i evaluated, in this case linking along the FlexFile library (for an fpt replacement of memo files) seems to be the culprit (all other demos work alright under 2018.05.01). My latest update (as of yesterday) to my project (for vDos) corrects Windows clipboard pasting (now at normal speed, and not limited to 15 characters, rather up to Clipper's maximum for the string type (around 64000)), but i recommend using the former vDos version (2017.08.01 silent update ?2017.09.16) until this issue is solved.

For anyone interested how Clipper Windows clipboard pasting was solved, i'm glad to share what seems to work (a re-linking-only fix) .oO just ask here

Thanks in advance,

Frank

[Jos]

Hi Frank,

Don’t think so, a program can switch to code at segment 0xE000 (normally translated to EMS) by a far CALL, far JMP, RETF, or IRET instruction. The first one is taken care of by copying the current EMS pages to physical memory. The last three not, the CPU would end up in all zero’s. Raising a CPU exception (invalid opcode). Even if the program provides for handling that, it would be most unlikely it would recover itself and continue normal functionality, though with a pause.

Jos

[Jos]

Update: The next version already had 2 exclusively running emulated cores, one with translating virtual to physical memory addresses (mainly FoxProX), the other without.

I added a third that doesn’t do optimistic Code and Stack segment assumptions. It’s triggered when a program jumps to code in EMS, or sets its Stack segment to that. Switching between cores is automatic, but the third one won’t switch back if possible to the some 30% faster first two.
Don’t think that will be really noticed for the few programs that triggers this core.

Jos

[lohen]

Hi Jos, if beta testing, specifically for my project's executables, is of any use, consider me candidating

Windows 7 Pro (32bit), Windows 10 Home (32bit) and Windows 10 Pro (64bit) are my test environments (XP also, but discontinued)

Best regards,

Frank

[Jos]

Thanks for your offer.
I already tested you DBX program and it works just fine.

Jos