---------- Forwarded message ---------- Date: Fri, 30 Nov 2001 16:29:24 -0500 From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Reply-To: LifeRaft <[EMAIL PROTECTED]> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Subject: Re: +[SurvPC] please visit http://www.drdos.org Barry, Alex, [ ... ], (* Warning, long dissertation follows *) I remember the original "PC compatibility" wars. I remember clearly the Victor 9000, Zenith 100/150/etc, DEC Rainbow, and others. Some of these machines were clearly better in all practical respects than the IBM offering, however the same thing that brought Apple back from the brink killed off all these better machines: a spreadsheet that was so hardware dependent that it would only run on something that mapped its keyboard, video memory, and DOS/BIOS features to match the IBM PC exactly. Lotus 1-2-3 was the *classic* example of bad programming practice and complete lack of portability, and yet people made it the benchmark. The question I heard most in the computer retail stores was, "will it run Lotus?" not "is it standards compliant?" No matter how often we told people that the Zenith or Victor followed all the documented APIs, all they wanted to know was, "will it run Lotus?" Apple never acknowledged the debt it owed to Dan Bricklin, and IBM never acknowledged the debt it owed to Lotus, but in the end it was the application that made the difference. And so to DOS. DR-DOS was (and is) standards-compliant. It exceeded the standards, improved on the standards, but it complied completely the the *documented* APIs, and with many that weren't. Unhappily, there is software that was written using parts of MS-DOS that weren't documented to the general developer population, and will only run on MS-DOS (and sometimes on PC-DOS). Some of it exploited "holes" in the API and/or "features" (bugs?) in the OS in order to get things to happen, and this software is condemned to run only on MS-DOS. If you depend on this software, you're stuck with MS-DOS. And what of standards? CP/M was a standard. The one thing you *knew* was that you would never know what hardware your software was on. You wrote to the documented API only. When MS-DOS came out, it performed so *badly* that bypassing the OS and BIOS was the only way you got speed. There is a *documented* API standard for DOS. Anything written to *that* standard will run on *all* the flavors of DOS. Most of the software I ever wrote for DOS (excepting low level drivers) will run on any MS/DR/PC/?? DOS. In fact, I can recompile most of it to run on Unix or Linux. Why? I largely stayed away from the tricky stuff that locks you into a piece of hardware or a one-vendor-only version of the OS. Compatibility? If your favorite application was written by someone who sacrificed standards compliance in favor of performance or other advantage then, for you, compatibility means "will it run my software?" and if you want access to *everything* ever written for the platform then, for you, compatibility means "will it run everything?" On the other hand, if you are a developer, writing for the broadest possible acceptance then, for you, compatibility means "can I get my software to run on *all* of them?" Now, I have no idea (ok, yes I do) of the marketability of stressing "my software runs on today's version of the OS and because I wrote to the *standard* my software will also run when you upgrade." Clearly today's leading desktop vendor isn't interested in pushing that concept. For the SurvPC crowd, I'm not sure what active development is still being done, but at least the OS and its APIs are known quantities, and the developer isn't going to get an ulcer worrying about whether his latest cool thing will be made obsolete by the next version of Windows. Those with short attention spans should stop here. There are two more variations I'll address: 1) where have all the standards gone 2) the power of de-facto standards to motivate solutions [1] There is a world where standards carry weight. If I were getting into programming today for the first time, I would ask, "which OS will preserve my efforts and allow me to create moving forward rather than continually 'updating' my software to follow a moving target?" The only environment I know of today that doesn't make one's knowledge obsolete every two years is the Unix family. The hardware is pretty much irrelevant to the application software developer, and the standard is king. [/1] [2] Early in the '80s dBase established a de-facto standard for desktop database management and programming. It made possible the development of ad-hoc database applications on a scale suitable and economical for small businesses. It took hold, and immediately there were clones: Clipper, dBXL/QuickSilver/Arago, Force, FoxBase/FoxPro, and others whose names I've forgotten. These became known as the XBase family of languages (dialects, actually). (Incidentally it also provided a foundation of legitimacy for other desktop database products, including Paradox, Access, Rbase, Revelation, Pfs-File, and so on.) Years passed, and it looked like FoxPro was going to win the benchmark battles, with Arago/dBXL in second place, but MS bought Fox Software and Borland bought WordTech as well as Ashton-Tate. Computer Associates bought Clipper from Nantucket and tried to evolve it into a thing called "CA Visual Objects" which never really flew. MS began to circulate "death of FoxPro" rumors and pushed people toward Access and SQL Server. Borland seemed to get confused and lose its direction. It looked like, after more than 15 years of providing a de-facto standard, dBase and its clones were about to wither and die. MS has finally discontinued work on FoxPro (sniff) and CA has stopped evolving Clipper, leaving dBase pretty much alone in its current incarnation, with the business world migrating toward the Access/SQL Server models. However, two decades of programming genius and billions of dollars invested in millions of lines of code worldwide does not go quietly into the night. (Remember COBOL?) In Germany, Holland, and other EU countries, where software engineering is still a science, programmers created not one but several solutions to keep their software investments alive. Alaska Software (Germany) has created "xBase++" which is a native 32-bit Clipper-compatible compiler with Windows GUI extensions and ODBC connectivity. Extended Systems (USA) has created the Advantage Database Server, which gives Clipper clones client/server capability. Multisoft (also Germany) has created Flagship, a Unix-based Clipper clone. And finally, E&T Company (Russia?) has created Clip, an open source Clipper clone for Linux. Academic issues aside, programming is a practical science -- an engineering discipline, really. The economics of writing software dictate that you get the job done, producing usable software, in a viable amount of time, for a viable cost. The XBase dialects make this possible. The language is quite strong in its own right, and the database model can be adapted to just about anything. I'm not trying to sell XBase, I'm pointing out a phenomenon. When a software concept clearly has value, it will accrue champions who will keep it alive even after its creators have abandoned it in favor of more popular "solutions" in pursuit of market share. So it is with XBase. So it is with Unix. So it is with DOS. [/2] So pick your favorite flavor of DOS and make sure you have one handy for those cold nights when your Windows fire sputters and dies. Just rub two DOS disks together and, presto, you have your fire back. Regards, Garry [EMAIL PROTECTED] Original Message: ----------------- From: Barry [EMAIL PROTECTED] Date: Fri, 30 Nov 2001 09:45:42 -0600 To: [EMAIL PROTECTED] Subject: Re: +[SurvPC] please visit http://www.drdos.org > > ----- Original Message ----- > From: "Alex Venn" <[EMAIL PROTECTED]> >> >> Since DRDOS has been my choice for many years I'm obviously >> in large agreement with you, but I wouldn't go as far. >> DRDOS doesn't have to crash, hang-up or malfunction in any >> way for it to be incompatible to some extent with MSDOS, it >> just has to do something differently. However, we may disagree >> on what compatible means. To me it means that *any* package >> which works with MSDOS will work with DRDOS. We can argue >> about the reasons if it doesn't, but to my mind, if a program >> doesn't run on DRDOS exactly as it does on MSDOS, DRDOS is >> incompatible with MSDOS. > > You're treating "compatible" as binary. It is or it isn't. I > suppose that's as valid as treating it as a measure and > discussing how compatible something is. But I think discussing > the degree of compatibility is more common and more useful. > > If you do want to treat it as a yes or no issue, then how about > "If it does what you want it to do, it's compatible and if it > doesn't, it isn't". > > Barry -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .
