nemesis wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Because you had lots of OSes called UNIX that weren't compatible with
>> each other, even at the source level.  (See autoconf)
> 
> that only happens when you exchange a common API for platform-specific APIs that
> do the same thing faster or funkier.  It happens even in Java.
> 
> It doesn't really happen in M$ because there really is a single vendor with a
> single set of solutions and they can cram old APIs to handle old code in their
> newer products with newer incompatible APIs.

Yes. And how does that mean that MS didn't cause that to happen?

>>> Win9x did not support DOS programs: they simply had DOS included to handle
>>> those.
>> DOS programs ran in a window, just like they do now.
> 
> It runs in a window because that's how graphical ambients run console programs:
> by opening a window terminal and letting the console program do their job.  It
> doesn't magically transform them into full graphical programs with graphical
> drop-down menus.

Who said anything about graphics, let alone magic?

>  The OS calls such programs did were DOS calls and such calls
> are still supported these days by letting an emulated DOS handle those.

Yes. But there's also a whole bunch of things the old code did that 
didn't go through APIs, like writing directly to screen memory or 
invoking hardware INT calls. Those got caught and emulated too.

> So they can afford to provide their older APIs together with the new.  It's
> their own code, it's not really "2 different OSes"!

The program runs on two different OSes. Of course, to make this happen, 
the new OS has to support the old API. I'm not sure which of my 
statements you think you're disputing here.

>> So, different operating systems. You're making my point for me. :-)
> old code still handled by old code, not new.

Not true. What's the code in DOS that handles writing to screen memory? 
Where's the code in DOS that handles moving the cursor via IBM BIOS calls?

> last few years and while the bugs are certainly different than those of MS
> software, there doesn't seem to be as many or as little as those.

And Linux still isn't as big as MS. Yes, MS has more bugs per line of 
code than Linux.  About 2 or 3 times as many, last study I saw. But MS 
is a commercial concern.  The bugs that MS has don't seriously affect 
their profitability. (Well, before Vista, at least.)

> So, why is the single largest and richest developer in the world with so many
> bright minds and a single set of enforcement rules over their developers about
> code quality and API standards get rivalled by ad-hoc developers from around
> the world working on many different little pieces of software that eventually
> get assembled into a Linux distribution?

I'm not sure. I'd guess it's because the people working on Linux don't 
have nearly as much backward compatibility problems, and they don't have 
nearly as many cost concerns. I.e., if there's a bug in a popular Linux 
application, Linux kernel authors don't add code to the kernel to work 
around the bug - they fix the bug in the application. MS doesn't really 
have that option. Plus, if there's a problem with Linux, the person who 
fixes it is the person with the problem. With MS, the bug in the OS gets 
fixed for the customer only if it's worthwhile to MS, not if it's 
worthwhile to the customer. Economics is always skewed by having the 
benefits go to someone other than the person paying.

> It seems to me MS crappy, crippled software is such by design, so people have
> always a reason to update.

I'm sure there are decisions made to ship less-than-optimal products 
that can have an upgrade path. Every commercial company does this, 
monopoly or not.

On the other hand, I've been getting free updates and bugfixes from MS 
for years and years. So I'm not sure what incentive you think they'd 
have to ship buggy products if they're going to fix them for free.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message