I've been trying to read this article: http://www.vanwensveen.nl/rants/microsoft/IhateMS_1.html

I'm still a long way from reading reading everything. But this struck me about XP: "What a great new product. Of course it makes sense to provide compatibility modes for old Windows applications, but to find the bulk of Windows 3.10 and DOS 5 (all of it 16-bit code) up to and including EDLIN, installed under the hood of Windows XP makes you wonder about the design principles that have gone into each "new" version of Windows."

Can anyone familiar with XP architecture confirm this? And as to how one can "see" this? By looking at the DLL's or something?

Took a quick glance through that article... Very interesting!

And, from the sentence right before the one you quoted:

If you look in some executables in the Windows directory, you find internal labels like "ProductName: Microsoft Windows (TM) operating system, ProductVersion: 3.10". There's even DOS 5.0 code with a 1981-1991 copyright date.

I've yet to verify this (need to start my Windows XP Virtual machine). Looks like the ProductVersion is set to 3.10 on some of the DLLs.

It's kinda true, in that all the old libraries are still around. I don't see why this is significant. Microsoft have done a lot of stupid and nasty things, but this really doesn't qualify.

Absolutely spot on! I don't know why people insist on using existing code when developing the next version of their product. The only way to get a successful product is to deltree/rm your entire source folder before you even consider releasing Version++.

If, like Microsoft, you base a lot of your strategy on backwards compatibility, you may be tempted to keep old libraries around for this purpose. If you are considering this, STOP! This will only prove to the entire world that you cannot innovate, and just reuse any old rubbish that's laying around in your bin directory. Wanting to be a forward-thinking company, you should instead clean room reverse-engineer your own libraries, applications, and protocols.

 

Tune in next week for my rant against Ford et al all reusing the same old engines and wheels for every new car, but just tweaking it a little bit. Do they hate innovation or something? Really, we're all just driving around in the same old Model T!

START REINVENTING THE WHEEL, PEOPLE!!
 

The latest version of most UNIX-like systems includes standard utilities that date from the 1970s.  Of course, at least the old utilities are just "experienced" and not simply left to rot like most of Microsoft's legacy apps (I'm looking at you, Notepad).

djork:

The latest version of most UNIX-like systems includes standard utilities that date from the 1970s. Of course, at least the old utilities are just "experienced" and not simply left to rot like most of Microsoft's legacy apps (I'm looking at you, Notepad).

Except perhaps for cpio. 

c3pio?

It's not too tough to see this. EDLIN.exe is present in the system directory, and is still a DOS application. Win16 applications still work (mostly), so the old libraries are present.

But I can't understand people who scoff at MS because of backward compatibility. Heck, I have an old game (Win32, though), that uses DirectX 3a and it still runs perfectly. (Well, actually not, but not because of incompatibility, but because the translators screwed up. Now translators are ones who I might rant about. Anyway, it's still possible to run it with a minor tweak to the executable). It's a plus that you are still able to use DOS applications without emulators. Surely, the Windows codebase would be cleaner if not for this compatibility cruft, but I think it's worth it.

What's up with cpio?

Spectre:

What's up with cpio?

Nobody has wanted to use the horrible beast in over ten years, and it shows. 

asuffield:

Spectre:

What's up with cpio?

Nobody has wanted to use the horrible beast in over ten years, and it shows. 

Oh yes, it's been updated in the last 10 years.  It's called RPM now, and still just as much of a WTF*.

* Ok, ok, I exaggerate a little.  RPM is a container format that adds dependency tracking and other stuff, but the archive with the actual stuff in it is usually a cpio.  And I'm not about to take back the "it's a WTF" comment.  I switched to Slackware largely because it has a better package management system--mind you, Slackware uses all-but-bare tarballs for package management.  Debian based systems are your best bet for good package management.  Also, I'm bitter because the build system at work uses RPMs, and it is a gigantic monster of a WTF.   

Spectre:

It's not too tough to see this. EDLIN.exe is present in the system directory, and is still a DOS application. Win16 applications still work (mostly), so the old libraries are present.

But I can't understand people who scoff at MS because of backward compatibility. Heck, I have an old game (Win32, though), that uses DirectX 3a and it still runs perfectly. (Well, actually not, but not because of incompatibility, but because the translators screwed up. Now translators are ones who I might rant about. Anyway, it's still possible to run it with a minor tweak to the executable). It's a plus that you are still able to use DOS applications without emulators. Surely, the Windows codebase would be cleaner if not for this compatibility cruft, but I think it's worth it.

