What is it about Windows? Part I

So what is it in Windows that entices corporations, managers and developers to want to actually buy Windows? Sure, there's lots of cheap PC hardware available to run Windows but, other than MacOS X, you can put a myriad of operating systems on these hardwares other than Windows. Let's start by looking at Windows a bit more closely:

In the beginning (ignoring DOS), Windows was first designed as a desktop operating system for a single user
With kludgy changes and over time, Microsoft bandaged the OS to support multiple users (but not simultaneously... you have to buy a server OS for that, and even that has issues). Windows was born out of a non-multitasking OS (DOS) and, again, with some bandages, once again added a, sort of, pre-emptive multitasking kernel (thanks to a VMS guy). Another kludge, if you ask me.

These changes were not fundamental ground up changes. They were add-ons... after thoughts. This is the entire problem with Microsoft and their design philosophies. They don't work on redesigning, they work on patching. If the OS can't do something, they just add on a patch and the problem is solved. Like, .NET. Yet another add-on library. This was not a fundamental OS change, they just changed out an old previous framework and development system and introduced a new 'better' (patched) framework to handle Internet development functionality. The OS wasn't altered or modified or redesigned to make room for .NET. It's just another patch.

What's wrong with patches? Well, nothing, if the code you're trying to fix is actually broken. But, if you're making new design changes or making a paradigm shift, implementing that change as a patch is just a kludge. It means, as a developer, you didn't try and rework other parts of the OS to actually and properly integrate the code. Of course, one could argue that by adding the DLL, that it does become part of the OS... well, yes and no. The OS had no knowledge of this functionality until the DLL was dropped in place. Therefore, it's still just a patch. Of course, you could argue that the OS was designed properly to support extensions. Since the advent of shared libraries (originally introduced in UNIX), otherwise known as DLLs on Windows, that has been possible with most operating systems.

Filesystem design issues...
Of course, here's another different issue. The OS is still, to this day, laid out in the same filesystem design is Windows 3.1! Another prime example of patching! Moving to Windows XP (or even Vista), you'd think that we could finally get rid of the Windows, System32, Program Files, Program Files/Common directories as well as config.sys and autoexec.bat and actually design each application to be self-contained (let's take a page from Steve Jobs and his design for the .app folder).

Better, let's actually create an actual and proper startup routine for the OS (so you know how to get things to properly start up when Windows loads). We'll come back to the startup issue. There should be one single location to load common system DLLs. But these DLLs should never be touched, modified or altered (other than by vulnerability patches). Again, these DLLs should be left alone and stand alone. No application should ever add DLLs to this directory. All DLLs for an application should reside in its own structure within its own app directory (self contained). There is no need to strew tons of DLLs (and other files) all over the filesystem in tons of different places. It's no wonder that Windows ends up degraded over time with all this extraneous garbage being left out there running even after the application is deleted from the system.

Common Files?
Why is there even a Program Files/Common Files area? If I request an application to load on drive D, why is it that it still has to load garbage onto drive C? This issue should have been addressed YEARS ago. Why is it still placing stuff onto C? And here's another issue. Why are we still using single letters to refer to drives? Why can't I access my stuff by using Data: or some other alias? We'll come back to drive letters later.

Shells and Scripting
WHEN WHEN WHEN will Microsoft get rid of the command prompt (both CMD and Command) and actually replace it with an actual shell that has a real scripting language available? Batch scripting? Heh, that is so basic it can't even be called a scripting language as it has very limited and unusually constructed conditionals. It's intended for quick batch jobs. Definitely not for scripting. WSH you say? That thing is so kludgy and Windows-GUI-centric that it's not even funny. Plus, the language is not even that standard... yes, it looks a bit like Visual Basic, but it really isn't. Just give me a shell that has full fledge conditional scripting built in. I don't want to have to call cscript or some other command that interprets my script and then doesn't work properly half the time. There really is no good way to automate command line tasks in Windows. Yes, I can add on Python, Perl or even Bash as an add-on. But, something should be included out-of-the-box!

Task Scheduler and running scripts
Yes, there's 'Task Scheduler', but again this is yet another kludge that's dependant on IE. IE? Why the heck is Task Scheduler dependant on IE? So, if you get some kind of virus or malware (very easy with IE), Task Scheduler can easily be corrupted and no longer work. Worse, anything you run through Task Scheduler has to open that stupid command shell window to run (if only briefly). So, when you're working on the console, you have to endure that stupid black command window popping up to run periodic tasks. There is no way to suppress that thing. Such a great idea for task scheduling! Sure, I can go out and get CRON or some other UNIX ported tool for Windows NOW, but I shouldn't have to do this.

Filesystems / NTFS and data storage
Don't get me started on NTFS (written by Veritas). Ok, I will. Linux offers at least 5 other filesystems that are available for use based on the type of data and performance needs. Most of these filesystems get updated regularly, support journaling and various other advanced recovery tools (not to mention that they were designed for exceptional performance). NTFS hasn't really been touched since NT4. Sure they did a few things to create NTFS version 5. But those changes were so minimal as to not be worthwhile (mostly to do with large sized disks and large files). However, if NTFS gets corrupted, there really are no tools to fix this issue other than chkdsk which is only barely functional. Thanks Veritas! And NTFS can and does get corrupted. I can only recall once having corruption issues with a Linux filesystem which was likely related to a failing drive (and that was on EXT2, not the current filesystems). With Windows, once the MFT (basically the FAT table) is corrupted, you might as well backup, format and restore (BFR). The catchall for MOST windows filesystem problems.

With advanced filesystems such as EXT3, XFS, JFS, ReiserFS, VXFS (Veritas' newer advanced filesystem) and others, there are MANY tools and safeguards to prevent data loss. With NTFS, these safeguards are just not there. Worse, Microsoft won't let these third party filesystem providers introduce these filesystems onto Windows as replacements for NTFS!!! I've already tried trusting NTFS several times and each time I've been severely burned. NTFS cannot even handle directories where the number of files exceeds about 15,000-20,000 files!! Once you reach the undocumented threshold on the number of files, the MFT (yes, the MFT can only be so big) overruns itself and begins corrupting the rest of the filesystem!! Worse, you try chkdsk, and that tool also overruns itself and begins corrupting the NTFS volume even more. Why WHY would you EVER trust mission critical business data to a filesystem that has NO recovery tools available other than chkdsk? There are not even third party tools! That's how closed NTFS is.

XFS, JFS and even EXT3 offer full fledged journaling. So, short of a bad head crash of a single physical drive, you're not likely to lose data with these other journaled filesystems. Even in this instance, you can sometimes use 'dd' to clone the drive and get much of the data back! Better, because the file systems are open source there are plenty of recovery tools! Even still, fsck is an extremely robust tool and behaves far far better than chkdsk ever has.

(continued in Part II)