On Tue, Apr 10, 2012 at 10:37 AM, Alex <alxm...@gmail.com> wrote: > This topic is not about DOS vs other operating systems, or the fact > that users tend to gradually abandon DOS. It's about the survivability > of DOS vis-a-vis hardware.
> The starting point for my reasoning is: what will happen with the > future development of the hardware architectures? So far DOS has fared > relatively well, in the sense that it can still run even on 32bit and > 64bit architectures, despite the fact that it does not fully support > them. Now the question is: will it always be like this? Or will there > come a point when, due to a radical CPU redesign, we won't be able to > even use DOS any longer on newer machines? What are the chances of > this happening? That's a matter of the marketplace. DOS was originally for and run on CPUs using the Intel X86 instruction set. Subsequent Intel CPUs were backwards-compatible, in that they *added* new processor instructions, but the old ones were still there. You could successfully run code compiled for an 8086 on an 80186, 80286, 80386 or Pentium. The X86 is a "segmented" architecture, but as CPUs moved to 32 bit and 64 bit addressing, what this meant was that the size of a segment increased. (On a 16 bit 8086, a segment is 64K. On a 386, a segment is 4GB.) The old code couldn't take advantage of the newer features provided by the CPUs, but it still ran. Current machines won't *boot* DOS, but will *run* it in a compatibility box, emulator or virtual machine. If you have a different architecture, bets are off. Many mobile devices use CPUs based on the ARM architecture, and DOS *won't* run on those. Linux will, and Windows 8 has been ported to it. (For that matter, ARM is positioning itself to make a run at the server space with its newest offerings, because they are a lot more power efficient than Intel chips, and power usage is a major issue for folks running any significant number of servers.) On those platforms, you would need an emulator of some sort that would convert X86 instructions to appropriate ARM instructions for execution. This is perfectly doable - back when Palm migrated from using the Motorola Dragonball CPU to ARM CPUs, they implemented such an emulator that converted MC680X0 instructions to ARM code for execution, so the existing code base of thousands of Palm apps continued to work. It was possible for programmers targeting Palm OS 5 on ARM to write ARMlets to speed up time critical operations that could be included with the standard MC680X0 code generated by the existing Palm development tools, and some did. (It was *not* possible to write an app *entirely* in ARM code, as Palm provided no SDK for it.) But creating such an emulator is a complex and time consuming task. I don't see it happening for FreeDOS - who can and would do it? > Related questions are: how adaptable would the (Free)DOS codebase > prove, in the event of this happening? How much manpower would be > required to recode/adapt (Free)DOS to the new needs? In short, could > DOS survive such a situation? It would require a total rewrite of the code base for portability. I don't see the resources being available to do it. > I know that this may look as an overly pessimistic scenario, but I > believe it's one we had better anticipate, rather than just assuming > that things will always be as they are now. I hope I am very wrong in > my reasoning, and I would be very glad if someone pointed it out. What time frame do you anticipate? Let's be realistiic: FreeDOS is a niche market product, aimed at an increasingly tiny niche. The vast majority of folks have no need to run DOS nor any interest in doing so. I run FreeDOS purely for fun, since I first started using DOS when the original IBM-PC was establishing itself and displacing things like Apple IIs used to run VisiCalc, and it's a bit of pleasant nostalgia to play with it and run old DOS apps. But I don't *need* it, and if future changes in technology make it impossible to run it, it will no longer be used and I'll bid it a wistful farewell. Life will go on, and my world will *not* come to an end. > Alex ______ Dennis https://plus.google.com/u/0/105128793974319004519 ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
