From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Tue, 8 Sep 1992 08:17:29 GMT

In article <id.VSXS.W68@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Sep1.224833.27021@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> This is a crock.  Industry acceptance of MS-DOS since the inception of
>> V 2.00 means that there is no such problem.
>
>Except for the problem caused by the inability to make any substantial
>improvements to DOS because it'd break all the critical applications. Microsoft
>eventually had to invent not one but *three* new operating systems, and they
>*still* have to retain very low level DOS emulation to get any market share.

There are no such systems accepted in the Real World (tm).  Microsoft has
been attempting to get OS/2 down the throats of users for years.  BTW, much
runs on it *slower*, although there are certain applications that are DOS
pigs that run better by brute force.

>
>> I don't use MS-DOS, I use
>> DR-DOS, which is a compatible superset.  Frill features of the hardware
>> are seamlessly added, not required.  My code just runs slightly faster; 
>> the alleged improvements are overblown when it comes to actual performance
>> improvement.
>
>If your programs were written in high level code, and you'd recompiled them
>with a 32-bit compiler, you'd have seen substantial performance improvements.
>Native 386 code is so much faster then 8086 or 80286 code that insisting you're
>sticking with 8086 because assembler is more *efficient* is insane!

As has been stated before, the 32-bit mode runs *slower*, not faster.  All it
buys you is a larger, albeit clunkier, address space you may not need.
Furthermore, the '286 mode is large enough for any sane program for this
class of machine.  Trivial reassembly for most purposes gets you compatibility
with this environment.  Microsoft has been telling developers for years how
to do this in all languages, including assembler *and* C.  But few sites
actually care.

>
>> In summary, the answer is yes, the same exact environment, surrounded
>> by a lot of optional shit that can be 100% ignored.
>
>And you think this is a good thing? The DOS environment is a concrete prison
>on the edge of a blasted war zone, pockmarked with bullet holes, held together
>by phenomenal programmers using knotted rebars and their own muscles. The tools
>are mostly toy versions of the real thing, with lots of pretty colors and
>exciting plastic mouldings  stuck on the side... but they won't do basic
>things like cut standard sized planks. The exceptions are a few old leftovers
>from before the war that don't have any safety guards and have a habit of
>blowing out the whole prison's electrical system if you make a mistake.
>
>I'm sorry, I'm not interested in doing without that optional shit like clean
>air and properly grounded and insulated tools any more.

Your colorful language is amusing, but hardly either accurate or relevant.
For your info, OS/2 and followons are *compatible* with DOS file structures
totally.  The so-called HPFS is an option you can bring up on alternate
devices, and it runs *slower* except in contrived memory-hog applications, 
where it's only modestly better, which is a great improvement over noticeably
worse.

None of this has anything whatsoever to do with alleged ease of moving
applications from MS-DOS to OS/2 or whatever regardless of what it's
written in.  Yes, it won't work on unix, but by and large these people
just don't care.  Microsoft's compilers (and assemblers) can generate
dual compatibility code with no great effort.  In some cases literally
no effort.  In any case, tempest in a teapot arguments aside, you are
attempting to characterize something you apparently have no first-hand
information on.

There is more trouble in bringing some hll applications written for older
versions of VMS up to newer ones than anything you allude to here.  As to
the size of this so-called prison, there is something wrong if you can't
write useful code to run in 1/2 Meg or so.  If I need to go to OS/2, I'll
opt to avoid the overhead of '386 mode, and stick to the "prison" you
describe of program space of 16 Megabytes.

Your point of recompiling ease really wears thin:  If the program could've
fit in the original environment, then it will run in either.  Anyone who
uses recent Microsoft or Borland Languages gets for free the ability to
not even have to recompile for OS/2.  In any case, if I have to make
trivial changes, I will.  You have presented literally nothing to convince
anyone that the changes are anything but trivial.

In an earlier post, someone has attempted to claim that programs written for
the "minimal" hardware of earlier configurations are not what's run.
Sometimes this is actually true.  In those infrequent cases, we resort to
the excellent Windows support libraries of Borland where all we could possibly
need to easily create a veneer of a GUI already exists.  And of course it's
callable from any language, even C, as well as assembler.  In any case, 
because all of the "fight" has been removed for us, there is little change
in the "meat" of the code, even when such a "false front" is applied.  BTW,
it's rather inefficient this way, owing in part to the fact that much of
Windows is written in C.  So, the O/S you seem to think is so much faster,
actually materially slows down the execution speed of virtually every
program you could name.  Smarter users drop back to DOS to get the work done
if GUI is avoidable.

cjl