|
|
Post by David Martin on Sept 22, 2020 21:10:22 GMT 1
Is there someway ... environment variable maybe ... to know the directory that was used in the "USE C: C:\directory" command in the AUTOEXEC.TXT file?
|
|
|
|
Post by David Martin on Sept 22, 2020 21:39:44 GMT 1
I was hoping ... SET VDOSC=%%CD%% ... would work as it is a valid Window environment variable.
SET USERNAME=%%USERNAME%% correctly sets an environment variable in the vDOS environment filled with the %USERNAME%
|
|
|
|
Post by Jos on Sept 22, 2020 21:39:49 GMT 1
You assign that directory yourself, so you can also set an environment variable accordingly?
Jos
|
|
|
|
Post by David Martin on Sept 22, 2020 21:41:33 GMT 1
Yeah, that is what I'm doing now ...
Was just looking to see if there was something already available to where I wouldn't need to remember to setup another item when installing on a new system for someone.
|
|
|
|
Post by Jos on Sept 22, 2020 22:09:21 GMT 1
You could do:
SET VDOSC=<whatever>
USE C: %VDOSC%
The Windows CD seems specific to the SET command, it’s no actual environment variable.
Jos
|
|
|
|
Post by David Martin on Sept 23, 2020 19:07:18 GMT 1
Yeah, that is what I ended up doing ... like you said I have to set it once somewhere ...
Thanks for help.
|
|
|
|
Post by andersostling on Nov 5, 2020 13:37:25 GMT 1
Our legacy DOS application is run from a network drive, but depends on two local directories on the C: drive. Instead of re-mapping C to the actual C disk, I moved both directories into the vDOS directory, aka the virtual C. Works fine and in my option a much cleaner solution since it will keep everything related to the (local) DOS app in a single directory. YMMV.
|
|
|
|
Post by Jos on Nov 5, 2020 14:14:38 GMT 1
Next would eventually be to get rid of all local DOS/vDos stuff, and move that (a single copy) to the network drive. So you end up with only local (desktop) shortcuts to start your app.
Jos
|
|
|
|
Post by andersostling on Nov 5, 2020 16:31:42 GMT 1
I can see that as an option, except that printing may be a problem since the app creates a local spool file for printing. How would concurrent users handle that?
|
|
|
|
Post by Jos on Nov 5, 2020 17:45:23 GMT 1
Normally such files are short-lived: Create the file, write lines to it, then print it and it’s of no further use to the program.
The chance spool files colliding is real small, but you would have to try it out. Perhaps those local spool files can even be disabled by some option in your app.
vDos also creates two such files, #LPTx/#COMx.asc and .txt. Didn’t get reports of problems with that.
But then again those files have no purpose to vDos itself. You can even prevent them from being created by the PRIVATE option in config.txt.
Jos
|
|
