Note 1: In this document, the word "browser" means the code which provides the browser frame-UI (menu, title and toolbars) and the navigational behavior. The clear separation of the browser-frame and viewers (e.g., HTML viewer, shell folder viewers, etc.) is one of our major technical advantages over our competitors.
Note 2: Most of features described in this documents are pure shell/browser features, but some of them are cross-components features which involves changes in URLMON, WININET and MSHTML.
This document describes the changes in the IE 4.0 shell achitecture from IE 3.0 and Win95 shell. Please notice that it's not the list of features, but the list of components or architectual changes with which we implement various features. The corresponding features are highlighted by underlines.
IE 1.0 and 2.0 was a monolithic EXE which was not componentized at all and hard to maintain. During the development of IE 3.0, we packaged HTML viewer code from IE 2.0 into a COM object -- an HTML Viewer, and wrote a mini-explorer on top of it, which is capable hosting any shell view windows (file system folder views and etc.) and any DocObjects (such as Excel, Word or Visio) as well as HTML viewers. IE 4.0 replaced the HTML viewer with much more advanced viewer which supports " the dynamic HTML. It allows the web authors to create much richer and interactive pages. Contact: GaryBu, SatoNa
IE 3.0 was a mini shell-explorer which is capable hosting any shell view windows, and we added the internet (http, ftp and etc.) as a separate name space extension. Under IE 4.0, we are fully integrating these two by (1) making the internet as a part of the shell namespace, and (2) merging the IE 3.0 browser and the Windows 95 shell explorer into a single browser frame code. It allows the end-user to navigate local and remove file system and the internet from the same Explorer window.We also make it highly componentized so that we can configure the explorer window as needed (such as folder vs. explorer, or integrated-shell vs. browser-only). Contact: CheeChew, SatoNa
IE 3.0 introduced limited layout negotiation mechanism to support OLE-style toolbar space negotiation and its own toolbar. IE 4.0 extended that mechanism and it has three types of layout negotiations, (1) OLE-style negotiation for ActiveX Document, such as Excel and Visio, (2) toolbar space negotiation for internal and external components, such as its own toolbar and explorer pane, (3) toolband space negotiation within a toolbar for internal and external bands, such as address band, search band and quick launch band. The desktop window also support (2) and (3) and that's how we made the tray and deskband extensible. These mechanism allows the users to customizes their browser and desktop more flexibly and gives opportunities to ISVs and ICPs to add values to the user's environment. Contact: CheeChew, AndyP, SatoNa
Under IE 3.0, the window, location, navigator and history objects were implemented as a part of the currently viewed HTML document. That implemenation was causing many Navigator compatibility problems (such as window.open("") and document.write). To fix this problem, we've moved the majority of those implementation to the browser side of code. This new architecture is much more compatible with the implied object mode. It also allows us to make the document object of a newly created browser window available much more earlier. This change alone is contributing to over 10% of jump in our compatibility measurement. Contact: ChrisFra, SatoNa
Under IE3.0, HTTP-EQUIV tags are handled by the code HTML viewer, which is written specifically for HTTP-EQUIV. It is causing some bugs and inconsistencies -- for example, IE 3.0 does not support the client-pull passed via the real HTTP headers. IE 4.0, all HTTP-EQUIV tags are simply passed up to the containing browser and handled by the same code that handles real HTTP headers. This change has fixed several problems in client-pull, PICS rating and expiration date and removed the inconsistencies between HTTP-EQUIV tags and real HTTP headers. Contact: TonyCi, SatoNa
IE 3.0 relied on the object-cache to maintain the view state (such as texts in a form or the scroll position) of last couple of pages. This mechanism was limitted in the number of pages it remembers the view state (up to 4 pages) and was not working well with certain pages (such as those that immediately expires). IE 4.0's browser solves this problem by providing a view state storage for each pages in the navigation stack. It remembers the view state of up to 100 pages. Contact: TonyCi, SatoNa
To improve the scripting compatibility, we've changed how we handle the navigation request from the script. When we receive it, we start the navigation asynchronously but deffer the activation of the new page until the first page finishes running the script. We've also added the asynchronous PICS rating query. We sends a request to the PICS server asynchronously (at the same time we sends the HTTP request for the page itself). In case we receives the responce from the HTTP server before the PICS server, we deffer the activation of the new page until the PICS server responces. Contact: ChisFra, GregJ, SatoNa
To improved the perceived performance, we start formatting HTML pages before we display it. IE 3.0 emulated this behavior by synchronously activating the new page but leaving the bits of the previous page on the screen for a certain amount of time. This mechanism, however, does not work all the time (does not work with frame-set pages) and makes the browser inaccessible during that delay. We've solved this problem by not showing (UIActivating) the new page (leaving the previous page fully accessible) until the format of the first page is done (the Ready-State property becomes "interactive"). The user will see less re-painting and re-layouting when browsing the web and feels faster. Contact: MikeSh, SatoNa
Keyboard Navigation of IE 3.0 was implemented very specifically for the scenario we had and was not extensible. In order to dispatch and translate input messages appropriately among multiple frame components (toolbars, toolbands, the frame and the main document/shellview), we introduced a generic mechanism to keep track of the focus and let them translate messages correctly. We've also changed how the input messages are translated to make it much more in-synced with OC96 spec (window-less control spec). These changes allow the user to tabbing between the main page, toolbars and bands (such as the addressbar, search band). Contact: AndyP, SatoNa
IE 4.0 supports the inter-page transitoin, which allows external components (ActiveX transition controls) to play page transition animations (such as fade-out/fade-in or page-flipping) when the user navigates from one page to another. It allows the page authors to specify the transitions to be played when the page is being opened via either HTTP header or HTTP-EQUIV tag. It will make the web-browsing much more like TV experience. Contact: MWinser, SatoNa
Lack of (or not enough) user feedback ma cause some frustration to the end-user, especially under slow or asynchonous environment like browsing over a modem. IE 4.0 improves the usability of the browser by (1) introducing sound scheme such as "start navigation" and "complete navigation", (2) showing the total progress in the progress bar and (3) making the animating logo state more accurate. Contact: Satona, Dinart
When we start downloading files with types which we can't browse in-plate, we start the file-download UI. To make it fully modeless (so that the user can continue using the browser window), we start a separate thread for this file-download UI. Under IE3.0, it causes double-download (sending the same HTTP request to the server twice) because there was no way to pass the download transaction from on thread to another. Under IE 4.0, we've solved this problem by adding the transactoin marshalling capability to URLMON. This makes it more reliable to download files from busy servers. Contact: JudeJ, SatoNa
IE 3.0 's Mail/News integration is limitted -- the list of those external components (under the Go menu) is limitted and the only thing the user can do is opening Mail and News window. IE4.0 extended it by making fully registry based. It allows other clients (such as the address book and the calender) to add their meuitems to the browser. It also allows those clients to provide items under the File->New menu, such as "create a new mail message" or "add a new appointment". Contact: JudeJ, SatoNa
The pluggable protocol support of IE 3.0 was very limitted and not extensible enough to really add new protocols. IE 4.0 made it possible. IE 4.0 itself add various new protocols (such as "javascript:", "about:" and "help:") to fully utilize thie new feature. Each protocol provider provides a COM object which can transfer byte streams and a set of registry settings which specifies various properties of the protocol (such as opaqueness and default PICS rating). Contact: ChrisFra, TonyCi, JohannP, SatoNa
Windows 95 introduced the shell shortcut (.LNK files) and IE 2.0 and 3.0 introduced the internet shortcut (.URL files). When we integrate the shell explorer and the browser under IE 4.0, we also merged features of shell shotcut into the internet shotcut, so that it became THE shortcut which can points any objects in the shell name space. We are also adding the scripting capability to it so that it becomes the shell script file format. The channel bar will use this scripting capability to open browsers in theater mode. Contact: ScottH, SatoNa
(To Be Filled) Contact: BryanSt, MattSq, CheeChew
(To Be Filled) Contact: Dli, CheeChew, SatoNa
The browser band is an implementation of a toolband which contains a web browser control (WebOC). This component allows the end-users to configure their browsers and desktops with much more rich contents -- the search band, the history band and ticker uses this component. Contact: AndyP, CheeChew, SatoNa
The shell folder band is an implemetation of a toolband which shows the contents of any shell folders (a folder in the shell name space). It allows the end-users to cofigue their browsers and desktops with various links -- the quick lancher and the quick links this component. The Windows 95 start menu will be re-implemented with this mechanism to allows the user to configure the start menu much more easily and directly. Contact: MikeSh, CheeChew
We extended the frame-targetting mechanism slighly so that the search band (a browser band) can target the main frame and the existing web pages work reasonably well when they are embedded on the desktop (as a desktop component). Contact: ChrisFra, JCordell, SatoNa
(To Be Filled) Contact: MikeSh, KurtE
(To Be Filled) Contact: MikeSh, Sankar, MikeSch
(To Be Filled) Contact: MikeSh, CDTurner
(To Be Filled) Contact: MattSq
To impove the browser performance over IE 3.0, we made following changed in the browser: (1) pre-merged menu for the HTML viewer, which eliminate expensive OLE menu negotiation and (2) better window re-use to avoid unnecessary destruction and creation of windows (such as progressbar and icon windows). Contact: AndyP, SatoNa