BrowserPage.dll problems
 

Some Windows 95 and 98 users are reporting that LimeWire is unable to load BrowserPage.dll. We are unable to reproduce this problem, so we need your help debugging it. The error comes in two forms:

1. java.lang.UnsatisfiedLinkError: C:\Program Files\LimeWire\BrowserPage.dll: A device attached to the system is not functioning
at java.lang.ClassLoader$NativeLibrary.load(Native Method)

2. java.lang.UnsatisfiedLinkError: C:\Program
Files\LimeWire\BrowserPage.dll: One of the library files needed to run
this application cannot be found
at java.lang.ClassLoader$NativeLibrary.load(Native Method)

If you've encountered the error, could you please post the following information:

1. The error message you encountered.
2. The version of LimeWire you tried to run, and the directory you installed it.
3. Whether you used the InstallShield installer (English only) or the InstallAnywhere installer (international).
4. The "start in" directory listed in the shortcut you used to start LimeWire.
5. Whether "BrowserPage.dll" can be found in the directory where you installed LimeWire. Note that Windows explorer hides .DLL files by default, so you will want to make sure it shows "hidden" files.

You can also email me at crohrs at limewire.com. Thanks in advance for your help!

Sincerely,
Christopher Rohrs
LimeWire

for bonus points
 

If you're having the above error and were able to find BrowserPage.dll in your install directory, we could REALLY use your help. In this case, please try installing the free Dependency Walker program from http://download.com.com/3000-2086-66...ml?tag=lst-0-3
Then open BrowserPage.dll with Dependency Walker and look in the upper left corner. Please report any files marked with a yellow question mark. For example, you'll probably see jawt.dll listed there. You can also just take a screenshot for us.

Many thanks,
Chris

I've seen this bug once time... It was caused by another software that came with its own version of the JRE, and inserted a path to some DLL of that specific JRE (1.3.1 conflicting with 1.3.1_01).

The problem was solved by removing the extra (conflicting and badly installed) JRE, and reinstalling Java separately, in its own folder, then removing all other references to other versions of Java.

I don't need, with a standard Java install, any setting for the PATH environment variable.

Note that the international version (that comes with InstallAnywhere) installs Java 1.3.1 in all cases in the "jre" subdirectory of LimeWire. The large size of the download is caused by the bundled Java package, which is not necessary if Java is already installed and usable systemwide.
InstallAnywhere does not check, before installing that Java is already present, and runs the Java installer to create another instance of that run-time.
In my opinion, the installer in InstallAnywhere should first test the presence of Java, and should ask the user wheer he wants to use it. Also, it should be possible to create a light Installer, which will, when needed, download the Java package or ask the user to install it. The upgrade would be much faster without this Java bundle which is never needed when someone upgrades...
Installing Java in LimeWire is a bad idea, it's just waste of resource. The installer should install Java as a separate product, that can be used by all applications (including Internet Explorer and Netscape)