On 2002-12-03, Tom Ehlert wrote: > I have a dual monitor configuration > the second IS HGC > I USE the hercules card - nearly every day > I NEVER EVER got even the idea to install a DOS driver for that. > I'm VERY happy to have a HGC card (and minitor)
Fine, I'm too. All my systems are dual screen systems (most of them SVGA + HGC) and I know several people, who do use dual screen drivers to redirect text to just the "other" screen using something like: ECHO Foo > CO80: ECHO Bar > BW80: ECHO Hello World > CON: > IMO, I prefer working 2003 for > 98% all cases over might work > in 2010 - eventually (if I'm not too busy) Hm, being at 98% in 2003 is completely illusoric, IMHO. The FreeDOS kernel has made significant progress, that's great. And there are a few really outstanding drivers and utilities. But being realistic, several more years of hard work will have to go by before the majority of the FreeDOS utility set will have reached the same level of maturity as in MS-DOS/PC DOS or DR-DOS. I hope it will happen eventually. As I see it, the most significant problem for many volunteers is simply lack of knowledge, what's actually going on under the hood, and also of the historical background, why some DOS components were designed this way and not another, originally. Knowing this helps to better understand DOS' internals. Hence, I'm trying to share what I can share (and my time allows), and I'm also very happy to learn from others, where they can provide expertise. > sorry for being harsh, but these 'one could think of' messages > effectively STOP all useful work. No, not in my opinion. Knowledge can never harm, being ahead in ideas and design compared to the actual implementation cannot either. It enables people to create better and more compatible software. Not knowing issues will often lead into dead ends or cause compatibility issues. Look at most questions raised in the DOS related newsgroups (probably even more so in the Windows groups), most of them are the result of lacking knowledge or improper documentation. Of course, even with enough knowledge it is still some kind of trial-and-error process, but I hope the learning curve will be much higher, as potential mistakes can be identified much earlier. IMHO the fine arts of engineering is to find the right compromise, that is, to /be/ knowledgable at first, and then /actively/ decide to temporarily put down some marginal issues to fulfill the deadline. But since there is no deadline for FreeDOS, and we do have mature and flexible (but now for the most part static) DOS issues already, there is IMHO no point in recreating the wheel without coming up with a better solution in the end... ;-) I don't say, the first release will/could/should be final, but if you don't think of potentially planned extensions right from the start, you might have to start from scratch in the middle of the project. However, my comments are never meant like "Please implement this for me" - if I'd need it for myself *now*, I could and would sure just implement it myself. But I usually use DR-DOS anyway, so I won't have any direct advantage of FreeDOS extensions except for enjoying that some of the DR-DOS features and ideas are spreading into other implementations, thereby making DOS "as is" a more convenient and attractive platform, which, I hope, will keep it alive a bit longer. That's also why I care that my own solutions are compatible with any DOS, including FreeDOS and DR-DOS. My comments are always meant as "Please take this non-obvious issue/ idea into account, while working on xyz" so that different solutions stay compatible with each other. I have seen more than one FreeDOS component being seriously incompatible with established DOS standards due to an only partial understanding and therefore implementation of the standard, and while it is always possible to fix these problems in later issues, I see no purpose in introducing them in the first place. I don't know how this would be possible without deeper insight, that's why I try to answer questions raised here and give some background info. --- On 2002-12-03, Aitor Santamar�a Merino wrote: > Suppose that I name DISPLAY as device CO80:, who assigns > CON to CO80: ? DISPLAY.SYS loads "on top" of another console driver, usually named CON:. I doubt other names of the console driver will be accepted despite the syntactical provision for the parameter. The CON: string is probably hardwired into the driver at the moment. But if you could already attach DISPLAY.SYS to other console drivers (as it for sure was planned to be possible), the CON: driver itself would have to use the, say, CO80: (or BW80:) driver internally, just like the PRN: driver internally uses the LPT1: driver (unless you are under a DOS issue where you can reassign this). If you would want independent codepage switching on both, CO80: and BW80:, you would have to load DISPLAY.SYS on top of both console drivers, I guess. Hypothetical example: DEVICE=DISPLAY.SYS co80:=(ega,437,(6,3)) DEVICE=DISPLAY.SYS bw80:=(mono,(437,161),0) Note, that (unfortunately only) the DR DOS 6.0+ PRINTER.SYS driver supports multiple drivers in one go as in this example: DEVICE=PRINTER.SYS lpt1:=(1050,367,12) lpt2:=(4201,850,2) lpt3:=(5202,437,2) The advantage is that the code will be shared between these drivers and only the data is kept separate for each of them, resulting in a significantly reduced memory footprint compared to the usual sequence of: DEVICE=PRINTER.SYS lpt1:=(1050,367,12) DEVICE=PRINTER.SYS lpt2:=(4201,850,2) DEVICE=PRINTER.SYS lpt3:=(5202,437,2) So, at a later stage (not now!), it might be worth thinking about adding something similar to DISPLAY.SYS as well: DEVICE=DISPLAY.SYS co80:=(ega,437,(6,3)) bw80:=(mono,(437,161),0) As another sidenote, under DR-DOS 7.02+ you can use the [D]CONFIG.SYS PRN=0,1..3,4 and AUX=0,1..4 directives to change the defaults. The main advantage of this being implemented into the DOS BIOS is that it required zero extra memory compared to a non-enhanced system (where you would have to overload drivers or hook into the System BIOS interrupts for a similar effect). PRN=0 and AUX=0 will hardwire the connection between PRN:->LPT1: and AUX:->COM1:, so this cannot be changed at runtime unless you would overload these drivers. I called it "high-speed bypass" as it saves a few clock cycles. PRN=1 and AUX=1 will still select these devices (LPT1: and COM1:) but make them configurable at runtime using a special issue of MODE (which has yet to be written - but it's merely changing a private flag in the DOS BIOS data segment). Syntax: MODE prn[:]=lptx[:] with x=1..3,4 MODE aux[:]=comx[:] with x=1..4 Other values (1..4) work the same, except for PRN=4 which only works in DR-DOS 7.02, not in DR-DOS 7.03+ any more (due to a serious bug introduced when the LPT4: device was removed improperly). Multiuser DOS always had a similar (yet much more powerful) configurability for PRN: and AUX:. At the moment, if you switch between monochrom and color display adapters, the actual switch is performed by the INT 10h BIOS, not DOS. So writing to CON: will come up whereever the data in the BIOS data segment "points to". Using the CO80: and BW80: (or COLOR: and MONO:) device drivers (as part of Axel's DUALMON.SYS driver) will write directly onto the corresponding screen, but noone keeps one from writing true alternative CON: device drivers. > Well, just a bit of positivity: at least it opens your mind to > other possibilities, not meaning that they are going to be > implemented in the near future. > [...] > Well, just it's nice to know even if just for information... Thanks. That was exactly my intention. Greetings, Matthias -- <mailto:[EMAIL PROTECTED]>; <mailto:[EMAIL PROTECTED]> http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org "Programs are poems for computers." ---------- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^^=============================================================== This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^^===============================================================
