Eww, that's awful that they did that on the Mac. It looks normal on Windows and Linux. Supposedly there is a hide playlist button somewhere. Maybe you can try a different interface skin?

What are you talking about? On Windows, at least, there's no "library bar". You can show and hide the playlist/library with a button at the bottom (by default it seems to be hidden). In other words, it looks the same as before.

Again, where to begin.

So I read that whole article. Few things surprised me as I already knew a lot of that stuff. It is well-known, for example, that the entire 3rd GB of each process's virtual address space is shared by all processes and writeable to some extent. This is a stupid compatibility hack. Sharing conventional memory, again, seems to have been a compatibility hack. The problem wasn't that Windows relied on DOS, but rather that it allowed too much DOS compatible to come roaring in and so the gates were opened and robustness was compromised. Note that the article only mentions areas of memory that were allowed to be writable by any program that shouldn't have been writable (or indeed readable). Nothing in the article stated that Windows really ran on top of DOS, with the exception of one statement "Win95 still rests on top of DOS", which is pretty damn vague. Again, there's no question in anyone's mind that Win95 and DOS had a relationship. The question is not about that. The question is whether Win95 was just a pretty graphical shell and DOS did everything else. The latter is patently false. Even this article wouldn't seem to dispute that. It readily accepts the idea of protected address spaces and VMs and multitasking and all that stuff. What it points out are places where that model is compromised in the interest of backwards compatibility and other hacks to make DOS drivers and legacy apps still work. One could open up address space holes on Linux if one wanted to, although lacking a DOS compatibility issue, there'd be no reason to do so.

On to your #2. I have performance monitor opened and I'm looking at context switches per second and I'm seeing values of ~2000 switches per second. That can't happen if your explanation (which is utterly bizarre) were true. In fact, if what you said were true, Windows performance wouldn't just be bad, it would be unusably abysmal. With the number of threads and processes active on a standard desktop system, if it could only switch threads about 80 times a second, nothing would get done. You couldn't get anywhere near 100% CPU usage because a lot of time would be waiting for threads to finish out their quantum instead of letting them yield and moving onto other threads while I/O operations take place. The problem here is that you simply don't understand how time-slicing works. And it's sad that you go on this big rant, based on an article that is really about adjusting some settings from the GUI (and is not an in-depth discussion about how scheduling actually works on Windows), when you clearly haven't the slightest clue. I mean, FFS, the article says that the time slices are meant to keep CPU bound threads from hogging the processor. CPU bound is the key phrase here. Any time a thread makes an I/O request, it's GOING to get switched out. Any time a keyboard interrupt arrives and there's a thread waiting on keyboard interrupt, that thread will get priority boosted and will get to preempt the running thread. Again, if it didn't do this, performance would be so poor as to be utterly unusable. The article talks a lot about priority boosting, which wouldn't make sense if every thread had to run for 15 ms before another thread was able to run. I'm actually flabbergasted that anyone would think that type of design even makes sense, much less would be implemented. It just blows my mind that you are that willfully stupid.

You didn't dismiss a damn thing.

Windows was an application that ran on the DOS shell, you say. First of all, the DOS shell was COMMAND.COM, which was essentially a command prompt that would dump itself and launch applications in a single-tasking fashion. It doesn't really run anything (except for batch scripts), it's just a launcher. Windows, nor anything else, could run on top of it. If you are talking about the DOS kernel, you again have some serious problems to contend with. For one, Windows was able to multi-task DOS applications, which requires virtual 8086 mode and a protected mode controller component (see the Intel manuals for more details). So Windows had to provide some sort of kernel to manage those DOS boxes. Additionally, Windows and Windows apps clearly ran in protected mode, which DOS doesn't run in. As such, Windows would, again, need some sort of kernel to manage the protected mode memory manager that DOS didn't have. So even if your oft-stated but always wrong idea that Windows was just a pretty shell on DOS, it was a pretty shell that had to do a lot of things that OS kernels usually do, severely weakening your point.

I'll also leave this here: http://blogs.msdn.com/b/oldnewthing/archive/2007/12/24/6849530.aspx

