Hi.
I've tried out the new release and run into an issue.
In the previous release a program I run works fine but in the new one it just freezes up and never gets back to the command prompt but I can shut vdos down from the close icon in the top right.
The program is Btrieve.exe which is a TSR database program.
If you need any further info I'm obviously happy to help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That’s strange; I myself still use only one DOS program, that also uses the Btrieve database manager.
I wanted to add the Btrieve version number, started Btrieve on its own. Behold, it stalled also!
It is “Btrieve/N Record Manager Version 5.10a”, and works fine with “btrieve /f:40 /b:12 /u:8 /m:48 /e /c /o”. I have to look into why it doesn’t w/o parameters. Will be one (?) missing, and I suspect causing Btrieve to locate its internal stack in upper memory…
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It was Btrieve setting its stack to expanded memory (I also meant that, not upper memory); vDos doesn’t expect program code or a stack segment in there. It saves testing where memory is supposed to be (no relocating with a speed gain).
A temporary quick and dirty modification/test seemed to do it. I then noticed a CPU exception was raised in both (!) versions, caused by an illegal IRET instruction. That puzzles me, seemingly Btrieve/vDos recovers from that, but can you confirm Btrieve ran fine with 2017.08.01 and eventually with what parameters.
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It was of course the /e option (don’t use expanded memory) that made the difference.
If a program locates its stack segment in expanded memory, and accesses the stack by both the
SS register and another segment register, the memory locations could get mixed up.
I did a silent update of vDosSetup.exe; it solves this issue (only detected with Btrieve TSR), as a result vDos is a bit slower. Also two other rather exotic issues are fixed.
Jos
Last edit: Jos Schaars 2018-05-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi.
I've tried out the new release and run into an issue.
In the previous release a program I run works fine but in the new one it just freezes up and never gets back to the command prompt but I can shut vdos down from the close icon in the top right.
The program is Btrieve.exe which is a TSR database program.
If you need any further info I'm obviously happy to help.
That’s strange; I myself still use only one DOS program, that also uses the Btrieve database manager.
I wanted to add the Btrieve version number, started Btrieve on its own. Behold, it stalled also!
It is “Btrieve/N Record Manager Version 5.10a”, and works fine with “btrieve /f:40 /b:12 /u:8 /m:48 /e /c /o”. I have to look into why it doesn’t w/o parameters. Will be one (?) missing, and I suspect causing Btrieve to locate its internal stack in upper memory…
Jos
It was Btrieve setting its stack to expanded memory (I also meant that, not upper memory); vDos doesn’t expect program code or a stack segment in there. It saves testing where memory is supposed to be (no relocating with a speed gain).
A temporary quick and dirty modification/test seemed to do it. I then noticed a CPU exception was raised in both (!) versions, caused by an illegal IRET instruction. That puzzles me, seemingly Btrieve/vDos recovers from that, but can you confirm Btrieve ran fine with 2017.08.01 and eventually with what parameters.
Jos
It is btrieve version 5.10a. It's being started with the command line:
btrieve /p:4096 /m:64 /f:32 /b:32
It works fine on vDos 2017.08.01 but ont he new version it didn't.
It was of course the /e option (don’t use expanded memory) that made the difference.
If a program locates its stack segment in expanded memory, and accesses the stack by both the
SS register and another segment register, the memory locations could get mixed up.
I did a silent update of vDosSetup.exe; it solves this issue (only detected with Btrieve TSR), as a result vDos is a bit slower. Also two other rather exotic issues are fixed.
Jos
Last edit: Jos Schaars 2018-05-07
I've had a chance to test this out and it works fine. Awesome!
Thanks.