Hi Denis
 > Somewhere down the chain when the DOS interrupt is called,
 > the INDOS flag is being set. Then when it comes to your code, the flag
 > is set, so you skip the print and exit as normal. Either way, the INDOS
 > flag will always be set since you're in the interrupt. There isn't a
 > chance for the flag to be seto to zero.
 You right i think. It may be set to zero few lines of code before it reachs
 the IRET (if interrupts are enable) and exit from the DOS interrupt.
 > case, you wouldn't even need to check anyway. You could just
 > "skip" that code and go to the print itself. Though either way I don't
 > think it's good to call DOS within DOS itself. Unless you're on a 
ifferent
 > interrupt or something.
  Yes i could, but need the check anyway critical flag otherwise the program
  will crash. So isn't good call DOS within DOS itself? :>
  Here is a part of a DOC about DOS interrupt
        INT 20  Program terminate
        INT 21  DOS Function Dispatcher
        INT 22  Program Terminate
        INT 23  Ctl-break exit address
        INT 24  Critical error handler address
        INT 25  Absolute disk read
        INT 26  Absolute disk write
        INT 27  Terminate but stay resident
        INT 28  DOS idle loop/scheduler (undocumented)
        INT 29  Fast character output (undocumented)
        INT 2E  Execute command using base level COMMAND.COM (undoc.)
        INT 2F  Multiplex interrupt (DOS 3.x+)
 Does it mean that inDOS flag isn't own by INT 21h only? But throught this
 range?
 > Hmm, possibly a register is being changed which might need to
 > be saved on the stack?
 But after printing on indos=1 i get this when i type to the prompt.
C:\>dir | more
Intermediate file error during pipe
So the command line becomes messy.
 > Well, aside from what I've mentioned above, I put together my
 > own little test programs. I'll post them to you as seperate messages,
 > perhaps they might prove helpful.
  Okay, i will grab them and try it.
Ciao Denis!
Sylvain
---
---------------