i was thinking, is it possible that we can re-read the file before parsing the line in the batch file but keep the line pointer?

what do you think?

Dunno if it helps, but you could try adding a "rescan" to clear the cache.

our batch file parser keeps the file open during the execution of the bat file.

yeah, i'd have to recompile the source of my program to add the rescan in but then it won't work in normal dos.

i've tried adding a rescan in the shell_batch.cpp but with no success. do you have an idea how to do it?

(my program has a shell that edits the batch file. that is - it keeps it open. not my idea but that's how it was done in the 80's as a way of "multitasking")

do you think it makes sense if we open and close the batch file before each line?

thanks,
trev.

I don't know how it went in real dos either.
I know that there is some interrupt that parses commandlines/batch file lines.
The started program from a batchfile doesn't get the filehandle of the batchfile. We now arange that by setting the non-inherit flag. It might be that the file was actually closed. Dunno.

the only thing we don't know, is what exactly occured when this interrupt came....

does anyone know?

i really want to refine this shell_batch.cpp so it works like real DOS.

I don't know if rescan will help us here or not?

when this interrupt came....

What interrupt?

the interrupt that real DOS supposedly gives or takes....

The command parsing one? That's just something like a subroutine
i think, doesn't really help with this problem.

ok, so we know the problem. let's try to think of ways to get around it.

to me, it seems like the "old" unupdated file is still in memory. we have to add something to the line parser or reader (most likely the reader function) to refresh the cache or reload the file....

Suppose you'd have to open the file before the DOS_ReadFile and close
it afterwards, and maintaining a line counter or something to seek to the
correct line before the DOS_ReadFile().

the goto does work how it should (it rereads the file). i have tested by editing the batch file outside of dosbox while the batch file is running, and the goto jump always picks up the edits immediately...

so i guess i have to implement something like this with a line pointer for the readfile..

any better ideas? i'll have a go at it...

Line pointer? Better just a byte/character pointer.

The WinXP command prompt at least seems to use a byte/char pointer. I just tested with a batch file that changed the length of some lines above its execution point and it just dumps back to the prompt at that point (without any error message). If the lines are changed, but the length remains the same, execution continues.

i guess I shoulod use DOS_SeekFile() to return back to the position i was or?

I don't really understand this DOS_SEEK_SET part of the function. There are two other strings but it seems they are not used?

If DOS_ReadFile() returns true, in the 3rd parameter (&n) the number of
read characters is returned, so you can count them to maintain the position.

DOS_SeekFile() is used to set the position of the file, where you'll need the
DOS_SEEK_SET type (set position).
To query the file position you could also use DOS_SeekFile() with the
DOS_SEEK_CUR type and a zero offset, which should return the position
and does not change the file position.

So guys, the problem is solved with 3 lines of code in shell_batch.cpp

1bool BatchFile::ReadLine(char * line) {
2	Bit8u c=0;Bit16u n=1;
3	Bit32u pos=0;
4		DOS_SeekFile(file_handle,&pos,DOS_SEEK_CUR); //bugfix: get current file position
5		DOS_SeekFile(file_handle,&pos,DOS_SEEK_SET); //bugfix: goto(set) file position to re-scan batch file for changes.

basically for every line of the batch file, i get the position, and then force a rescan by returning to the same position again....
any disputes about how i did it?

many many thanks for your great support!!!

trev

The only problem i see now is passing parameters (%2 %3 etc...) in call statements with "=" characters...

behaviour is different in real dos to DOSBox.... i suppose this is another thread 😀

Looking at the solution:

Isn't this a host level problem then ? I recall we have simalar code in dos_file:::read after a write
DOSBox itself does no caching of the data.