curios...

I haven't reproduced the described problem by following your example:

1) Made a WS6.BAT file in C:\BATCH containing:

1SET PATH=C:\WS6;%PATH%
2CD \WS6\DOC

2) Changed path with "SET PATH=C:\;C:\BATCH" (might want to keep Z:\ in path, but whatever)

3) Executed "WS6" without extension at C:\> prompt, path was changed with prepended dir, current dir changed to C:\WS6\DOC

4) Executed "WS6" without extension at C:\WS6\DOC> prompt, batch ran yet again.

DOSBox's shell only supports a subset of DOS commands, and not all supported commands have all features. Windows command shell script can differ from real DOS in a number of ways. Please post a batch file containing only those commands necessary to reproduce what you think is a problem. If you find that execution of a specific application is necessary to reproduce the problem, that points to a compatibility issue with that application.

I think I've figured out what's causing the problem.

• * My batch file is called WS6.BAT.
  * The ws.exe executable file is in a directory called WS6.

DOSBox is attempting to "run" the directory WS6 instead of the batch file WS6. Since I'm in a Linux environment, I made sure that the executable property of the WS6 directory was cleared for owner, group and others, using chmod, but it makes no difference; DOSBox still attempts to execute directory WS6.

If I rename WS6.BAT as WS9.BAT, it behaves the same way as I would expect it to in a real DOS environment and I can run the batch command WS9 from anywhere in the PATH without having to add ".BAT" to the command line.

DOSBox must first test whether a command string can be matched with one or more file names in the PATH as it parses the PATH value from left to right. (In my example, it should look for "WS6" first in C:\WS6, then in C:\ and finally in C:\BATCH. It must attempt to run partial matches in each path exactly in the following order (See http://support.microsoft.com/kb/35284):

1. COM
2. EXE
3. BAT

In other words, it needs to first look in C:\WS6 for WS6.COM, WS6.EXE and WS6.BAT; then look in C:\ for WS6.COM, WS6.EXE and WS6.BAT; finally, look in C:\BATCH for WS6.COM, WS6.EXE and WS6.BAT.. Any directory matching the name "WS6" in those three places must be ignored and DOSBox should not even attempt to run it. Once DOSBox has exhausted the search for EXE, COM and BAT possibilities and failed to make a match, it should report "Bad command or file name".

I tried repeating your experiment with a simple directory structure that looks like this:

1C:\
2   |
3   + - WS8
4      |
5      + - DOC

and running a batch file in C:\BATCH called "WS8.BAT" that looks like this:

1SET PATH=C:\;C:\BATCH
2SET PATH=C:\WS8;%PATH%
3CD \WS8\DOC

It runs fine the first time from C:\, but fails when one attempts to run it a second time from C:\WS8\DOC. See the attached screenshot. Note that DOSBox reports "Illegal command: ws8.", with a trailing period. I don't know if it is saying it is trying to execute an entity called "ws8." or if the period was simply added for style in the screen message. While in C:\WS8\DOC I can reset the PATH value to C:\;C:\BATCH and type "ws8", and it still fails, telling me that it finds the directory called "WS8" in C:\, tries to execute it and gives up.

This is definitely a DOSBox bug that should be brought to the attention of the developers, though I'm not sure how to do it.

As you can see in the attached screenshot, the problem is not occuring with my test on the official Win32 release of DOSBox 0.74, so perhaps there is a platform issue. Maybe others on Linux platforms can try this simple batch test.

Your initial post said you're using 0.74, but your screenshot shows 0.73, so please ensure that you're using 0.74, although I don't think it will fix whatever the problem is.

ripsaw8080 wrote:

Your initial post said you're using 0.74, but your screenshot shows 0.73, so please ensure that you're using 0.74, although I don't think it will fix whatever the problem is.

Oops, you're correct. I just installed 0.74-1 from the Debian "Squeeze" repository (Ubuntu has 0.73) and the results are the same.

This could, indeed, be a platform related issue. Maybe DOSBox isn't detecting directories properly when running on Linux, thinking that they're just another executable file.

I'll take a look.

I don't have 0.74 installed on this linux machine, but I can confirm the problem in 0.73, but it works in the current SVN.

It's either fixed or depends on the compiler used.