Slashdot Mirror
Interview with IE Lead Program Manager
crackman writes "Matasano Security is running an excellent interview with Christopher Vaughan, a lead PM on the IE team. Christopher has worked on every release of Internet Explorer since version 2. He discusses IE7, security lessons learned from IE6, the future of .NET managed code in IE, and more."
I am happy (and proud) to say that only 58% of the visitors to my various websites use IE. That is, in the last 60 days. The various Gecko-based browsers share 32%.
I don't believe 97 percent was ever achieved by IE, but I could be wrong.
Write boring code, not shiny code!
> I don't believe 97 percent was ever achieved by IE, but I could be wrong.
r owsers
It's pretty close, from what I've read.
Just googled this:
http://en.wikipedia.org/wiki/Usage_share_of_web_b
it's in that ball park (frequently around 90-95%).
My point remains - it could only be 50% and it's doing well (on paper!)
Because they don't want to suddenly have a broken codebase and have to re-write the entire app when the next version of .NET and its development tools come out?
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Or alt-D
#include <disclaimer.h>
#include <beer.h>
current native code which has hooks deep into the OS.
Ok, a lot of people keep saying this, and I think there is some big misconception here.
IE taps into the HTML rendering DLLs of Windows. However EVERY application that runs on Windows taps into the FONT rending DLLs or the BITMAP rendering DLLs, but no one makes this claim about them. Nor other applications that use features from the HTML rendeing functions of Windows.
So to keep asserting that IE is somehow 'hooked' into Windows on a level above a NORMAL application is not entirely correct. It would be like saying FireFox also has deep hooks into Windows because it uses the Windows DLLs for FONTS and IMAGES...
defintitely the same reason - when you right click, you get a list of commands you can perform on the document. If Open wasn't one of them, then you couldn't open it :-)
.reg files - leftclick them and I get notepad with the text inside it. Also, for dlls, leftclick and I get dependancy walker. Similarly, when I click a cpp file, it loads in Visual Studio. If left-click was hard-coded to open, none of these things would work.
You can change the default action to something else instead of open.
Left-click is just a shorthand way of right-clicking and selecting the default.
The reason its done this way is that's much better (a more OO way) of associating commands with a file type. You can add a new command, change the default to that, and then left-click the file performs the new command! I do this for
If you want to know more, read about Shell Extensions in MSDN.
It's a shame that web developers have LET IE define the standard.
It's an amalgamated mess of about half of CSS 2.1, some proprietary stuff, and a sprinkling of JavaScript expressions. It doesn't have a name, but Microsoft tend to refer to it as "CSS", despite being clearly different to CSS. cf. Embrace, extend & extinguish.
Bogtha Bogtha Bogtha
Stop making up stuff. The full list of .NET 2.0 breaking changes is available here; at least cite examples from those if you're going to make claims that .NET 2.0 is completely incompatible with 1.0/1.1.
C# 2.0 maintains full source compatibility regarding keywords. The new keywords (where, yield, partial) work only under certain contexts, and can still be used as variable names. For example, where and partial work only in class definitions, i.e. public partial class Blah where T : class, and yield can only exist as yield return 4. There is no legal 1.0/1.1 code like that.
Types you define in your assembly take precedence over those in other assemblies, so there's no compilation issue. If you want to use new classes that clash with yours, you can add a using SubstituteClassName = ClashingClassName and use the new substitute name.
Look at the breaking changes page and tell me which one of those impacts you severely. All the changes I see are to fix bugs or security issues, or remove extraneous functionality. New signatures are simply added as overloads and the old signature made obsolete where necessary. See next for why obsolete doesn't mean a break change.
You can find a list of obsolete APIs here. And before you respond with "see!!! all those obsolete APIs break my code!!!", they're all either obscure or unsafe parts of the API, or have been updated to take advantage of new .NET 2.0 constructs. Furthermore, they're merely marked obsolete and will only generate a warning; you can still use them if you choose.
That is likely a failing on your part. Visual Studio 2002/2003/2005 all generate solutions that reference projects with relative paths. None of that is stored in the registry; hell, I've been uploading my projects to a Subversion repository and working on them from a variety of locations for years without any path problems.
All the wizards/tools generate .NET code; you can code everything manually if you'd like, including Winforms and ASP.NET. Even the project files are XML, and in .NET 2.0, you can compile everything without even the IDE installed. What examples do you have of stuff that requires a wizard to work?