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
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.
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.
Freedos-user mailing list