Hi all I have found a couple of small bugs in the last beta gpc-19990118.i386-pc-djgppv201.zip when using LFN=n 8.3 limitation in DOS 6.2

The problem comes from the fact that in this situation DOS makes uppercase all filenames. FindFirst/FindNext in the dos.pas unit has an odd behavior displayed by the following short program:

program ff; uses dos; var F:SearchRec; begin FindFirst('ff.pas',Anyfile,F); writeln('l ',DosError); FindFirst('FF.PAS',Anyfile,F); writeln('u ',DosError); end.

DJGPP answers l 0 u 18 i.e. it does NOT recognize the UPPERCASE filename, finding only the lowercase one.

In the same situation BP answers l 0 u 0 i.e. it recognizes both.

The defect can be traced to the function MatchPart in the FindNext procedure. Correction need to be done only under DJGPP (at compilation time) when LFN=n at execution time. A possible solution is given by the attached diff.

Similarly the environment names are always capitalized, so that GetEnv('path') and GetEnv('PATH') give the same result as displyed in the following short program:

program ge; uses dos; var F:SearchRec; begin writeln('LFN=',GetEnv('LFN')); writeln('ll ',FSearch('rhide.exe',GetEnv('path'))); writeln('uu ',FSearch('RHIDE.EXE',GetEnv('PATH'))); writeln('lu ',FSearch('rhide.exe',GetEnv('PATH'))); end.

DJGPP in DOS 6 with LFN=n answers:

LFN=n ll uu F:\DJGPP\BIN\RHIDE.EXE lu F:\DJGPP\BIN\rhide.exe

whereas in BP gives always (even in a W95 dos box)

LFN= ll F:\DJGPP\BIN\rhide.exe uu F:\DJGPP\BIN\RHIDE.EXE lu F:\DJGPP\BIN\rhide.exe

This behavior of automatic capitalization of environment variables is so strange that I am not sure it must be reproduced in a unit which aims at portability: I think that nearly everybody would write naturally programs with environment variables uppercase as displayed by the set command. But for the same reason the first issue on FindFirst/FindNext must be corrected, because filename are usually written in uppercase in DOS, so that the actual behavior of gpc is completely unnatural.

A completely different bug is in the crt unit. Readkey returns #10 i.e. linefeed when one hits the return as well as the ^M keys which should be #13. THis is very strange since the demo program testcurs.c which comes with the sources of PDcurses has the correct behavior.

Hope this helps

Maurice Lombardi