Hi howard!
03 Feb 2002, [EMAIL PROTECTED] (howard schwartz) wrote:
hs> I must admit the hardest part for me of abandoning Dos, is losing
hs> a whole lot of programs I love that will never be ported to Linux, and
hs> which I will never try to emulate by writing my own source code for.
Same with me ...
Linux works GREAT for my little server which is connected 24/7 to the
internet ... but I still have not completely switched to linux on the
desktop :(
>> The 386 offers extreme power, and DOS is not able to use it.
>> All later processors offered only speed improvements, but the 386 lay
>> the basic for modern OSes. (486 integrated FPU and cache, and was
>> slightly pipelined. 586 fully pipelined, and superscalar (can execute
>> up to 2 commands per clock. 686 integrated 2nd level cache on the die,
>> speculative execution of up to 3 commands per clock.)
hs> I get from this that inherent dos limits prevent it from running fast
hs> hardware devices, thinks like USB ports and firewire and so on with
hs> the proper speed.
I guess that if somebody wants it very much it would be possible. (ie DOS
limits don't prevent the usage)
The problem are the not existing drivers.
I don't see any limit except the copying of data from conventional mem to
XMS and back.
hs> I did not know that. It makes me wonder why some
hs> versions of dos are so popular for use with embedded devices.
Embedded devices are not I/O bound ...
if it takes 10% longer to load something from a 7500 rpm disk, than you
will not even notice !
hs> Lineo or whatever their name is now sells version 7.3 of Dr. Dos at
hs> quite a price as ``the perfect solution for your embedded devices''.
Hmmm ... last time I looked they tried to push openlinux for the same
purpose.
hs> The general story is how fast dos can be handling real time software
hs> process control. Seems to be a conflict of claims here.
In my oppinion embedded systems don't need realtime capabilities.
An embedded system in my point of view is for example a surf station with
arachne or dr webspy (or whatever the name was)
DOS is absolutely NOT able to deliver realtime scheduling ... DOS does not
provide any type of scheduling.
Even linux does not provide RT scheduling. (without RTLinux patch)
RT capabilities are seldom required ... except atomic powerplant control,
or realtime data analysis (the OS has to guarantee, that system calls et
all will under no circumstances take longer than x milli/microseconds)
>> There are some tries to evade DOS defficiencies.
>> Eg XMS to address more memory. This works so, that you load a driver in
>> DOS, which switches to protected mode (where you can address the RAM)
>> and copies small parts to under 1 MB if needed. Naturally this is
>> painfully slow (every mode switch is expensive, and the copying of the
>> data is also slow)
hs> ``Painfully slow'' really -- a few more fractions of a second for an
hs> application to do something?
ok ... I have exaggareted a bit ...
with XMS you are faster than DJGPP (DPMI) ... so maybe 10-15% slower than
with a mature OS.
But IMHO it is perverted to use such tricks, only to evade the huge design
flaws of a "bootloader" (here most people call DOS so, because it offers
no real OS capabilities like memory protection, multitasking, etc)
hs> Does this really compare to the speed difference, using any kind of
hs> comperable hardware of the 1K elegant dos program written entirely in
hs> assembler to the similar winblows program with 7 directories 16 dll
hs> libraries, and 300 files -- that does the same thing.
I guess DOS would be a bit faster ...
because a badly written win program goes through many win software layers.
And Win9X has also to go through "Thunking" layer, which maps 16 bit to 32
bit winAPI calls.
>> Eg 32 bit addressing.
>> DJGPP creates 32 bit protected mode executables - GREAT .... _BUT_ DOS
>> can't operate in Protected mode, so these programs have to switch back
>> to real mode, for every IO operation, and for every DOS service they
>> need. (read DJGPP faq Why are IO bound processes so slow) [PS: this is
>> the same solution as win9X ... switch to PM do your thing there, and
>> call dos functions in realmode if needed
hs> Never knew or thought about this. When dos has to do some I/O related
hs> thing for your -- back you go to real mode and 16 bit processing?
Sure ... DOS is not able to work in PM ...
hs> Do some of the newer doses, such as the DPMI mode for Dr. Dos, Free
hs> Dos, etc over come this limitation?
No ... DPMI _IS_ the limitation :)
it specifies how to switch modes, how to do syscalls, etc.
PS: DPMI was a invention of M$ ... so that 32 bit DOS programs could
cooperate with windows.
hs> Howard Schwartz
CU, Ricsi
--
|~)o _ _o Richard Menedetter <[EMAIL PROTECTED]> {ICQ: 7659421} (PGP)
|~\|(__\| -=> It is easier to admire hard work if you don't do it <=-
