"Web Apps are the new DLL Hell"
Desktop application installation conflicts have been a persistent problem since the early days of Windows. These problems created an emphasis to use more web apps which offered the promise of being accessible from any computer and from any browser. That promise didn’t hold true for many reasons:
- Because of it's inclusion in Windows XP, IE6 completely dominated the browser market for nearly 10 years especially in the corporate space. As a result, developers and QA, faced with short time-frames and budgets, would typically only target and test with IE6.
- Many “web-applications” are truly not web applications, but rather ActiveX controls and plug-ins. The APIs and interfaces for browser plug-ins are highly specific to the browser brand and version number. As a result, many plug-in based web-applications only work with specific browsers and specific versions of those browsers. A lot of legacy content on the web can still only be accessed through plug-ins such as Java, Shockwave, Breeze, SVG, Media Player, and Real.
- The Java browser plug-in was one of the more popular browser plugins in the early days of the web, however, backward and forward compatibility within different versions of Java turned out to be incomplete and as a result, applications written for older versions of Java don’t run correctly on modern versions of Java.
- HTML standards have changed a lot since the first browsers appeared. Often the developers who created older web applications have moved on to other projects. Companies that are still around to provide updated versions of their web applications need to get paid for their work to create updates, but for an IT buyer paying for web app upgrades just to achieve browser compatibility seems like double taxation – wasn’t the whole premise of buying a web app protection against browser and desktop changes in the first place?
- Modern browsers introduce new segmentation and compatibility issues. With the rise in popularity of Firefox in the corporate environment, the same issues with IE are starting to proliferate in Firefox.
For IT Administrators, deploying and supporting web applications has become as tough as deploying desktop applications. Because IE6 can’t be installed on Windows 7 natively, IT Administrators are now being asked to decide between upgrading to Windows 7 and entirely stopping support of legacy web applications in their environments. Microsoft offers some options such as Terminal Server and XP-mode to remotely publish a browser instance from an older operating system, but often people reject these options because of cost, complexity, security, and performance.
Today, I’m going to give a technical preview of some exciting work being done by the ThinApp team to help solve the “Web App Hell” problem. In January, we posted a guide on how to use ThinApp to virtualize IE6 so that it will run on Windows 7 and this was very popular with our customers in the process of migrating to Windows 7. We’ve also posted notes on how to use ThinApp to virtualize various versions of the Java run-time and run them in isolation. Since then, we’ve made some great improvements.
In our earlier guide we recommended using Firefox IETabs to host IE6 as a container, the reason was that while IE6’s rendering engine was easy for ThinApp to virtualize, the browser frame and everything it can do is a bit harder. For example, when you use the File/Save dialog in IE6 it interfaces which system shell components that are not backward compatible from Win7 to XP. If you tried to do operations like File SaveAs, File Open, Print, Print Preview, New contact, Edit with Notepad, or modify various settings under Tools Internet Options you would probably get a crash or an error message. In addition you might have seen some cosmetic issues with icons being black or incorrect because of the same dependencies.
I’m happy to report we have now have IE6 fully virtualized and working perfectly on Windows 7 32bit and 64bit.
Currently the process for creating a ThinApp IE6 package is a little complex, you have to capture the IE6 install using a clean instance of Windows 2000 since that is the first version of Windows to ship with something before IE6. If you capture on Windows 2000 using the IE6 download from Microsoft’s download page you might not get all the latest security fixes provided by Microsoft who has agreed to continue fixing holes for the next few years for their enterprise customers. Capturing using Windows 2000 can also make it trickier to also capture plug-ins for that application, especially if the plug-in only installs on XP+.
We know this is popular use case, so we’ve turned the process of capturing IE6 into a few clicks. ThinApp can now automatically “harvest” IE6 out of any Windows XP instance. This means you can use an XP instance that has the latest security fixes applied, and also capture any plug-ins you want in the same go.
Today users need to know which web pages and apps require IE6, which pages require Firefox, and which pages work well on all browsers. If the user wants to navigate to a page that requires IE6 or Firefox from IE8/9 on Windows 7, they need to launch the virtual browser version and navigate to the page they are interested in. This process requires some user training and breaks up with normal work-flow. I’m excited to preview the ability to associate web pages with different virtualized browser versions. Users are automatically redirected to the appropriate browser as they navigate without interruption to their work-flow. This functionality works by installing a browser helper object in the native instance of IE which can then launch virtualized browsers when the user navigates to specific pre-defined URLs. We like to think of this as “file type association for browsers”. Because ThinApp executes entirely in user-mode and doesn’t install any system drivers, you can guarantee the native IE instance is completely unaffected by ThinApp, virtualization only kicks in when the user navigates to a specific set of URLs, and then only for the IE6 process instance. All other processes on the system are unaffected by ThinApp. This helps reduce the testing matrix complexity because ThinApp can be completely removed from the equation when testing the standard desktop experience before rolling out to users.
Associating browser instances to web URL sets allows IT administrators to remove components from their base desktop image where the only reason those components were installed was to support a specific web page. This simplifies deployment, testing, and reduces the security attack surface. Some examples include:
- Associate a web page with (IE8 native instance + virtualized Java 1.3)
- Associate another web page with (virtualized IE6 +virtualized Java 1.4)
- Associate HTML5 web page with virtualized Firefox or Chrome
ThinApp’s AppLink feature makes it easy to capture browsers and plug-ins separate and combine them dynamically at run-time, which both simplifies the update and management of various components.
We’ve done a lot of work to make all of this easy to manage, deploy, and use. For example, if IE8 launches two IE6 instances, DDE is used to ensure than only one instance of IE6 is started with multiple frames.
The process of adding and removing “browser filetype association” works using Thinreg.exe just like normal file type associations. The list of URLs to redirect can be updated on end-user PCs post-deployment via a per-machine and per-user simple text file.
Another thing we’ve done is test many of the popular plug-ins in the wild to ensure they work correctly inside of a virtualized IE6 instance running on Windows 7. We’ve added special code to ThinApp to allow various plug-ins to work in this environment.
For those interested in only in a video demonstration, please click here. We hope everyone enjoys this Tech Preview. Be sure to join us at what we can only say will be an "incredible" VMWorld this year. See you all in San Francisco!