There are far better ways to accomplish this task.  My Linux system is capable of playing DOS and Win95 games flawlessly*, but there is not a single line of code in my OS proper dedicated to compatibility with these horrid excuses of operating systems.  I have a QEMU install with FreeDOS and a copy of Win95 I found on eBay.  It works great.  Better, in fact, than trying to play these games in XP without resorting to emulation or a VM of some sort.  Win95 actually runs faster on my machine in its virtualization environment than it ever did on real hardware of the era.
 

* For definitions of "flawlessly" meaning as well as the original, buggy systems ever did.

phaedrus:

asuffield:

Spectre:

What's up with cpio?

Nobody has wanted to use the horrible beast in over ten years, and it shows. 

Oh yes, it's been updated in the last 10 years.  It's called RPM now, and still just as much of a WTF*.

It's still a horrible beast that nobody wants to use, and I dispute that it has been updated in the past ten years.

It is more of a WTF though. Even dpkg's source (written in iwj-C) looks attractive compared to the monstrosity of the rpm tree.

phaedrus:

accomplish this task.  My Linux system is capable of playing DOS and Win95 games flawlessly*, but there is not a single line of code in my OS proper dedicated to compatibility with these horrid excuses of operating systems.  I have a QEMU install with FreeDOS and a copy of Win95 I found on eBay.  It works great.  Better, in fact, than trying to play these games in XP without resorting to emulation or a VM of some sort.  Win95 actually runs faster on my machine in its virtualization environment than it ever did on real hardware of the era.

For DOS programs (like the original DOOM), DOSBox (together with FreeDOS) on Linux also works very well. Even programs that do low-level hacks with the VGA work as expected.

Raptor, and old DOS top-scrolling shooter, has never failed to operate perfectly under whatever circumstances. I believe it to be the most perfect piece of software I have, given that it also provides ample entertainment in the form of blowing lots of stuff up.

Tyrian is fun too (two player coop is annoying when you do NOT want to merge the ships though). Haven't had a problem running it in any environment (FreeDOS, DOS 6.22, DosBox, Win9x, Win XP).

phaedrus:

asuffield:

Spectre:

What's up with cpio?

Nobody has wanted to use the horrible beast in over ten years, and it shows. 

Oh yes, it's been updated in the last 10 years.  It's called RPM now, and still just as much of a WTF*.

* Ok, ok, I exaggerate a little.  RPM is a container format that adds dependency tracking and other stuff, but the archive with the actual stuff in it is usually a cpio.  And I'm not about to take back the "it's a WTF" comment.  I switched to Slackware largely because it has a better package management system--mind you, Slackware uses all-but-bare tarballs for package management.  Debian based systems are your best bet for good package management.  Also, I'm bitter because the build system at work uses RPMs, and it is a gigantic monster of a WTF.   

Did you know that a debian package is an ar archive under the hood? (it contains a small text file and two tar files).

ammoQ:

phaedrus:

For DOS programs (like the original DOOM), DOSBox (together with FreeDOS) on Linux also works very well. Even programs that do low-level hacks with the VGA work as expected.

Ahh, good old Doom.  I still play it using an (I think) open source engine called Doom Legacy.  Lets me take advantage of today's larger screen sizes, jumping, and angling up or down.  I recommend it.  Also, it makes loading new .wads easy.  Star Wars Doom FTW!

phaedrus:

* Ok, ok, I exaggerate a little.  RPM is a container format that adds dependency tracking and other stuff, but the archive with the actual stuff in it is usually a cpio.  And I'm not about to take back the "it's a WTF" comment.  I switched to Slackware largely because it has a better package management system--mind you, Slackware uses all-but-bare tarballs for package management.  Debian based systems are your best bet for good package management.  Also, I'm bitter because the build system at work uses RPMs, and it is a gigantic monster of a WTF.   

Ignoring the internals of RPM, I find its biggest WTF is the dependency hell you go through when un/installing anything non-trivial. RedHat's official RPMS like to link against everything under the sun. Why is that if you remove a trivial (say) Gnome package that you'll never use, RPM wants to remove the entire Gnome system?

Yum helps a bit, but it's so extraordinarily dog slow compared to apt, the only fair analogy is playing a modern FPS shooter at 1600x1200 @ 120hz on a 70's style TTY printer.