Hi,
Steffen Kaiser escribi�:
Til this time there had be no suggestion to overcome the requirement about how to detect if:
1) FreeCOM's input comes from the local keyboard (in opposite to FreeCOM MUST use the file descriptor #0 or the "read from stdin" DOS APIs) and
2) FreeCOM's output goes to the local screen (in opposite to FreeCOM MUST use the file descriptor #2 or the "write to stdout" DOS APIs).
There are two obvious indicators that the console is NOT the local hardware:
1) when fd #0 (or #1 respectively) is NOT connected to a device, and
2) when fd #0 (or #1 respectively) is connected to a device, which has the NUL or CLOCK$ bit set.
How can FreeCOM detect a CTTY COM3 situation _without_ FreeCOM had carried out the CTTY command itself, e.g. when you boot the system with another shell or when a special setup (embedded system or maybe a CONFIG.SYS patch making CTTY= available) is used.
There had been a discussion that the LoL field "last loaded CON: driver" is not suitable.
Also, the name of the driver itself "CON" is not suitable, as one can name a driver like that, that is not driving a console at all.
Are the stdin/stdout bits of any value?
As I see it, FreeCOM should in all cases use files stdin and stdout for entries. I see it as logical that someone (maybe Kernel) should guarantee that only one device has stdin/stdout bits at a time (and this is the device where file #0, file #1 should point to), regardless if it is CON or has other name, but I haven't tested this, so I don't know.
I just wanted to use this thread and ask (whenever DISPLAY becomes a SYS) if when I chain to a previous CON driver, wether I should clear the previous CON driver's stdin/stdout bits, and set my own stdin/stdout bits. If I just do this, I don't think it is guaranteed that stdin points to me. Of course, it's faster (and less mess) if stdin/stdout continues to point to the old CON driver (DISPLAY will just chain all the calls except IOCTL), but I think that this wouldn't be logical.
Any ideas or light on this is welcome.
Aitor
------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
