Re:advantages of multiple inheritance
on
PHP 5.4 Released
·
· Score: 1
Fair enough. It seems like you should, but x86 is weird with registers. There's no way to address ip/eip/rip like you can the other registers. You can't do it with flags/eflags/rflags either. You have to push, mangle and pop (like you were suggesting in the post above). Weirdo architecture...
Re:advantages of multiple inheritance
on
PHP 5.4 Released
·
· Score: 1
The only way you can push the instruction pointer is with a call instruction. The only way you can pop the instruction pointer is with a ret instruction. So yes, you *could* do arithmetic on it and use call/ret as fancy push/pop instructions for the instruction pointer, but...why? What does it accomplish? Why not just use those instructions as intended, or one of the jmp instructions? I'm struggling to understand what value is gained by your method, if it's indeed different from using computed jmps.
Who was making money back then? Well, you had paid online services like AOL and CompuServe. Geocities pages just weren't there for making money...people had their day jobs elsewhere. Nowadays, companies that are web-only have to make money somehow and the money doesn't magically appear. Either you pay for the site, or there are ads. There's no magic.
You don't understand interfaces. They aren't just documentation. They allow you to actually do things that you wouldn't be able to do otherwise. Let's say you have an IDisplayable interface that provides some functions that let you pretty-print the contents of the object. Any object that belongs to a class that implements this interface can be assigned to a variable of type IDisplayable. The only methods you can call on a variable of that type are the pretty-print methods, but that's okay, because that's all you care about doing if you are just using the interface variable. Now you can create functions that take IDisplayable parameters. Any type throughout the hierarchy might implement this interface, but you don't care where, just that it has those methods. Without an interface, you must either restrict the functionality to a single class hierarchy, or rely on Object variables and reflection. Neither of these is desirable.
In C#, for example, you very frequently want methods that take an IEnumerable or ICollection of something, or return an IEnumerable. The actual object type might be List or an array or something more complicated. But you don't want to restrict yourself to one of those, because all you care about doing, for example, in taking an IEnumerable parameter, is looping through each element in the parameter. An array, a list, a dictionary or a method with the yield keyword would suffice. It allows you to specify desired behavior, not specific types. Without an interface, you'd *have* to ask for a list or an array or something specific and that would make the method less flexible.
In any case, it's not just about documentation, if it's indeed about documentation at all. It's a matter of functionality within the static type system. In a non-statically typed language, interfaces are obviously fairly useless (with some exceptions, like PHP's special interfaces that tell the compiler that your class can, for example, act as an array).
Re:advantages of multiple inheritance
on
PHP 5.4 Released
·
· Score: 2
Only if you are using an assembly language that lets you directly modify the program counter with normal arithmetic instructions. x86 does not let you do this. You must use one of the jmp family of instructions (essentially goto), or call/int/ret/iret (and related).
A skeptic is someone who really does look at the available evidence with a critical but open eye and who has the critical thinking skills to synthesize new knowledge and understanding from that, be it just for themselves, or for the world at large. The Fox News crowd does not generally fall into that category. They did not come to the global warming debate with the idea that it's a serious issue that must be examined critically and deeply. Instead, they come at it with the idea that it's all a big liberal conspiracy and can't possibly be true. That's not skepticism, that's just plain denial. There *are* skeptics (I mentioned that). A lot of the people who don't buy into global warming are not skeptics, but merely deniers. Likewise, there are people who buy into global warming without any critical thinking and so are just lemmings and bad in their own way. I won't defend them either.
Your middle paragraph makes a very dangerous and misguided point. There is, in fact, a big difference between a prophet claiming to speak for God and a scientist doing research and publicizing the results. The latter is actually verifiable. The latter's methods are public and known. The latter's methods must furthermore work and bear fruit. String theory gets laughed at here and elsewhere because it fails these things. And yet dogmatic religion last thousands of years despite countless pieces of evidence and arguments against it. No scientific theory would ever last that long if it had no truth value whatsoever. Bad science *does* get weeded out, even if it is politicized. In the end, there really is more value in coming up with the truth than just being right for the sake of being right. If global warming really is a big hoax, a big scientific blunder, it *will* be uncovered. Not through hacked emails or out-of-context quotes from a random climate scientist. It'll come out through actual, peer-reviewed science. Remember also that it's in the system's interest for global warming to be false. As such, any real evidence against it would have strong political backing.
No, that's a reasonable term for what many of them are. I'm not necessarily talking about the scientist with a blog who's a skeptic. I mean the legions of regular folks and politicians who believe, for no good scientific reason, that global warming can't be happening, or if it is, it just can't be because of humans. If you want a religion, there's one right there.
It's not a religion, well, except for the deniers, who will go to any length to stick their heads in the sand and distort, attack and otherwise misrepresent the complexity of the situation and the scientific findings thus far. It wasn't even a political issue until a bunch of conservitards decided that they didn't like the idea of giving up their precious oil-based lifestyle.
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.
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.
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.
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.
Slashdot Mirror
Fair enough. It seems like you should, but x86 is weird with registers. There's no way to address ip/eip/rip like you can the other registers. You can't do it with flags/eflags/rflags either. You have to push, mangle and pop (like you were suggesting in the post above). Weirdo architecture...
The only way you can push the instruction pointer is with a call instruction. The only way you can pop the instruction pointer is with a ret instruction. So yes, you *could* do arithmetic on it and use call/ret as fancy push/pop instructions for the instruction pointer, but...why? What does it accomplish? Why not just use those instructions as intended, or one of the jmp instructions? I'm struggling to understand what value is gained by your method, if it's indeed different from using computed jmps.
Who was making money back then? Well, you had paid online services like AOL and CompuServe. Geocities pages just weren't there for making money...people had their day jobs elsewhere. Nowadays, companies that are web-only have to make money somehow and the money doesn't magically appear. Either you pay for the site, or there are ads. There's no magic.
You aren't the guy I was replying to, but *he* said "Java interfaces" and I responded to that.
You said Java interfaces. In Java, they are not documentation. In PHP, you are mostly correct, as I indicated at the end of my post.
You don't understand interfaces. They aren't just documentation. They allow you to actually do things that you wouldn't be able to do otherwise. Let's say you have an IDisplayable interface that provides some functions that let you pretty-print the contents of the object. Any object that belongs to a class that implements this interface can be assigned to a variable of type IDisplayable. The only methods you can call on a variable of that type are the pretty-print methods, but that's okay, because that's all you care about doing if you are just using the interface variable. Now you can create functions that take IDisplayable parameters. Any type throughout the hierarchy might implement this interface, but you don't care where, just that it has those methods. Without an interface, you must either restrict the functionality to a single class hierarchy, or rely on Object variables and reflection. Neither of these is desirable.
In C#, for example, you very frequently want methods that take an IEnumerable or ICollection of something, or return an IEnumerable. The actual object type might be List or an array or something more complicated. But you don't want to restrict yourself to one of those, because all you care about doing, for example, in taking an IEnumerable parameter, is looping through each element in the parameter. An array, a list, a dictionary or a method with the yield keyword would suffice. It allows you to specify desired behavior, not specific types. Without an interface, you'd *have* to ask for a list or an array or something specific and that would make the method less flexible.
In any case, it's not just about documentation, if it's indeed about documentation at all. It's a matter of functionality within the static type system. In a non-statically typed language, interfaces are obviously fairly useless (with some exceptions, like PHP's special interfaces that tell the compiler that your class can, for example, act as an array).
Only if you are using an assembly language that lets you directly modify the program counter with normal arithmetic instructions. x86 does not let you do this. You must use one of the jmp family of instructions (essentially goto), or call/int/ret/iret (and related).
A skeptic is someone who really does look at the available evidence with a critical but open eye and who has the critical thinking skills to synthesize new knowledge and understanding from that, be it just for themselves, or for the world at large. The Fox News crowd does not generally fall into that category. They did not come to the global warming debate with the idea that it's a serious issue that must be examined critically and deeply. Instead, they come at it with the idea that it's all a big liberal conspiracy and can't possibly be true. That's not skepticism, that's just plain denial. There *are* skeptics (I mentioned that). A lot of the people who don't buy into global warming are not skeptics, but merely deniers. Likewise, there are people who buy into global warming without any critical thinking and so are just lemmings and bad in their own way. I won't defend them either.
Your middle paragraph makes a very dangerous and misguided point. There is, in fact, a big difference between a prophet claiming to speak for God and a scientist doing research and publicizing the results. The latter is actually verifiable. The latter's methods are public and known. The latter's methods must furthermore work and bear fruit. String theory gets laughed at here and elsewhere because it fails these things. And yet dogmatic religion last thousands of years despite countless pieces of evidence and arguments against it. No scientific theory would ever last that long if it had no truth value whatsoever. Bad science *does* get weeded out, even if it is politicized. In the end, there really is more value in coming up with the truth than just being right for the sake of being right. If global warming really is a big hoax, a big scientific blunder, it *will* be uncovered. Not through hacked emails or out-of-context quotes from a random climate scientist. It'll come out through actual, peer-reviewed science. Remember also that it's in the system's interest for global warming to be false. As such, any real evidence against it would have strong political backing.
No, that's a reasonable term for what many of them are. I'm not necessarily talking about the scientist with a blog who's a skeptic. I mean the legions of regular folks and politicians who believe, for no good scientific reason, that global warming can't be happening, or if it is, it just can't be because of humans. If you want a religion, there's one right there.
It's not a religion, well, except for the deniers, who will go to any length to stick their heads in the sand and distort, attack and otherwise misrepresent the complexity of the situation and the scientific findings thus far. It wasn't even a political issue until a bunch of conservitards decided that they didn't like the idea of giving up their precious oil-based lifestyle.
It certainly does have to do with those things, but it also has to do with real, actual science. False dichotomy.
You are indeed a crackpot. Strawmen are fun, no?
Clearly you don't understand how science works.
It might not. In any case, NP-hard doesn't mean unsolvable, it just means inefficiently solvable. Perhaps you are thinking of undecideability?
He explained it wrong. It's not about the constant, it's about using a non-deterministic Turing machine to solve in polynomial time.
No, we don't know that yet (that's the whole P=NP debate). The thing we do know is that they can be solved non-deterministically in polynomial time.
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.