Resource File

Microsoft Virtual Machine Remediation

Contents

Developers who use the Microsoft virtual machine (VM) will need to transition away from its use by January 2004. To comply with a court settlement with Sun Microsystems, Microsoft will not be able to update the Microsoft VM, even to repair critical security vulnerabilities. No new Microsoft products will utilize the Microsoft VM. Microsoft will be providing a tool to ensure that customers will be able to protect their systems from any vulnerabilities that are discovered after January 2004.

It is important to understand what types of applications are affected. If you have built Web sites that expect the Microsoft VM in conjunction with the <APPLET> or <OBJECT> tag, or applications or components built with the Microsoft SDK for Java or Visual J++ (any version), you will be affected by this change. JavaScript, JScript, J2EE, and ECMAScript usage will not be affected unless they use one of the technologies just mentioned.

Microsoft recommends that if you use Visual J++ and the Microsoft SDK for Java and you've built applications or Web sites that use the Microsoft VM, start to replace it now. If you use the _language_ extensions in the Microsoft VM, you should plan to convert your applications using either Microsoft Visual J# .NET or the Microsoft Java Language Conversion Assistant (JLCA). These products will assist you in migrating your existing source code to the .NET Framework and help you understand the specific extensions available.

The first step in any plan to migrate away from the Microsoft VM is to understand its dependencies. In order to assist in this, Microsoft has made available a tool that will scan your systems and produce a report on the affected resources. Once you understand your dependencies, it is recommended that you migrate from the Microsoft VM by doing one or more of the following:

• Use Visual J# .NET to recompile your Microsoft VM code to the Microsoft .NET Framework.
• Use the JLCA to convert your Microsoft VM code to C# on the .NET Framework.
• Replace your Java applets with either ASP.NET or DHTML/ECMAScript.
• Move to a third-party display technology (such as Flash or Shockwave).
• Replace any use of the deprecated <APPLET> tag with <OBJECT>.

Visual J# .NET is a tool for developers who use the Java language to build applications and services on the .NET Framework. It provides you with a simple way of taking your existing Visual J++ or Microsoft SDK for Java applications and moving them to the .NET Framework without leaving the Java language. Microsoft has also released the beta version of an add-on to Visual J# .NET, the J# Browser Controls, that will round out support for migrating applet code to .NET using the Java language.

The JLCA, built on ArtinSoft migration technology, automatically converts most existing Java-language source code into C#, converting both language syntax and library calls.

If you used applets to overcome the limitations of early versions of HTML, you can take this opportunity to adopt a server-side solution. By converting to either ASP.NET (and utilizing ASP.NET server controls for advanced functionality) or replacing their applets with DHTML and ECMAScript, you'll be able to provide a solution to your users that can be viewed from any browser. With ASP.NET you'll also be able to provide device support to PDAs and cell phones from one Web site with minimal effort.

Developers can also move completely to another rendering technology. Many companies provide rich rendering technology that can be viewed in a number of browsers and that generally has far more functionality and flexibility than that provided by applets.

However, if you want to continue using applets, at a minimum you should follow the recommendation of the W3C and switch from the deprecated <APPLET> tag to the supported <OBJECT> tag. This provides you with additional functionality and the ability to select from a number of different Java Runtime Environments (JREs). If you want to move your existing standalone applications from the Microsoft VM, many third-party JRE vendors provide guidance on how to achieve this.