Now onto the next piece of bullshit. You say that no Windows OS is preemptive. I'm not even sure where you get this one from and I remain stumped after reading your statement several times. I don't see what the log clock has to do with whether the OS is preemptive or not (I should also mention that "log clock" isn't a thing and you really don't explain what your algorithm prints and how it's able to measure anything, really; also, running in a VM is a bad idea because the VM is multitasked by the host OS and most VM implementations use fuzzy timers since routing the timer interrupt to the guest is not a good idea). Then you say that Windows is time-sliced. Well, time-slicing IS preemptive multitasking. Otherwise, you have cooperative multitasking, because there's no guarantee that a program will ever give up control. Even the earliest Windows had to do a context switch to the kernel for interrupts, as did DOS, so that's not a relevant factor in cooperative vs. preemptive. Windows behaves the same as Linux in this regard, and every other modern OS. Since this is EXTREMELY well-documented, even in, e.g., academic OS textbooks, I'd like you to find me some sources that indicate that your definition of preemptive multitasking is real (actually, it'd be nice if you could explain what you actually mean, since I'm not clear what the distinction is that you think you're trying to make) and that Windows doesn't fit it.

Your link about DR-DOS does nothing to explain your point, at all. Nobody denies that DOS was booted first and from there, Windows was launched and was able to take over the system. Nobody denies that Windows used DOS functionality for some hardware access (more so in Win3.1 than in Win95). So what point are you trying to make here? Also, I mentioned HAL not to claim that DOS was NT HAL (it clearly isn't), but that it rather acted like one in a limited sense.

So, your post, which does nothing but parrot myths, proved nothing except your ignorance of some very basic concepts, such as how multitasking works, the difference between the DOS kernel and the DOS shell, and what print statements in a loop tell you about preemption. You ready to drop your delusions now that you've been thoroughly schooled?

I don't doubt it because I know the facts. The fact is that Windows 3.1 and later had a kernel called vmm386 which provided pre-emptive multitasking in 32-bit protected mode. Each DOS box was in its own VM and all Windows 3.1 programs shared a VM. In Windows 95, each Windows program got its own VM under this kernel.

The reason you can delete a file from DOS is because the filesystem drivers in Windows 3.1 would run in DOS, albeit invoked by Windows. That doesn't mean DOS ran the show. It just means that Windows farmed out some of the hardware interaction to DOS, using it as a sort of HAL. In Windows 95 and later, Windows had its own filesystem drivers. This is well documented if you bother to do a Google search on the subject.

It wasn't really just an application. It used DOS to boot and as a piggy-back for some device drivers, but otherwise, it was a real operating system. It was a shitty one, but it did, in fact, run the show.

And one could say that Linux is good for Linux programming, otherwise not so much. I wouldn't do Windows programming on Linux, or Mac programming on Linux. Each platform is really best at programming for that platform. For the stuff that's truly cross-platform (in your examples, Python and JavaScript are like that, but not C++), the story is a lot nicer than you are pretending it to be, perhaps out of ignorance. For all the examples you gave, there are either Windows-only solutions, or cross-platform ones. Heck, you can install and use Vim on Windows if you want. That's what I do. Eclipse runs fine on Windows. All the other IDEs run on Windows (Qt Creator, Code::Blocks, Visual Studio; and for Python: http://wiki.python.org/moin/IntegratedDevelopmentEnvironments -- note that all of them run on Windows, but not all of them run on Mac or Linux). All the major webbrowsers run fine (for JavaScript). All of the open source text-editors work on Windows, and there is a plethora of Windows-only text-editors of varying quality that are available to you. If you insist on using the command line, you can always install cygwin (people bitch about it, but for what one would need a Unix shell on Windows for, it does just fine). At worst, in Windows you end up using open source or ported software. At best, you get access to stuff that doesn't exist on Linux and you get to use it on a platform that's more stable and doesn't require you to reboot if you want to play games or do true Windows development.

Here's a weird case that happened to me. I was trying out Haskell and I found the experience better on Windows than Linux. I mean, both were frustrating since Haskell isn't a mature platform, but on Windows installed Leksah and the Haskell Platform was a breeze. On Linux, there were some issues. I managed to fix many of them, but I still find that Leksah runs smoother on Windows than on Linux. So there's that...

Almost all of the serious work applications and tools are on Windows, or on Windows and Linux/Mac. There are so many line-of-business applications that are Windows-only it's not even funny. Then there's Visual Studio, SQL Server (plus SSAS and SSRS), MS Office and so on. If you want productivity and you aren't coding in C or PHP, then Windows is the way to go.

Yeah, I have to lol at the people who still think KDE3 is super awesome. Both KDE3 and KDE4 follow more or less the same desktop metaphor, so whatever "dizzy usability heights" KDE3 had are also in KDE4. In fact, everything that was in KDE3 is in KDE4 in some form or another, but in a cleaned up, more flexible and yes, more configurable form. The only reason to still use KDE3 these days is if you have an ancient computer that can't handle KDE4.

There's no such thing as an ad hominem attack. There's the argumentum ad hominem fallacy, whereby the arguer attempts to say that the opposition is wrong because of some personal flaw. This is not that. It is a straight up attack on the man's character because of the things he's said. No ad hominems.