More Sniffing for Browsers, Virtual Machines, and Operating Systems

Michael Edwards
Developer Technology Engineer
Microsoft Corporation

Updated June 25, 1998

Editor's note: This article is the second in a series of articles Michael has written on sniffing for various system components. Other parts include: "Sniffing for Browsers, Virtual Machines, and Operating Systems," and "Sniffing the Microsoft Virtual Machine."

Introduction

It's only been seven months since we published "Sniffing for Browsers, Virtual Machines, and Operating Systems," so you might wonder how that original article could already be broken! Happily, there is nothing incorrect with the information and code samples in that first, very popular sniffing article. However, some readers had questions, and many of the questions kept coming up. So I'll take this opportunity to fill the rest of you in with the answers I've been providing on the most often-asked questions.

Sniffing 128-bit Browsers

Sites that serve secure information often need to determine whether the client browser that is requesting a page from the server has the strongest encryption capabilities. These Web sites generally have two sets of pages they serve up: one set for 128-bit browsers, and an alternate, 40-bit version. In their February 2, 1998 column, the Web Men explained how sites can detect a 128-bit browser.

You can direct your customers to install the 128-bit version of Internet Explorer from the Internet Explorer download site .

Sniffing the Browser's Default Language

A lot of people would like to know how they can detect the client's default language so they can serve the correct language version of their Web site.

If you need to determine this from the server, use the HTTP header HTTP_ACCEPT_LANGUAGE. This header includes a pair of two-character identifiers separated by a hyphen character. The first identifier is a language code as specified by the International Organization for Standardization's (ISO) 639 standard. This language code indicates the browser's default language setting. Note that there are a couple discrepancies (nice way of saying mistakes) between the language codes used by Internet Explorer and what is specified by ISO 639. You can get the list of language codes used by Internet Explorer from the "Internet Options..." dialog available on the View menu. The list is located in a deeper dialog; choose Languages on the General tab.

You can also use client-side scripting to determine the default language; however the only method I know is only supported on Internet Explorer 4.01 and above. This method relies on the browserLanguage property of the navigator object.

Some important caveats if you are going to pursue this:

While Internet Explorer is completely standardized on ISO 639, Netscape Navigator is only "mostly" standardized. So test the country codes you support on Navigator (and then sniff Netscape browsers for the cases that don't match ISO 639).
Users can change their browser's default settings starting with both Internet Explorer 4.0 and Navigator 4.0. That means that users can change their default language after they have visited your site, so don't cache it in a user profile.
Most U.S.-manufactured computers ship with English as the default browser setting. Plus, even when users later upgrade their browsers, they usually don't change the default language option (which defaults to English) during Internet Explorer setup. Finally, most users don't know how to change their default language setting later. So when you see an English-language browser, that doesn't always mean the customer prefers English. Microsoft Network (MSN) deals with this by offering foreign language versions via hyperlinks on the bottom of its home page. Also, each language version uses its own domain so customers can manually choose the language version they prefer.

Many of you are looking for definitive ways to handle broader browser-locale issues, such as local currency, time zone, and other information needed to created a truly international site. This is a huge topic that I won't even attempt to address here. We've got it on our wish list. Be patient, it is a fairly hard problem.

Sniffing the Virtual Machine

A number of the people who read the virtual machine section in my previous sniffing article found the information for sniffing the installed virtual machine from a Java applet lacking. They cited a number of good reasons why you would want to determine the vendor and version for the installed virtual machine from script or C++. Some even sent me the code they are using for doing that, which was very helpful. Thanks!

Detecting the Virtual Machine from Script

Unfortunately, as I discuss in part 3 of this series, "Sniffing the Microsoft Virtual Machine", there isn't a simple, universally-acceptable way to sniff for all virtual machines across browsers using script alone. (I guess that would make things too easy.)

Detecting the Virtual Machine from InstallShield Setup Script

If you use InstallShield to package the Setup files for your Java application, you may wonder about the best way to detect whether the target computer is hosting the minimum virtual machine version required by your application. Even if you redistribute the self-extracting executable for installing the Microsoft virtual machine, you might like to know if you should run it from your InstallShield script.

One faithful reader recommends the following technique for determining the virtual machine from InstallShield, using the VerGetFileVersion and VerCompare helper functions provided by InstallShield:

#define MSJAVAVM  "msjava.dll"
#define MSJAVAVM_31 "5.0.2752"
...
if (VerGetFileVersion(WINSYSDIR ^ MSJAVAVM, vmVer) != 0) then
// the Microsoft VM isn't installed
else
// got the Microsoft VM, but what version is it
if (VerCompare(vmVer, MSJAVAVM_31, VERSION) = LESS_THAN) then
// the version number is prior to 3.1 virtual machine
endif;
...

Note that the basis for this method is to check the version stamp on the file msjava.dll that is located in the folder WINDOWS\SYSTEM32 (on Windows NT) or WINDOWS\SYSTEM (on Windows 98). This is the same technique recommended in the SDK for Java documentation . You can get a complete list of virtual machine version numbers from the Support Online site.

Detecting the Virtual Machine from C++

To detect the virtual machine from C++, use the same technique as from InstallShield scripts (above). That is, check the version information on the file msjava.dll in the Windows system folder. There's an easy way to do this, and a hard way. Rather than go into the details here, let me refer you to the April 1998 issue of Microsoft Systems Journal where Paul DiLascia wrote definitively on both methods .

Detecting the Virtual Machine on the Web Server

If you want to make sure your Web server is running the latest virtual machine, the easiest way is to open an Explorer window on the Windows system folder, right-click the file msjava.dll, choose Properties on the context menu, and click the Version tab. If you want to update the virtual machine, use the same method as you would for a client machine.

For More Information

Popular Topics for Java (the Support Online site devoted to Java, including information on deploying the Microsoft VM, and lots more)

Download the Microsoft SDK for Java, Version 3.1

Microsoft SDK for Java 3.1 Documentation Start Page

Conclusion

It is always neat to get feedback (good and bad) from readers, so thanks for writing to me. If nobody had written, I wouldn't have known that the information on sniffing the virtual machine was insufficient. Nor would I have learned about how to detect 128-bit browsers or what a default browser language is. And, of course, you wouldn't have just finished reading about it here.

Good luck and happy sniffing!