Z is not a real drive. It probably checks the path or comspec variables. What you might do (inside DOSBox) is:

1copy z:\command.com c:\
2set comspec=C:\COMMAND.COM
3path=c:\;z:\

If it works, you only need to do the first line once. You can add the other two to the [autoexec] portion of dosbox.conf.

Thank's for the answer.

I've already tried before (and now again to be sure) but no result.

It continue to writing me "Couldn't create record buffer file".

I'm afraid that this "runform.exe" try to create this record buffer with some direct address, because I've tried with an old desktop, booting with MsDos 6.22 from the floppy disk (A:), the comspec is = a:\command.com, the path starts with "a:\;...." but the buffer record is written on "c:\".

O maybe there are some I/O problems?..

luigi

Are you sure you're also actually starting the program from drive C: (that is: does the prompt actually start with C: )? Perhaps it just writes to the current drive.

You are exactly, Kippesoep.

I have tried now on the old desktop MsDos 6.20

The runform.exe program writes the buffer record file on the root (\) of the drive from where I execute runform.exe. So isn't the "path" or the "comspec" driving the address for this small buffer record files.

Now, on the new laptop Xp i've tried again to run "runform.exe" from the "C:\" of DosBox, ma it doesn't start and still writes "Couldn't create record buffer file".

The "runform.exe oracle book help" tell's me that happen when there is no space on the hard disk (but with the dir command on "c:\" from Dosbox shows 100mb) or there are I/O problems.

luigi

When you mount the "C:\" in dosbox you can specify a higher value for drive space.

Ex: "Mount c D:\oracle6 -freesize 500"

Thanks DosFreak.

I've tried also this, but is not a problem of size. This buffer record file is just 0(zero) bytes.

luigi

luigi sent me a small demo at my request. I've used it to debug and found an error in DOSBox' file open code.

The program uses a temporary file "2" in the root of the running drive. (If it already exists, it tries "3" etc). It does this by calling INT21/AH=3D ("open existing file") with DS:DX pointing to "\2".

DOSBox attempts to open this file. It doesn't exist, so it tries to determine which error code to return: 2 (file not found) or 3 (path not found).

In the function "PathExists", it zeroes out the last '\' in the path. Since, in case of a file in the root directory of the current drive (i.e. no drive letter), this is also the first and only '\', it becomes an empty string. DOS_MakeName then interprets this as invalid and error code 3 (path not found) gets set. Since the root of the current drive must by definition exist, the program doesn't check for this error code, only error 2 (file not found) and in getting an unexpected error, gives up.

The fix is quite simple. In src/dos/dos_files.cpp:

1static bool PathExists(char* name) {
2	char* leading = strrchr(name,'\\');
3	if(!leading) return true;
4	char temp[CROSS_LEN];
5	strcpy(temp,name);
6	leading = strrchr(temp,'\\');
7	*leading = 0;
8	Bit8u drive;char fulldir[DOS_PATHLENGTH];
9	if (!DOS_MakeName(temp,fulldir,&drive)) return false;
10	if(!Drives[drive]->TestDir(fulldir)) return false;
11	return true;
12}

should become:

1static bool PathExists(char* name) {
2	char* leading = strrchr(name,'\\');
3	if(!leading) return true;
4	char temp[CROSS_LEN];
5	strcpy(temp,name);
6	leading = strrchr(temp,'\\');
7	if (leading == temp) return true;
8	*leading = 0;
9	Bit8u drive;char fulldir[DOS_PATHLENGTH];
10	if (!DOS_MakeName(temp,fulldir,&drive)) return false;
11	if(!Drives[drive]->TestDir(fulldir)) return false;
12	return true;
13}

When this is implemented, Luigi's demo runs just fine.

Attached is the patch.

Thanks Kippesoep, makes sense.
(the patch is on sourceforge as well i saw)

Thanks Kippesoep for resolving the test case and for answering me.

For me was the first time to get into this Forum and it is really nice to see people that try to help each other.

Thanks also to DosFreak and wd for giving time to this test case.

Best regards.

luigi