From: mharris AT blackwidow DOT saultc DOT on DOT ca Date: Mon, 10 Feb 1997 06:56:39 -0500 (EST) Reply-To: mharris AT blackwidow DOT saultc DOT on DOT ca To: Roger Ivie cc: OPENDOS AT mail DOT tacoma DOT net Subject: Re: [opendos] OS advancements and old technology: My viewpoint. In-Reply-To: <01IF2GFAGFOI8ZORO4@cc.usu.edu> Message-ID: Organization: Total disorganization. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-opendos AT mail DOT tacoma DOT net Precedence: bulk On Wed, 5 Feb 1997, Roger Ivie wrote: > > There has been a lot of discussion lately on the list about > > improvements in OpenDOS, and software in general breaking on > > older machines. > > I apologize if I have left the impression that my primary concern is older > systems; it is not. My primary concern is embedded systsms in which PC > compatible is not needed, not desired, and expensive; yet, the most > cost-effective development system is DOS, so many systems eat the costs of > PC compatibility because the tools are affordable. Ok, if PC compatible is not needed, then use a portable OS that isn't tied to the x86 IBM-PC. > > The post I just read about Turbo C 1.5 not running on the DEC > > Rainbow (a NON-PC compatible as stated) is irrelevant. If TC 1.0 > > works, then use it! > > The example was intended to illustrate software that requires compatible > hardware for no good reason. Why should the command line version of Turbo C > care if it's running on a PC? It's a _compiler_ for crying out loud. I > specifically omitted the IDE from my complaint, because it makes sense for > that to be tied to specific hardware. Ask Borland. I'm sure that they didn't say, "hey, lets make this program not run on the DEC rainbow". On the contrary. Turbo C is an IBM PC program. Borland claims that it will run on an IBM-PC or 100% compatible computer. The claim doesn't read that Turbo C will run on any circuit board with an 8088 on it. That is WHY TC cares if it is running on an IBM PC, because it was written FOR an IBM PC. Simple. As for your wishing that TC was made for the x86 in general and not just the IBM PC, I'm afraid you'll have to take that up with Borland. Besides, you should be using Micro C for embedded systems work anyways. The code it produces is much smaller. Anyone doing embedded systems work should know about Micro C. Also, feel free to use FreeDOS. The FreeDOS kernel is written with Micro C as well. This would be a fantastic solution to all of your embedded systems work as it is all FREE. > For what good reason should a _compiler_ be tied to a specific piece of > hardware? To take advantages of that hardware? Everyone is free to choose between portability and speed and/or other OS/hardware specific features when designing a piece of software. This doesn't exclude compiler vendors. Just out of curiousity, does Microsoft C, or Watcom, or Symantec or Zortech or DJGPP work on the DEC rainbow? Also out of curiousity, can you use MSDOS on the systems that you are working on? What I'm asking is were you using MSDOS previously, but now you're upgrading to using OpenDOS for development? Or is MSDOS incompatible with the embedded systems? > > From the software development side of things, a developer wants > > to write software that works on the MOST number of machines. To > > do that, it makes sense to stick to some sort of standard. > > I have no problem with that. My gripe is about tying the _operating system_ > to a particular bit of hardware for no good reason. Blame Microsoft/IBM for that. They never said that DOS was a portable OS. Whoever told you that it was needs to be set straight. > > By sticking to standards, we help maintain an even playing field > > when developing. When new technology or hardware comes into the > > picture, new standards are needed. > > By sticking to standards at an unneccesarily low level, you are also > stifling creativity. At the risk of putting you back to sleep, let me use > CP/M as an example. ... ZZZZZ.. ZZZZZZ.. .... .... By sticking to a VT100 terminal, I'd say is stifling creativity. > Now, I am not saying that we should all be running CP/M or that CP/M is the > end-all be-all of operating systems. Then why do you keep talking about CP/M? > However, CP/M-land shows us the > diversity that is possible by placing hardware independence where it > belongs. I WOULD USE A MORE MODERN EXAMPLE, BUT THERE ISN'T ONE. Hmmm. Can we say "Linux" boys and girls? > There is an incredible variety of CP/M machines. They range from really > simple to complex. Yet all of them can run CP/M software. For example, I > run THE SAME BINARY of KERMIT on my DECmate II and on my Televideo 802; > these machines are about as far apart as you can get. [SNIP] Well if CP/M is so fantastic and portable, THEN USE IT!!!!! > In x86-land, if I'm going to use a DOS program to do file transfers, I'd > dang well better have a 16450 or compatible UART. Suppose I need to > occasionally do HDLC? Fine, but you also have to carry around the 16450 if > you want to speak to modems. In CP/M-land, it's possible to use, say, an > SIO as a UART most of the time and HDLC occasionally. Well then USE CP/M!!! You keep complaining DOS doesn't do this and it doesn't do that, but CP/M does this, AND it does that. So, _USE_ CP/M. What is the problem? That is like me saying that Windows doesn't run on my 8088, but DOS does, and complaining till DOOMSDAY that Windows should be more portable. > > > MSDOS > > is an x86 OS, however TC1.5 is an "IBM-PC or 100% compatible PC > > running the DOS operating system" program. > > But there's no good reason for TC1.5's command line compiler to be tied to > the PC architecture. Sure there is. Borland said "Lets design a C compiler for the IBM PC." Then they did it. End of story. > Similarly, there's no good reason for DIR to do direct > screen writes. That is a perfectly valid *opinion*. However, there *IS* a perfectly good reason for DIR to do direct screen writes, I want it to, so do many others. I will configure it to do so too. If you feel that you dislike direct screen writes, then be sure to configure it to NOT do them. Simple. > Do you expect ls to do direct screen writes under Linux? Why > not? It's also a PC operating system. ls writes to the screen amazingly fast in Linux. Although I don't have the sources handy, I'd bet that it does use direct screen writes.. If it doesn't, then it must go through some blazingly fast interface to video memory. An ls under Linux goes about 4 times faster than a DIR under DOS *WITH* direct screen writes!!!! Don't ask me why, but it does. Must be file access speed or something. Oh, BTW, Linux is *NOT* *JUST* a PC OS. It is also for 68k, DEC Alpha, Sparc, PowerPC, MIPS, ... I'm sure an ls is just as fast on those machines under Linux as well. Also, even if ls doesn't do direct writes, it IS POSSIBLE to write a version of LS for Linux that DOES do direct writes so your argument is pointless. I've written a couple programs for Linux that do direct screen writes in text mode and they work great. I don't much care that they don't work over a serial line as I've written them for me and anyone I'd be giving them to uses the console anyways and would appreciate the effort I've put into making the video code scream. (It would take me about 6 hours to put conditional code in to make them work over serial lines as well). > > If all programs were made without using any direct hardware > > access, then all programs would be written in ANSI C and run over > > VT100 terminals and be SLOW, NON-GRAPHICAL, and BORING. > > I'm not complaining about "all programs". I'm complaining about the > operating systems. If you want fast DIRs, by all means write an alternate > shell that does fast DIRs. Just don't put it in the operating systems. A command shell as NOT an operating system. A shell is a program just like any other on the system. Your above statement doesn't make much sense. > > (Besides, that is what VMS is for. :o) > > I'll tell the half a dozen VAXen in my basement that you care. I don't though. > > The whole point of this posting is to try and make people who are > > using older equipment understand WHY new programs may NOT work on > > their computer, and WHY a lot of people WANT new features that > > might not work on older computers. > > Again, my primary concern is not old machines, but embedded ones. If I'm > building a special-purpose widget, I shouldn't need to make it 100% PC > compatible just because the widget happens to need an operating system. Apples != oranges. I said that my point was to make people understand that newer programs wont work on their "computers", not their microwave ovens. > The embedded market is large and thriving. I realize embedded PCs arenot as > large a market as desktop machines, but they are still an important one. Yes, the embedded market is large. But I am talking about MSDOS which is an IBM-PC OS, and programs written for that architecture and operating system. My concerns towards IBM-PC/MSDOS software working on ANY embedded systems are about on level with my concerns of IBM-PC/MSDOS software running on a VAX, or a VIC-20 for that matter. We're dealing with 2 different worlds. > Have you any idea how many processors are in the PC sitting on your desk? No, please tell me. It's an ACER 486-DX2/66. Besides, my PC isn't on my desk. :o) Mike A. Harris | http://blackwidow.saultc.on.ca/~mharris Computer Consultant | My webpage has moved and my address has changed. My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html mailto:mharris AT blackwidow DOT saultc DOT on DOT ca Close windows, and OpenDOS! http://www.caldera.com/dos/dos.htm