I've got a program here which works fine on Linux but has started to fail on Windows after running fine for years. This doesn't appear to depend on the version of Lazarus, version of FPC or version of Windows, but since I've now got the source in local svn I can see that the earliest version I checked in (r1) works while the next one (r2) doesn't.

Once the message loop is running the program does this to see if there's anything to be piped into it from the command line:

   IF ParamCount = 0 THEN BEGIN          (* Case (1) or (2) *)
     debug('No parameters (case 1 or 2)');
     TRY
       AssignFile(input, '');            (* Standard input               *)
{ IOCHECKS OFF }
       Reset(input);
{ IOCHECKS ON }
       debug('Reset() -> ' + IntToStr(IOResult));
       TRY
         IF modifiedEof(input) THEN BEGIN (* Case (1)    *)
           debug('At EOF (case 1)');

where

   FUNCTION modifiedEof(VAR f: TEXT): BOOLEAN;
   BEGIN
(*$IFDEF UNIX   *)
     IF IsATTY(f) = 0 THEN BEGIN
       debug('stdin is not a TTY');
{$IOCHECKS OFF }
       RESULT:= Eof(f);
{$IOCHECKS ON }
       debug('Eof() -> ' + IntToStr(IOResult))
     END ELSE BEGIN
       debug('stdin is a TTY');
       RESULT:= TRUE
     END;
(*$ELSE         *)
{ IOCHECKS OFF }
     RESULT:= Eof(f);
{ IOCHECKS ON }
     debug('Eof() -> ' + IntToStr(IOResult))
(*$ENDIF        *)
   END { modifiedEof } ;

This used to work, but what I'm now seeing is that when running on Windows it hangs at that Eof() until it sees ^Z<cr>

I think that I've managed to eliminate all code changes, i.e. I don't think there's anything in a .pas file that's causing the problem. The one thing that did happen however was that r2 got modified by a later version of Lazarus than I usually allow near this program, so I had to back out of various SynEdit (etc.) properties that it had added to the forms.

Is there anything stored in non-Pascal files that could cause this sort of problem?

Alternatively, does Windows have anything equivalent to IsATTY() or Do_IsDevice() that I could use as a guard around the failing Eof()?

[...]

This used to work, but what I'm now seeing is that when running on Windows it hangs at that Eof() until it sees ^Z<cr>

You *could* try to set CtrlZMarksEof to False (which is set to True for Windows), but I don't know whether that will really help you...

Alternatively, does Windows have anything equivalent to IsATTY() or Do_IsDevice() that I could use as a guard around the failing Eof()?

There is no IsATTY function for Windows, but a Do_IsDevice exists (internal to the RTL) which basically checks whether the handle stored in the file rec is one of the three I/O handles (StdInputHandle, StdOutputHandle or StdErrorHandle).

Regards,
Sven

I've just tried pushing it both ways to no avail.

I was aware of that from the discussion circa 2005 which pointed me at IsATTY(), but had mistakenly noted it as Dos_IsDevice() and for that and other reasons didn't realise that it was fully-implemented across all platforms. I see it now and can see how it's implemented, if I can't do something with that I'll just live with always having to have a dummy parameter on Windows.

Also relevant discussion around
http://lists.freepascal.org/lists/fpc-devel/2006-May/007794.html

I remain perplexed as to where this problem is lurking. If there's the potential for trouble caused by e.g. inconsistencies between a .lfm and .lrs I might not be the only person this bites.

Many thanks for the suggestions.