On Sat, 31 Jul 2004, Bart Oldeman wrote:
OK, I had already promised that BEEP can:
+ be silent, + print \a,&
+ do some PC speaker sounding.
And the user decide, what to do. The default would be '\a', as it is the most compatible beep at all.
no BIOS, no int29, no delay timing, no direct hardware, just keep it simple -- the ASCII beep goes to STDOUT, redirected to STDAUX and beeps at the right place.
[[Please substitude COM3 with any name of a driver that is suitable for CTTY.]]
It would be, also for other stuff, very helpful to know, if it is save to use local interrupts (video, keyboard) to perform certain actions. For instance:
CLS over COM3 may issue a ^L (Form(ular) Feed) or <ESC>2J (VT100 clear screen), but neither of them work in a WinXP DOSbox (not sure about plain DOS/BIOS). [So one would have to do both, funny ways.]
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?
There are destructive tests to determine whether a read originates from or a write targetted the local console (e.g. compare INT-16-01 with a nice combination of DOS-0B/01 -or- INT-10-03 before/after DOS-02).
But what are the non-destructive tests that work with COM3?
Also: There is the probability that only one of stdin and stdout is connected to the local hardware.
Also: Consider this scenario:
===AUTOEXEC.BAT CTTY NUL %COMSPEC% <CON >CON ===
funny, huh?
Bye,
--
Steffen Kaiser
------------------------------------------------------- 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
