You however are making the assumption that everybody in Microsoft talks to each other. A most incorrect assumption. The reality is most likely that WinDiv (The division responsible for the OS) made the assumption that fonts would not be loaded from insecure sources, e.g. Word documents. The Office division however faced the problem of what do you do when some user uses a font that is not on another users system? So they made the decision to allow the embedding of fonts into the file format, along with a bunch of other really bad decisions in hindsight (remember the Melissa virus?) that would have been caught if they had had the same security reviews as WinDiv did. To compound the problem, Office used unpublished and most likely unhardened APIs (it probably still does in parts) that allowed it the capabilities to do things like on the fly font loading something that wasn't exposed to the rest of us until Windows 2000 (NT 5.0). My point being that at the time it WAS a safe decision as far as WinDiv was concerned. Should they have been a little more careful with those unpublished APIs... yes they should have, it would have prevented a lot of anti-trust issues, but they weren't. So here we are with yet another security bug.

Firefox is using:

Image (executables): 95,084K

Mapped File: 56,892K

Sharable Pages: 133,100k

Heap: 25,100K

Stack: 46,080K

Private Data (explicit mallocs): 205,280K

Page Table: 1,372K

Unusable (leftover area of explicitly allocated pages that were LESS than 64K): 9,440K

Only 10M unusable isn't bad on windows... (start inevitable trolling here) as the memory manager only allocates pages in increments on 64k

I wish we had a score six to mod this too. As a .NET developer I agree that devs who only know .NET or Java or PHP etc. are a liability, we recently interviewed someone with extensive .NET experience, looked to be a good candidate too, and then we asked him about exception handling. He responded that anything that can throw should be wrapped in a try/catch block this answer was fine... although of concern. However what caused us to see other candidates was his reasoning "Because that's the way we've always done it where I work," a statement revealing how much he fundamentally didn't understand about what he was working with. While he was a perfectly fine technical coder he was under no circumstances an engineer. I think this is what the critically misguided CEO meant, however I still wouldn't work for someone that decides any technology is a liability, every technology has its purpose and to discount that as he has done is just idiotic

Honestly.... this argument is stupid, Group Policy arose because on Windows everything is a COM object with an ACL and it was neigh impossible to manage to provide even a modicum of security without some sort of system policy at a high level. Linux of course doesn't need this because it operates in a fundamentally different manner where everything is a file and the file system permissions (group based) determine if a is executable or not. Thus the Linux kernel doesn't need to know what specific COM+ handler needs to be loaded, but rather if a file is a supported executable format or not, and what to do from there. Both systems have fundamental advantages, Linux is deceptively simple leading to a power on the command line that is daunting for many users. Whereas Windows can be easy worked with to extend using COM and the registry (The registry was never designed to hold most of the crap that people shove in there... it was designed to be a central repository of information for COM objects).

If anything this model shows MS's lack of foresight into the importance of networking and their focus on the single standalone box.

Sadly this is due to COM+ registration, every single file type that has a program association (including exe in which case the association is the loader) is registered to tell windows what to do with it.

.NET CLR takes care of some of these issues... but doesn't sadly change the overall system. The fact that so few devs take advantage of application manifests to lock down their programs and use Side by Side to specify the precise dependencies allows virus writers to simply bypass the OS and aim for third party apps