Direct Access 5.19 DOS Menu System

[cnsvdosfan]

Hi,

First off - vDOS rocks, so thank you Jos & co.

I have to say vDOS does a truly magic job of allowing print to Windows printer (nice job)..... it has allowed another friend of mine to be able to ditch his old Dot Matrix and ancient PC and keep using his old DOS app, whilst still do printing but to modern A4 with pretty nice output - good one.


I'm hoping you can help, with an issue I've just not been able to resolve/figure out myself (not for lack of trying)...

I've been trying to get a Direct Access 5.19 DOS Menu system working under vDos (2021.05.01, and earlier versions)...

vDOS was opted for to get an Old timer off an ancient DOS PC, that we can't keep running much longer AND because he has been using Dot Matrix that we can't replace or get new ribbons for. To make matters worse, the chap is openly set in his ways and has been forced to close up his sole-trader business of > 30 years due to age/health issues so simply needs to keep working the way he has for a few months more.

Until now, on his ancient DOS PC, the Stock app, is accessed via the Direct Access Menu system so he is able to select and run either the Stock/Inventory system along or some other menu items to allow the him to be able to exit the app and select basic file copy scripts for backup/restore and so on.. Nothing complex...


His Stock app is primarily a pretty basic app and in itself works 100% under vDos, so if all else fails I may find myself having to have a Shortcut to vDOS and ONLY run up the Stock programme, whilst having other Desktop shortcuts (and you have no idea how hard that will be to sell to this person) that run his other menu tasks directly.

What's been happening is that the DA Menu system, when I select say Menu Item H (assuming it's defined) to perform say some program, it will perform the last action requested. Eg: If the last action was Exit i.e. F10, then selecting Item H will exit the menu, so then going back in, even selecting Exit, will then perform the action I previously requested before I was exited the last time....

This is causing huge confusion for the user, as they have to go in/out multiple times simply to get in/out of various menu selections....

For this same chap, I do have another issue to resolve around re printing, for this Old Timer's Stock/Inventory program, but will raise a separate question around that.


re the DOS Direct Access Menu issue, I've run up ProcMon and can See vDOS file/registry actions, but of course can't see within the apps that are running within the vDos environment to see what's going wrong. (too low level for the tools)....

Any chance you could possibly please take a look and see if you can see what's causing the menu to do this action, which doesn't occur on the ancient genuine DOS PC?

Download for Direct Access 5.19 can be done from winworldpc.com/download/46c2abc3-83c3-be18-c39a-11c3a4e284a2

AutoExec.cfg sets the C: to a folder and within vDOS all looks ok from a File system perspective.

I extracted the Disk01.img file into a folder within the vDOS C: structure eg: Download\Disk01 and ran the Setup from within there, doing originally an upgrade of the DA519 system, then later a fresh install and creating fresh new menu structures.

I've got a TEMP of C:\TEMP (folder exists) in the vDOS structure.

Original DOS the Menu ran under is pre DOS 6 with a Windows 3 implementation on it (of course won't/can't run under vDOS and is NOT needed/expected to, so is not in the vDOS file structure for this person)......

Hopefully you may be able to spot something vDOS isn't returning back to the Direct Access system.

If not, I'll look to go the trickier way and face the music with the old timer (gulp)....

Cheers
CNSvDosFan.

[Jos]

The main engine of DA is the MAIN.BAT file, with these two first lines:

@echo OFF
DA_MENU ÿ %1 %2 %3 %4 %5

So it starts the DA_MENU.EXE program. That modifies the running MAIN.BAT by writing (new) lines past the second line, ending that sequence with a ASCII 26, EOF.
DA_MENU.EXE exits, the third and following lines are executed.
The last one eventually (no F10 – Exit used) MAIN: MAIN.BAT is ended and started again.

As a batch file is processed by the DOS command line processor, that file is opened, one line read, the current position in the batch file saved, the file closed and the line interpreted.

The catch with vDos: It reads the whole batch file in memory, and then processes its lines. That saves a lot of file opens, positioning and closes.
But changing that batch file while it is running has no effect at all. So the 'previous' content will still be executed.

The only option to circumvent this batch file processing by vDos would be to use another command line processor, like attached 4DOS. You would then change the autoexec.txt line:
menu.bat
To:
4DOS menu.bat

BTW:
You probably already did that: Delete the DA_LOGO.PCX file to get rid of the useless intro.
vDos itself doesn't access the Windows registry and also many file operations just come from Windows DDL's like the mouse system. Those are just logged by ProcMon as vDos.exe because it is the main program running.

Jos

[cnsvdosfan]

Thanks heaps Jos. That made total sense. Sorry, wood for trees.... 
Totally appreciate that.
Menu is now working as the Old Timer expected/demanded - phew.... 1 stress less....
Cheers
CNSvDOSFan
I'll likely be back with a curly Printing question once I sort out the facts fully....

[cnsvdosfan]

Hi Jos,

sorry to bother under this post, but issue is directly related to using the 4DOS processor.

The menu system works great under 4DOS, however (there's always a however right?).....

I have to run an XCopy to Restore a folder structure from a USB Stick & I've successfully mapped the USB Stick fine in the Autoexec.txt, no problem and had a BAT file relying on XCOPY (FreeDos - I saw you mention in another post).

From the VDOS command prompt I can run a BAT file that has a simple XCOPY D:\Folder\*.* C:\FOLDER /s /e /v - No problems. It copies and says 190 files (as it should)

BUT XCopy from under 4DOS says 3 files copied....

Do you know what the issue is there and how to get around it please?

I'm thinking I'll have to use 4DOS' COPY D:\Folder\*.* C:\FOLDER /s /v (apparently the /e isn't copy Empty, but no error messages or something) ....

I don't mind changing the BAT files, but I'd like to also have the BAT file detect it's under 4DOS and change to using COPY instead of XCOPY, so the script can be portable between DOS and the Menu (running under 4DOS on vDOS on Windows) ......

The 4DOS.com works, but of course wasn't installed as such, so appears not to be able to tell me the %_4DOS value i.e. that it's running in 4DOS, so that makes it kind of tricky to detect.

It would also be great to get the HELP installed too.... but not a killer...

Hope you can help.

Cheers CNSvDosFan

[Jos]

Na apparent reason why XCopy wouldn’t work if started from 4DOS. I copied a bunch of directories and 610 files w/o problems.
You’ll have to experiment what’s special to your D:\Folder\*.*. The fourth file is problematic?

%_4DOS isn’t a 4DOS variable, %_4VER is among many others. The full 4DOS package: www.4dos.info/4dvers/4dos800.zip.

Jos

[cnsvdosfan]

Thanks, I saw %_4DOS somewhere, but yep %_4VER - cool.

Re the File copy, I've not found what's wrong, but can confirm it worked 100% in VDOSPlus....

I don't want to go VDOSPlus, so for now have edited the script to detect is 4DOS and am using Copy... Hopefully that will get us by.

Cheers
CvDF

[jamesb52]

Sept 28, 2021 6:23:27 GMT 1 Jos said:

Na apparent reason why XCopy wouldn’t work if started from 4DOS.

After installing a new drive, for example, then updating backups with XCOPY, I've found that the XCOPY switches (such as "XCOPY *.* /S /V /D /E /M") don't work as expected because XCOPY is misreading the destination files the first time on a new setup.  If I turn off the XCOPY switches (thereby copying ALL files) then XCOPY works OK after the switches are set again. It's like a simple permissions error that self-corrects. I hope that makes sense.

[Jos]

Wouldn’t it be time to convince that Old timer things are getting too complicated?

Revert back to vDos only and instead use some dedicated shortcuts?

Jos