Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #287458 +++ Build ID: Eclipse 3.6m6 or later on WinXP SP2 We have a vanilla Windows XP SP2 installation, on which the SWT Browser fails to load the swt-xulrunner-win32-xxx.dll. It looks like the reason is a dependency on msvcr80.dll, which is not installed on this machine. This is a problem for our commercial product, which needs to run on a vanilla Windows XP installation. The SWT Xulrunner that comes with Eclipse-3.5.2 works fine on the same machine. Can the requirement for having msvcr80.dll be lifted?
SSQ presumably this is a result of changing the SDK we compile against. Is it expected that this dll would be missing from a machine with XP SP2 though? I even have it on my Windows 2000, and I don't remember installing it specially.
I personally installed that XP SP2 machine from scratch (it is our performance test machine, which I wanted to be as "genuine" as possible). I recorded each and every step that I took, and I know for sure that I didn't delete any msvcrt DLL. On the other hand, I just noticed that we are already shipping msvcr80.dll as part of our product (in a different folder), so we could probably work around the issue, but the regression is still surprising. In swt-xulrunner-win32-3637.dll at 0x111F0 I find this: name='Microsoft.VC80.CRT' version='8.0.50608.0' In swt-xulrunner-win32-3555.dll I don't find this String, so it does look like this has been built differently. From my testing, it looks like the issue was introduced between 3.6M5 and 3.6M6. Does that coincide with changing the build environment on your end?
Yes, this started happening when we stopped using the old unsupported MSSDK from February 2003 and starting using "Windows Server 2003 SP1 SDK". I do not think we can go back to the old SDK. We investigated if it was possible to remove the dependency on msvcr80 and still use the newer SDK, but we did not find any solution at the time.
We double-checked our system, and MSVCR80.DLL is definitely not available on a plain Windows XP SP2 installation. It's also not available after upgrading to XP SP3, and installing all "high priority" updates; and, it's also not available after installing Firefox 3.5.9. So... while it's certainly true that the MSVCR80.DLL C++ runtime does come with some widely distributed apps, I do not know which ones; and, while the lib is available from Microsoft free of charge and can be redistributed etc. this does add some pain on Eclipse adopters like us. The issue is a regression, and I think that there is a case for at least trying to live without the C++ runtime DLL. This doesn't seem to be an issue for most of the SWT DLL's since they are plain C and so the C++ runtime library is not needed, whereas the xulrunner lib is C++. I'm wondering whether it might be possible for you to compile and link the swt-xulrunner-win32-xxx.dll library with /LD /MT switches in order to create a DLL while linking the C++ runtime statically, such that MSVCR80.DLL is not needed at runtime? For reference, see http://support.microsoft.com/kb/154753 We tried setting up a build environment ourselves for validating this suggestion, but getting all the Mozilla etc stuff in place didn't work out of the box so we'd appreciate if you guys could give it a try. Thanks!
I have the same problem for Windows XP SP2. If I use the SWT version 3.6M6, then the Browser Widget does not find the installed XULRunner. With the SWT version 3.5 all is running fine. We have a lot of Terminals with this operating system at our customers. It would be difficult to update all Terminals, that we can use the newer SWT version! It would be great, if there is another possibility? Thanks! Here my test snippet and the console outputs... public class DisplayMozillaVersion { public static void main(String[] args) { Device.DEBUG = true; Display display = new Display(); Shell shell = new Shell(display); System.out.println(">>>Snippet creating SWT.MOZILLA-style Browser"); try { new Browser(shell, SWT.MOZILLA); System.out.println(">>>succeeded"); } catch (Error e) { System.out.println(">>>This failed with the following error:"); e.printStackTrace(); System.out.println("\n\nSnippet creating SWT.NONE-style Browser"); try { new Browser(shell, SWT.NONE); System.out.println(">>>succeeded"); } catch (Error e2) { System.out.println(">>>This failed too, with the following error:"); e2.printStackTrace(); } } display.dispose(); } } Console outputs: C:\xulrunner_test>java -cp .;swt_3.6.jar DisplayMozillaVersion >>>Snippet creating SWT.MOZILLA-style Browser >>>This failed with the following error: org.eclipse.swt.SWTError: No more handles [Could not detect registered XULRunner to use] at org.eclipse.swt.SWT.error(Unknown Source) at org.eclipse.swt.browser.Mozilla.create(Unknown Source) at org.eclipse.swt.browser.Browser.<init>(Unknown Source) at DisplayMozillaVersion.main(DisplayMozillaVersion.java:13) Snippet creating SWT.NONE-style Browser >>>succeeded C:\xulrunner_test>java -cp .;swt_3.5.jar DisplayMozillaVersion >>>Snippet creating SWT.MOZILLA-style Browser XULRunner path: c:\Bizerba\xulrunner1.9\xpcom.dll >>>succeeded
Created attachment 169373 [details] patch (for 3.6RC2) (currently testing the patch on different machines)
fixed > 20100520
(In reply to comment #7) > fixed > 20100520 I have tested my snippet with the SWT version 3.6RC2 and 3.6N20100524 and I have already the same problem: org.eclipse.swt.SWTError: No more handles [Could not detect registered XULRunner to use] at org.eclipse.swt.SWT.error(Unknown Source) at org.eclipse.swt.browser.Mozilla.create(Unknown Source) at org.eclipse.swt.browser.Browser.<init>(Unknown Source) at DisplayMozillaVersion.main(DisplayMozillaVersion.java:13) Is the patch already integrated in this versions?
Yes it should be fixed in these builds. I'll try to find a similar XP machine here to try on (my test case so far has been my Windows 2000 with its msvcr80.dll renamed).
I didn't get to testing this yet, but looking at HEAD, it seems that in xpcom.manifest, you'll need to remove the entry about "Microsoft.VC80.CRT". Or, remove the file entirely.
Created attachment 170005 [details] jar to try I haven't found a machine here that fails with the 3.6RC2 content. It's true that the manifest file is not needed when compiling swt's xulrunner library with the old compiler, so I've done this and attached the case here for you to try. Please try the following as soon as possible, as it would be ideal for us to be finished with this issue by the end of today, if at all. - get the attached swt.jar - run it at the command line with: java -jar swt.jar - does it come up for you?
(In reply to comment #11) > Created an attachment (id=170005) [details] > jar to try > > I haven't found a machine here that fails with the 3.6RC2 content. It's true > that the manifest file is not needed when compiling swt's xulrunner library > with the old compiler, so I've done this and attached the case here for you to > try. Please try the following as soon as possible, as it would be ideal for us > to be finished with this issue by the end of today, if at all. > > - get the attached swt.jar > - run it at the command line with: java -jar swt.jar > - does it come up for you? It works! I have tested your test case and my snippet. Thanks a lot for fixing this bug so quickly! In which target milestone this bugfix will be integrated? Best regards...
Targetting for 3.6RC3.
Created attachment 170019 [details] patch part 2 (for 3.6RC3) This is the patch to review for 3.6RC3.
The xpcom.manifest is not necessary anymore. +1 for RC3
fixed > 20100526
*** Bug 316157 has been marked as a duplicate of this bug. ***
