IE7 Beta 2 caveat

There's a fairly important difference between IE 7 Beta 1 and 2 beyond the cosmetic.

To vastly oversimplify, IE 7b1 was a demonstration of the new eye candy. New interface, new features (tabs, plugins, security features), but it used the same exact HTML/CSS renderer that IE 6 does. To web developers this is useless.

Recently, build 5296 aka IE 7b2 was released by Microsoft for download. It features the actual new renderer with the CSS fixes promised in MSDN's blogs. There's a more recent version (build 5299) but it's not supposed to be available to the public. Eventually there will be a public beta as well.

One irritating feature of IE is that installing new versions invariably wipes out old versions, and there isn't always an uninstaller to revert to older versions. To make it possible to test new IE versions in the wild, Microsoft put an undocumented "local mode" into the installers.
IE installers are in fact .RAR archives. Unpack them to a temp directory with a tool like 7zip or WinRAR and inside is a pile of files including the iexplore.exe program itself. In order to make this version of iexplore run without trying to install itself, the usual trick has been to delete a DLL in that directory (shlwapi.dll), then create an empty textfile renamed to iexplore.exe.local -- these two things alert iexplore.exe that it's not an installed version and to run in local mode.

There's a problem with Beta 2. Microsoft hasn't been fond of "local mode" because it derails the installer's ability to overwrite system files with newer ones. Beta 2 comes with a new version of a system library (wininit.dll) which it expects to find -- in a particular set of circumstances.

Forumistas with both legit and pirate copies of XP have had inconsistent experiences getting Beta 2 to run in local mode. I was able to get it to run easily on a PC yesterday, but on another PC running the same version of XP Pro the application opens and closes mysteriously. Attempts to run it from a command line result in a cryptic dialog:

iexplore.exe - Entry Point Not Found
The procedure entry point InternetGetSecurityInfoByURLW could not be located in the dynamic link library WININET.dll.

The only difference between these two test bed PCs is that the one which ran successfully was logged in as the sole Administrator account, and the one which did not is an administrator but not the Administrator. Complaints on the forums indicate that this may not make a difference.

Here's my take on how it behaved. The infamous IE CSS rendering bugs documented at positioniseverything.net are largely fixed. I haven't run it through Eric Meyer's CSS2 test suite extensively, but I did notice that it still doesn't appear to support max- and min- dimension properties.

More critically, it accused sites which use JavaScript of having popups it blocked, when no such popups exist. Menu selects fail to work and some actually trigger popup blocker warnings. CSS-based menus do not consistently disappear when hovers end. The last one may be an anticipated side effect of using behavior: JScripts to correct IE6's incomplete hover: model. [edit: this was partially the case. csshover's author rewrote his code to do nothing in the presence of IE7 and it solved the problem.]

Until I can test IE7 in installed mode rather than local mode, I can't tell whether these are bugs in IE7 itself or its interaction with an OS using IE6 libraries.