How to set Path variable for non-executable file extensions in 4DOS

[mdavid]

Hi, I'm using 4DOS with vDosPlus to run some legacy MS-DOS software, I need to add non-executable files to the search path. The original ms-dos system used APPEND to achieve this, but 4dos does not support the APPEND command. So how can I add non-executable file types to the search path in 4DOS?
Any help much appreciated
David

 

[Joe Caverly]

Hello David,
I answered your question on the vDosPlus SourceForge Forum.

vDosPlus / Discussion / General Discussion:Executable Extensions

Joe

 

[K_Meinhard]

Wouldn't ESET do what APPEND does?

 

[mdavid]

Thanks for this, not clear how to use ESET.
In my autoexec I have:

APPEND C:\SA2000;C:\SA2000\USER;C:\UTL

Where and how would I write this using ESET

Thanks for your help
David

 

[mdavid]

I put: ESET %path in the autoexec

%path includes the directory where the .DTA file is located
but I'm still receiving a "File not found" error.

I understand that the path variable only searches for executable files, what I need is a command that will search the specified path for non-executable files such as .DTA

Thanks for your help
David

 

[K_Meinhard]

Sorry, upon looking a bit deeper it seems that ESET cannot help here, and i have no longer a 4dos machine available.

 

[K_Meinhard]

After a little experimenting, I have found a simple way that seems to work here, at least using TCCLE14, which should be compatible to 4DOS using this simple commands.

I made an executable extension:
set *.ini="C:\Windows\System32\notepad.exe"

I added the TCCLE14 directory to my %PATH variable:
set path=%path;"c:\program files (x86)\jpsoft\tccle14\"

Issued the command "updater.ini", which brought up the file in Notepad, as expected.
I then changed to the root directory of my drive and issued the command again. The file came up in Notepad, again.

Isn't that what you wanted to achieve?

 

[Charles Dye]

If memory serves, APPEND was a kind of compatibility kludge for very ancient MS-DOS programs — the kind that used File Control Blocks and didn't understand subdirectories. It worked by patching the internal structures of MS-DOS. Unless you are running (A) an application from Ronald Reagan's first term, under (B) an actual DOS operating system, APPEND is not likely to be of any use to you.

What, exactly, are you trying to do?

 

[vefatica]

If memory serves, APPEND was a kind of compatibility kludge for very ancient MS-DOS programs — the kind that used File Control Blocks and didn't understand subdirectories. It worked by patching the internal structures of MS-DOS. Unless you are running (A) an application from Ronald Reagan's first term, under (B) an actual DOS operating system, APPEND is not likely to be of any use to you.

What, exactly, are you trying to do?

Yup. I think that's exactly what he wants to do ... what APPEND did in MSDOS.

Here's the description of APPEND from the MSDOS 5.0 Users Manual (1991).

APPEND

Enables programs to open data files in specified directories as if these files were in the current directory.

The specified directories are called appended directories because, for the sake of opening data files, they can be found as if they were appended to the current directory.