Slashdot Mirror
IE Developer Responds to Mozilla Accusations
sriram_2001 writes "Dave Massy, a Microsoft employee who works on the Internet Explorer team has a response to the Mozilla Foundation's Mitchell Baker's comments. Specifically, he responds to the claim that IE is a part of the operating system. 'IE is part of the Windows Operating System so that parts of the OS and other applications can rely on the functionality and APIs being present. To be clear there are no Operating System APIs that IE uses that are not documented on MSDN as part of the platform SDK and available to other browsers and any other software that runs on Windows..'
Read the source code if you even bother. It was ejected by WMP not IE nor the KERNEL.
appended to the end of comments you post, 120 bit floating point
IF there are no operating system API's used by the browser, then why did MSFT fight so hard not ot have to remove it from the browser. IT might not use the OS API's, but im fairly sure it works the other way round. Has he ever tried to remove IE cleanly from a windows install?
At least that's what Microsoft told the courts...
And because it is effectively an OS service, it has theses "no security at all" modes that if you can escalate to in a script, you 0wn the box.
Test your net with Netalyzr
I would never use I.E. again if Firefox could do one thing (more), to be able to navigate to other (windows) boxes using my browser (like i can in I.E.)
by typing \\servername or \\ip address
my understanding was that this functionality was part of the API that is not available? this is the only thing keeping I.E. on my windows desktop.
I'm not usually one to point out typos, but... You might want to check your spelling when you're making a very public argument about how your software is not more prone to vulnerabilities than another.
IE is part of the Windows Operating System so that parts of the OS and other applicaitons can rely on the functionality and APIs being present. IE in turn relies on Operating System funcitonality to do it's job.
There are maybe a dozen sentences in the blog entry and two in a row have glaring typos (not to mention using "it's" when they mean "its"). I know we should judge it on the merits of what they're trying to say and not the careless way they said it, but it's hard not to have this reflect poorly on the speaker and the claims they're making.
I'm a big tall mofo.
Who says that's MS's philosophy? That was a user comment you quoted, not a post by the MS guy who owns the blog.
I guess you're trolling given the rest of the post - what's wrong with the XP kernel? - but hey.
People just love to makethe definition of "OS" whatever is best for them to bash MS.
The MS guy is right. Microsoft was right in court. It's not rocket surgery, haters.
IE is part of the business component "Microsoft Windows". It's "part of the OS" in terms of customer expectations, developer expectations, and the business defintion of what Microsoft defines as an OS. Actually, nowadays it's finally recognized as absolutely ridiculous to ship an OS without a browser.
It is _not_ a part of the OS proper in a CS/technical definition. It is not required for functionality of the kernel or core OS services.
Thats the point though the IE gives websites access to the APIs of other programs like WMP without asking the user.
To be clear there are no Operating System APIs that IE uses that are not documented on MSDN as part of the platform SDK and available to other browsers and any other software that runs on Windows.
This is always the standard Microsoft defense. Our products are written with the same API's as are available to everyone else. Everything's fair.
Except that Microsoft developers get access to the people who wrote the specifications. They can influence the specifications to change. In fact, according to a friend of mine who works at Microsoft, they have a tool which highly optimizes their code after compilation, by, among other things, moving the infrequently used code like error handling routines to the back of their DLL's, etc.
The fact that this tool hasn't been released to other developers is proof that they unfairly compete.
I was speaking recently to a developer working on Longhorn and he gave me the following information: IE cannot legally, since the court battles, use any undocumented system API calls. Therefore all of the calls that IE used have been made public on MSDN. They may have strange names and actually do other things than the documentation strictly says, but Microsoft has been forced to announce what "they do" to the public at large.
'IE is part of the Windows Operating System so that parts of the OS and other applications can rely on the functionality and APIs being present. To be clear there are no Operating System APIs that IE uses that are not documented on MSDN as part of the platform SDK and available to other browsers and any other software that runs on Windows..'
But was this case 7 years ago when Win98 came out with the integrated browser? NO. Only now that they've faced anticompetitive presures have they been willing to document certain "secret" api's.
Most of the best software available between 98 and 2002 (when they started releasing api's to the public) was designed by former microsoft alumni or other big companies working in close collaboration with MS. What little information that was available was only available in the "Microsoft Press" books.
This is just another case of Microsoft newspeak, ie: Documentation for most of our API's is available for free, (implying) Documentation for most of our API's has ALWAYS been available for free.
Cool! Amazing Toys.
I'm the guy who posted the story to Slashdot. One thing I noticed and which got edited out was that - nowhere in the post, does Dave Massy criticize Firefox itself. Though it is his own personal blog (it is not the IE team blog), he never mentions anything about Firefox. On the other hand, we have various people associated with Firefox badmouthing IE every chance they get.
I'm sure Dave could have pointed out with glee Firefox recent security problems (IDN, GIF handling ) or update-rollout problems. Can you imagine a Firefox dev not jumping on similar problems with IE and making fun of them?
Well, 512 millibits would indeed be a joke, but if you meant 'MB' for megabytes, then your definition of 'joke' must be different from mine...
I used to run it in half that, and it worked just fine thanks. When I added a load more, it got a lot faster for editing huge audio files or having lots of heavy apps open, but for general use there wasn't that much difference. I wouldn't recommend using less than 256MB, but it's perfectly comfortable with that amount.
Ceterum censeo subscriptionem esse delendam.
I've heard the Windows ME point to death. Do you know why they made Windows ME? Because 98, even with 98SE, wasn't up to snuff for the people that weren't ready to jump to the NT platform yet (which was where they were going with Whistler - which is what XP was known as back then). I think they just rushed it and it was a good base of half-baked ideas, but it was certainly a lot buggier than any other Windows release in recent history.
Contrast this to Longhorn - for once, Microsoft has bet the lion's part of their resources on one project to overhaul the system. If I understand this correctly, this includes making the kernel run as managed code - a huge undertaking in itself - but also revamping or replacing vast parts of what's under the GUI but above the kernel.
It's been big on promises both under the GUI (ie system features) and other, more advanced features that you actually use directly as applications. They realized that it'd take freaking forever, cut a big chunk of the touted advanced features and are now focusing on what's left. It's not going to be rushed and it will bring a big deal of new stuff, including vastly improved stability. So yes, if you're expecting Windows ME, you'll be pleasantly surprised, because this time, what's new in there isn't half-baked, isn't unstable and actually changes the core of the system to be more secure. They were very big on promises, and this seems like a major mistake now, but I think you're going to get your money's worth.
I'm not sure what to blame, but I just compared IE and FireFox side by side on a PC isolated to my local network. FireFox loaded many pages many times faster. Then I uninstalled all the virus protection (Norton) software on this newly aquired PC (as it will always be isolated to my local network for in-house testing) and IE performance improved dramatically.
I refuse to switch to KDE or GNOME because it's easy to use. Hell I still use FVWM without any fluff and my computer kicks ass.
You can take away the fluff of linux. You CAN'T take away the fluff of windows XP.
Exactly... this is most likely why Microsoft was found a monopoly... the .exe is not providing the OS API for 3rd party and other windows components, it is the html rendering library.
OS X has its WebCore and Safari is built on top of that. Anyone in the world could use the WebCore libs and make their own browser out of it.
Same for FireFox... Why do you think Netscape is so easily able to use the Mozilla renderer... because it is a library.
Microsoft's argument for not detaching IE is retarded as the executable is so not needed for anything. If they had been asked to remove the libraries, then they would have a problem.
Now, for the courts of course... Microsoft would always want to remove everything that is IE to prove that it has a huge purpose.
> I think this is unlikely. The underlying NT is quite well-designed (originally by David Cutler of VMS, amongst others, as I believe), and a reasonably flexible system upon which to develop applications.
I'd go along with that, when I worked for the OSF we considered NT as the uKernel for OSF/1 uK.
(considered == joint study with Dave Cutler and others)
Given that the shell namespace interfaces (which appear to have been what Devos meant, although he never really said) ARE documented, which is how come people write SOFTWARE with them, and that Devos never actually came up with a single instance of an undocumented API or interface, and that the area is really pretty well explored and understood, and that Devos' products just happened to include Windows API documentation and utility libraries... which he had to persuade people to buy somehow, even with the regular MS libraries and docs already available...
Whence? Hence. Whither? Thither.
Jeremy White (CEO of CodeWeavers) who actually got IE to work under wine says so
Well maybe White's the liar? Hmm?
The fact is, there are more uninformed people out there than there are informed people (just read the crap in the original article).
Another fact is that there are more Microsoft fans than there are Open Source fans (right now).
So, the intersection of those two groups means that there are more uninformed Microsofties than there are informed Open Source fans.
And those Microsofties, for whatever reason, have decided to hang out on
Get used to it. That's the same way it will be throughout most of your life, unless you restrict yourself to very exclusive groups with very high entrance requirements (/. is not one of them).You can't argue them down. They don't know enough of the material to know how ignorant they are.
I've argued here with people who swore that SMTP did NOT have authentication. Even after I posted links to the RFC's.
I'm not your typical Slashdot-fanatic, M$-hating, L1nux d00d. I love most of the latest MS products and think they're solid (as long as you're clued).
However, I literally laughed out loud when I read the following comment by the blogger:
As we develop IE we go through very thorough and stringent security reviews to ensure that every change is secure and does not expose the user to attack.
Which version of IE is this?! Nearly every released version of IE has had laughable (keep in mind, I'm not a Linux bigot) security flaws. I'm sorry, but you can't feed the sheep their own shit. They know, they KNOW.
He goes on to say:
The security of any browser is irrelevant to if it is part of the operating system.
That seems to be Microsoft's mantra. However, any security engineer or person with common sense would disagree.
If we are to debate security of browsers then let's bring in relevant arguments and accurate details about different possible attacks rather than rely on the irrational fear that because IE is part of the operating system it must be exposing OS functionality to the web.
Are you fucking joking? There is documented exploit after exploit demonstrating this. People aren't pulling it out of their asses. It's backed by fact, something you appear to be ignoring.
I'm a somewhat-loyal MS customer, but I've got to say I don't like reading tripe like this. What I do like reading is "we're going to fix IE's security model and this is how we're going to do it, what does the community think?".
Perhaps the IE team needs to review their security procedures, because they fuckin' suck hard.
No matter how fast/RAM saturated is your system, launching a Windows app takes at least 5 seconds, not to mention vigorous hard drive noises. I suspect it's busy relocating dozens of DLL thats should have used -fPIC, loading out-of-process COM servers and doing millions of registry accesses.
Sucks to be you. My apps pop up instantly. Only xemacs for me takes around 5 seconds on first invocation (and fsf emacs starts up instantly, but alas lacks the features I need). Go grab process explorer, take a look at the loaded DLL's for a microsoft app. Look for the yellow ones. Say, not many of them, are there?
Now make that app do something CPU bound. For example, run for(;;) putchar('a'); in a command prompt window. SMP or not, the system freezes.
You expect what behavior on a single-CPU system? Even with the fake SMP of hyperthreading on, it ate half the CPU. There's plenty of annoying crap in windows, but you simply don't know what you're talking about.
To be fair, KDE under Linux does a decent job emulating Windows in these cases.
Ah, but alas, IHBT.
How are you monitoring the memory usage in Windows? After booting, Windows XP will agressively swap out unused resources and allocate substantial amounts of RAM for drive caching.
It's tough to figure out what Windows is really "using". I suppose I could try booting Knoppix (without a ramdisk) and WinXP side by side in VMWare to compare how small the footprint can get. I recall Knoppix won't even load KDE without 70MB or so free. I figured that out recently when booting Knoppix with 128MB of RAM.
Yeah, there's the ramdisk again.
No, windows millennium was a stopgap that forced most software vendors into realising that the end of the road for perfect DOS support was coming, and coming fast. The few home owners who got that piece of shit made it real clear real fast that things had to change. The fact that most vendors didn't adopt Millennium for long drove home the point just a little quicker. Time to evolve. The days of not functioning on an NT core are coming to a close.
What is sad is that I had to support that monstrosity. Thankfully, not many WindowsME machines made it into the wild, and most are quickly and violently disappearing under the influx of XP Home. (THANK GOD).
Microsoft cannot evolve the platform fast enough anymore. All their innovations (evolutions) will be done in the backoffice. Desktop is not going to change that much.
Is The Browser Part of the Operating System?
An exercise in misdirection
You missed copying the first sentence of that paragraph: "Some say that Windows NTFS does not really offer a journaled file system." Nice FUD there.
i ty/centers/fileservices/fileservices_faq.mspx
That might be trying to say that NTFS doesn't journal file data, which is the case for almost all journaling file systems (or alternatives such as FreeBSD's Soft Updates). Those that do have that feature never enable it by default: the cost is simply too great.
File system integrity (i.e. metadata) is the job of the OS and the filesystem. Data integrity is the job of the application (until it has told the OS to commit the data to the disk, i.e. fsync in POSIX or FlushFileBuffers in Win32). The OS can't attempt to do that on a general level without greatly inhibiting performance for everything. That said, it would be very useful to have a journaling API available that applications could use.
http://www.microsoft.com/windowsserver2003/commun
I don't know how accurate your source is, but my friend at Microsoft is quite adament that people working on different products at Microsoft are hardly even allowed to talk to each other. After all the court action in the past, Microsoft's set an in-house policy that basically says that each product team is only allowed to access other teams' specifications that have also been released in public.
Having said that, it wouldn't surprise me the slightest bit if executives make decisions from time to time that completely ignore this policy, if they think they can get away with it. But in the general case, programmers at Microsoft aren't allowed to talk to each other about the internal workings of independent projects except to distribute already published material. I suspect that this would be enforced quite a lot between the Windows/IE barrier, given all the accusations in the past.
Personally I think the bigger problem is getting Windows to stop bundling, loading and using IE at every opportunity if and when it's not wanted. I haven't used Windows seriously for several years, but it can't be that easy to change the assumption that many Microsoft and Third Part applications seem to have, that IE will always be available on a Windows system.
My understanding was that this was the whole issue. If IE were to be removed, many applications would simply break. Windows would also break, since it uses IE's API (which, by the way, is published for any operating system to use) to do so many things.
Is this still a problem? I haven't used Windows seriously for several years now, although to me XP appeared that Windows Explorer and Internet Explorer were still based on the same engine, even when I'd changed my default browser.
Undocumented APIs are APIs that are not documented. Their use by other apps is "cheating". How do you know that MS apps don't call those APIs? BTW, making methods public that aren't to have external linkage is known as "really bad programming", or "unstable hack".
--
make install -not war