[Freedos-devel] How to detect if fd #0/#1 are the local console (was Re: [Freedos-devel] BEEP)
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 ESC2J (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
[Freedos-devel] (FWD) OpenGEM and FreeDOS
Hi. Shane is interested in hearing from anyone who could help build a FreeDOS core system that could be used to install/run OpenGEM on a bare hard drive. Is anyone interested? Please email Shane directly. His email is below: Shane M. Coughlan [EMAIL PROTECTED] wrote: Hi Jim As you know, I was interested in positioning OpenGEM as a graphical user interface for FreeDOS, and I hope to really push this release as the 16bit GPL GUI of choice for FreeDOS users. This is especially so as FreeDOS 1.0 is getting so close. I was wondering if you knew anyone from the FreeDOS project who might be interested in doing a little work with me to make a FreeDOS 'core' for allowing people to install and use OpenGEM on empty hard drives. This would entail making a small bootable floppy disk (1.44meg format, though using less than this to allow some of OpenGEM to co-exist on the disk). Any help would be wonderful. Regards Shane - Here is a copy of the email I sent a couple of days ago: - Dear everyone, As you may (or may not know) I am leaving the UK to live in Japan shortly. This is a rather big adventure for me, and will entail many changes in my life. Because of this, after I released a new version of GEMini in May, I announced the end of my software days. I cheerfully said that OpenGEM and GEMini were coming to the end of their evolution, though I would continue to support people using the software as best I could. Ahem. A lot of people have contacted me about that statement, and suggested that I should not stop developing OpenGEM or GEMini. In fact, this month 500 people have downloaded OpenGEM, and 300 have downloaded GEMini. There are still a lot of users out there (thanks mainly to the FreeDOS community, who have adopted OpenGEM whole-heartedly). Okay. Let it never be said that I don't listen to other people! :P I have a big announcement to make. OpenGEM Release 3 is coming soon. This will be the third 'generation' of the OpenGEM software, and will mark a substantial leap forward in stability, size, and versatility. I'm still designing the new package, but I can tell you that a lot of useless files are removed, the install and setup functions have been simplified and improved, and configuration options will be vastly increased. The motto with this third generation release is to get rid of junk, cut out unused options, and generally think switch on and use when it comes to the distribution. OpenGEM Release 3 is slated for release on the 10th of August. It will replace OpenGEM 2.2.0. There is some good and some bad news. The bad news is that there will be no direct upgrade patch from OpenGEM 2.2.0 to OpenGEM Release 3. This is because my time is limited, and I cannot allocate enough to make an upgrade patch. The good news is that OpenGEM Release 3 will be designed to be much easier to use, to update, and generally to maintain on your machine. It will be designed to be the most simple, most effective and most useful 16bit GPL graphical user interface for DOS based computers. Because I will move to Japan on the 24th of August for at least one year (gulp) I cannot be sure when and if additional patches would be created for OpenGEM, and certainly I cannot suggest a projected timescale for a potential OpenGEM Release 4. Instead I will focus on getting OpenGEM Release 3 to market, making sure it's good, neat, stable and tidy. I will also commit myself now to attempting to provide good and coherent support to OpenGEM Release 3 for a substantial period, to ensure that when people adopt it they can be sure of some help. OpenGEM Release 3 will be supported by myself and my website (http://gem.shaneland.co.uk) until at least December 2005. I will continue to support OpenGEM 2.2.0 and GEMini Release 2 until the same date. If you need support simply email me at [EMAIL PROTECTED] I believe that OpenGEM is already pretty much the number one 16bit GPL GUI, and I hope to further consolidate this position with the new release. No one even comes close in the range of applications, development and reliability. DOS is an increasingly small market, and other GUIs have failed to adapt themselves to the needs and wishes of consumers. With FreeDOS version 1.0 coming ever closer, I hope OpenGEM Release 3 can provide a firm foundation for people to build their GPL graphical user interface adventures! So there you have it! OpenGEM Release 3 will be out on the 10th of August. For more information visit the OpenGEM website as that date gets closer! Additional news for people who speak Spanish is that another FreeGEM programmer is currently making a version of the GEM software to be distributed in the Spanish language. This will not be an OpenGEM distribution of FreeGEM, but it will be 100% compatible. The first BETA of OpenGEM Release 3 should be out tomorrow evening (GMT). So far it features the following improvements over OpenGEM 2.2.0 OpenGEM Release 3 - 10th August 2004 * Added
Re: [Freedos-devel] How to detect if fd #0/#1 are the local console (was Re: [Freedos-devel] BEEP)
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
