Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Oomph » Custom self-extracting installer doesn't find the JRE on Windows(Getting weird conflicting errors about unexpected registry entries)
Custom self-extracting installer doesn't find the JRE on Windows [message #1745970] Thu, 20 October 2016 03:29 Go to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

I have a JDK 1.7, a JRE 1.7 (different micro versions), and a couple of different JDK 1.8 installations on a Windows 10 64-bit VM in Parallels on Mac (hopefully that isn't a factor, ugh).

I am attempting to assemble a working self-extracting installer for Papyrus-RT, following the instructions for extracting the installer bits on the wiki and using the extractor binary at

/opt/public/tools/oomph/extractor-64.exe


on the Eclipse.org build server.

I am using this method, as it seems the Oomph releng itself does it, because attempting to extract the relevant bits from a previously built eclipse-inst-win64.exe results in a binary that isn't recognized by Windows as a valid executable.

But, my installer EXE doesn't launch properly when I try to test it. I get a sequence of error dialogs in which the first is:

Quote:
Java Virtual Machine Launcher

Error: Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.8', but '1.7' is required.


I would have thought that 1.8 meets the requirement.

When I dismiss this dialog, I get another:

Quote:
Java Virtual Machine Launcher

Error: could not find java.dll.


And then a third dialog after this one:

Quote:
Java Virtual Machine Launcher

Error: Could not find Java SE Runtime Environment.


And then Edge browser opens up to the handy JRE/JDK download page hosted by Oomph with the VM argument "vm=1_1_7_0_64_0" which looks right to me, according to my installer descriptor file:

1
1
7
0
64
0
papyrus-rt-inst.exe
papyrus-rt-inst.ini
Papyrus-RT Installer
http://www.eclipse.org/papyrus-rt
https://wiki.eclipse.org/images/e/e3/PapyrusRT_Logo.jpg


Curiously, if I use the registry editor to hack my configuration to set a 1.7 JDK as the current version, then launching the installer gives me first a dialog saying that the current version is 1.7 but 1.8 is needed, and then the same dialog again claiming that the current version is 1.8 but 1.7 is needed. Odd, that.

Any ideas what the problem could be and how I might go about determining the cause and how to fix it? The latest eclipse-inst-win64.exe from the Eclipse download server works just fine on my system. And keep in mind that I know very little about the Windows environment. Sad

Thanks,

Christian
Re: Custom self-extracting installer doesn't find the JRE on Windows [message #1745980 is a reply to message #1745970] Thu, 20 October 2016 07:01 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33137
Registered: July 2009
Senior Member
You say "the latest eclipse-inst-win64.exe" works just fine. If you apply the same repackaging setups to it, does the repackaged result look/work fine? I.e., is the repackaged result identical byte-for-byte to the original. I know I had a hard time getting every last detail right when writing the wiki and I had a tiny typo in the COPY command that produced bad results which didn't work but also didn't give any kind of error when running the COPY command. So perhaps first try to eliminate the possibility that your reassembly isn't really producing quite the right thing. If it does the right thing, it should produces the same bytes as you started with.

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Custom self-extracting installer doesn't find the JRE on Windows [message #1746020 is a reply to message #1745980] Thu, 20 October 2016 14:38 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Thanks, Ed!

With your tip (which I totally should have thought of myself, duh) I was able to determine that the problem was in my cat command, as you suspected. A path needed quoting. I was able to build a working installer on my Mac, and the Eclipse signing service no longer rejects the file as not a valid Windows executable, but I still have problems with that step:

Corrupt PE file - current signature not at end of file: /home/data/users/genie/signing/httpd/upload/phpv4RIrx

Failed


Error 500: Codesign tool(running on: build,459) exit status: 255.


Not your problem.

Thanks again for all of this amazing framework. I may have some more requests for customizability of branding coming, soon.
Re: Custom self-extracting installer doesn't find the JRE on Windows [message #1746043 is a reply to message #1746020] Thu, 20 October 2016 18:50 Go to previous message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Ah! And my last problem with signing seems to have been caused by using the extractor.exe extracted from an Eclipse Installer build. I think that extracted extractor binary was already signed, so when I built my own installer binary by appending all of the other bits to it, that invalidated the existing signature.

Using the extractor binary from the /opt tree, together with my fixed concatenation script, works. I now have a self-extracting Papyrus-RT Installer for Windows.

Ed, maybe you'd like to update your wiki blurb about the extraction process with a note to the reader about not using the extractor.exe extracted from a signed installer binary?
Previous Topic:eclipse-inst.ini -Doomph.redirection broke in latest 1.5.0 Build 2683
Next Topic:URI re-direction with the self-extracting installer
Goto Forum:
  


Current Time: Sat Apr 20 03:04:30 GMT 2024

Powered by FUDForum. Page generated in 0.03002 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top