So you're running TP7 in DOSBox? DOSBox is not really meant for running TP7.

I would be concerned as to whether your copy of TP7 is complete and installed correctly.

Also: DOSBox IS NOT SUITED TO RUN YOUR NON-GAMING DOS APPLICATION

I too use DOSBox with Turbo Pascal 7.0 and discovered the same thing.
What I found so far is that this is related somehow to the way stdin/stdout works under DOSBox.
I found that a GREP search creates two files: $$PIPE$$.TP$ and $$MSG$$$.TP$ and I think the latter contains the search result, but Turbo Pascal cannot retrieve it.
I experimented a bit with the GREP2MSG.PAS file (located in TP7's BIN directory) but still have not found a solution.

Another quirk running under DOSBox I discovered (and I suspect this problem is not unique to Turbo Pascal):
Copy a file, for example using Windows Explorer, into a folder which a session of Turbo Pascal is using.
Go to File | Open and one cannot find the file just copied.
Exit Turbo Pascal (and DOSBox if it is not configured to auto close with the application its running).
Now Restart DOSBox/Turbo Pascal and now one can find the file just copied.

Not sure why the bad attitude toward other-than-game-users of DOSBox. I can understand why DOSBox developers do not want any liability for unintended side effects, etc.
But, as a programmer myself, I would view the information provided from other-than-game users as potentially useful and may provide clues to any open issues with running games.

for the latter, press ctrl-f4

With regards to GREP. It might be benefical to debug that. As long as there is no piping involved, we should be able to handle it pretty well.

raydela wrote:

Copy a file, for example using Windows Explorer, into a folder which a session of Turbo Pascal is using. Go to File | Open and o […]
Show full quote

Copy a file, for example using Windows Explorer, into a folder which a session of Turbo Pascal is using.
Go to File | Open and one cannot find the file just copied.
Exit Turbo Pascal (and DOSBox if it is not configured to auto close with the application its running).
Now Restart DOSBox/Turbo Pascal and now one can find the file just copied.

This is caused by DOSBox's internal directory cache. If you change the contents of mounted folders outside of DOSBox then you need to refresh the cache (Ctrl-F4 by default) for DOSBox to "see" the changes.

raydela wrote:

Not sure why the bad attitude toward other-than-game-users of DOSBox.

Well, I don't really see any "bad" attitude in this case. You might get a similar reaction if you take your new hammer back to the hardware store and mention that it doesn't work well when trying to pound in screws.

This is caused by DOSBox's internal directory cache. If you change the contents of mounted folders outside of DOSBox then you need to refresh the cache (Ctrl-F4 by default) for DOSBox to "see" the changes.

So any changes made to folders by the application running under DOSBox can be seen immediately without pressing Ctrl-F4?
(Just wondering if this was the answer to the Turbo Pascal/GREP issue -- maybe Turbo Pascal can't see the search results file in order to retrieve it.)

yes, the cache is only aware of stuff happening inside DOSBox.

The problem with GREP is that DOSBox does not convert tabs to spaces in INT 21/02, and the GREP2MSG program is confused when it finds tab characters. A cheap hack is to change tabs to a single space:

1    case 0x02:        /* Write character to STDOUT */
2        {
3            Bit8u c=reg_dl;Bit16u n=1;
4+           if (c==9) c=0x20;
5            DOS_WriteFile(STDOUT,&c,&n);
6            //Not in the official specs, but happens nonetheless. (last written character)
7-           reg_al = c;// reg_al=(c==9)?0x20:c; //Officially: tab to spaces
8+           reg_al = c;
9        }
10        break;

To do it properly, the output function would have to keep track of the column so the appropriate number of spaces can be written out.

Thanks for figuring it out.
That is pretty cheap indeed. Wouldn't the write (while not being redirected) end up at int10_teletype in the end which would do the expansion? Now that would be lost as well.

Qbix wrote:

Wouldn't the write (while not being redirected) end up at int10_teletype in the end which would do the expansion? Now that would be lost as well.

I think that in real DOS the console device is responsible for converting tabs to spaces, not video BIOS functions.

The problem with GREP is that DOSBox does not convert tabs to spaces in INT 21/02, and the GREP2MSG program is confused when it finds tab characters.

Aha!

I made the following change to GREP2MSG.PAS and recompiled it.

First, change the E (error code) variable at top of file:

1LineNo, E : word;

to two error code variables:

1LineNo, E_space, E_tab : word;

Second, add a string variable:

1sTab : string;  { Pos(...) function requires a string for the sub-string argument. }

Third, initialize sTab somewhere BEFORE the repeat loop:

1sTab[0] := Chr(1);   { Array location of Pascal string size }  
2sTab[1] := Chr($09); { load the Tab character into the Pascal string } 

Finally, make the following change where loop processes the (expected) spaces in sLine:

1<SNIP>
2   else begin
3      Val(Copy(sLine, 1, Pos(' ', sLine) - 1), LineNo, E);
4      if (E = 0) then
5         WriteMessage( LineNo, 1, TrimLeft(Copy(sLine, 9, 132)) )
6   end;
7<SNIP>

Change To:

1<SNIP>
2 else begin
3      Val(Copy(sLine, 1, Pos(' ', sLine) - 1), LineNo, E_space);
4
5      if (E_space = 0) then
6         WriteMessage( LineNo, 1, TrimLeft(Copy(sLine, 9, 132)) )
7      else begin
8         Val(Copy(sLine, 1, Pos( sTab , sLine) - 1), LineNo, E_tab);
9         if (E_tab = 0) then
10            WriteMessage( LineNo, 1, TrimLeft(Copy(sLine, 9, 132)) );
11      end;
12end;
13<SNIP>

This will now support either spaces or tabs.

Thanks for looking into this.

(P.S. Is there a way to send a donation to Vogons, preferably via PayPal?)

Looking at this again, you don't need separate E_space and E_tab variables.
The original E variable will work.
Also, even though the Pos(...) function specifies that the sub-string argument must be of string type, I found the following will work when the sLine contains tab(s).

1Val(Copy(sLine, 1, Pos( Chr($9) , sLine) - 1), LineNo, E_tab)

Therefore, disregard anything regarding adding variables and use the following:

1<SNIP>
2 else begin
3      Val(Copy(sLine, 1, Pos(' ', sLine) - 1), LineNo, E);
4
5      if (E = 0) then
6         WriteMessage( LineNo, 1, TrimLeft(Copy(sLine, 9, 132)) )
7      else begin
8         Val(Copy(sLine, 1, Pos( Chr($9) , sLine) - 1), LineNo, E);
9         if (E = 0) then
10            WriteMessage( LineNo, 1, TrimLeft(Copy(sLine, 9, 132)) );
11      end;
12end;

<SNIP>