293 replies to this topic

[_def_x_]

I think we may have discussed this before but I have forgotten, did we determine if there is a difference with the java downloads from Java.com versus FileHippo - JavaJRE?

I know the files are named differently - Java.com (jre-6u26-windows-i586-s.exe) and FileHippo (jre-6u26-windows-i586.exe).

The reason is, it would be nice to get Java signed but I cannot download a 64-bit version from Java.com, it detects the browser. If Bam's info is correct it's pretty easy to edit the apm files. Otherwise, I can only sign a 32-bit and ignore the 64-bit.

[Cristiano]

and they are detecting if you are running x64 even if you aren't running an x64 browser. but with the link that i've posted in my last post, everybody can

as for Java.com versus FileHippo, both are the same version (except that the default version in java.com is the -s version and the user that wishes the version without that has to add an +1 in the download link. also, for the x64, it's just add another +1 in the download link). but states that their version is the SE edition and not the JDK

[]s

Edited by Cristiano, 08 June 2011 - 05:06 PM.

[_def_x_]

If someone downloads either (hopefully both) versions of Java from post#160 could you supply the md5 and size, I downloaded the x64 file but it may be corrupt??? I'll download the x86 version later.

Once I get a confirmation on the size & hash I'll update the Java page and provide a more detailed explanation on how to add (manually) Java to an AutoPatcher release.

[dfdff3000]

jre-6u26-windows-i586 from Cristiano's link is 15.8 MB (16,619,296 bytes) and the md5 has is 216ca7b04a6898b427643ac683674777
jre-6u26-windows-x64 from Cristiano's link is 16.1 MB (16,920,684 bytes) and the md5 is 169cd52ad4b57e6439171fa411a4b6ef
I checked the md5's against the Java updates I downloaded from filehippo yesterday - and they are the same as these two.

[Cristiano]

confirmed

[]s

[_def_x_]

Thanks dfdff3000, that's what I wanted

I will try to get Java done in the next few days, I still have to download Java (x86) on dialup. My first priority is to help get XP SP3 finished, my friend is doing good, almost done, about 15 or so updates added, 8 or so removed, 3 more bulletins left.

I need some clarification, just a bit confused still:

Cristiano said:

java.com is the -s version and the user that wishes the version without that has to add an +1 in the download link.

This is the download link for x86 - http://javadl.sun.co...?BundleId=49024 - are you saying to change to BundleId=49025, this will download without the -s?

Cristiano said:

but states that their version is the SE edition and not the JDK

I'm not following what you mean exactly? I downloaded the x86 version from java.com, unedited BundleId, one thing I noticed is the executable uses the java coffee cup icon (Java logo), I also downloaded the x64 version using your link, this executable has an ugly dos-like icon (like AutoPatcher), this is why I thought the download was corrupted - it's not, the hash matches. Btw, both files say binary SE!

[Cristiano]

> are you saying to change to BundleId=49025, this will download without the -s?
yep. it will be the clean version

> I'm not following what you mean exactly?
at oracle site, it's possible download the developer edition (JDK) and the runtime edition (SE). to avoid issues about "hey, i'm looking for the developer edition, not this one", they state the version, just that. as for the link, in here both versions has the same icon. it may be related to the OS (i'm under x64)

[]s

[_def_x_]

Cristiano said:

> are you saying to change to BundleId=49025, this will download without the -s?
yep. it will be the clean version

OK, makes sense, but this is what still confuses me a bit... your download link for x64 is BundleId=49026, this is to get the x64 version without the -s correct, which means you added +1? What was the original (unedited) BundleId for x64, it couldn't be BundleId=49025, isn't this the edited version for x86 without -s?

[Cristiano]

> What was the original (unedited) BundleId for x64
that is the original BundleId for x64. that version doesn't have crapware. that way to track the version is just an easy way that i've realized long ago to get the x64 version without change to an x64 browser. now, doesn't matter, their detection is becoming smarter and now it shows both versions to those that run an x64 OS. the interesting thing about that is that if you keep adding +1, you will be getting a lot of versions of java

so:
BundleId=49024 = the x86 version -s
BundleId=49025 = the x86 version
BundleId=49026 = the x64 version
BundleId=49027 = JavaSetup6u26-rv.exe
BundleId=49028 = JavaSetup6u26-sprev.exe

etc

[]s

Edited by Cristiano, 09 June 2011 - 01:19 AM.

[_def_x_]

OK, can Java(JRE) x64 use both nice and simple registry alternatives for detection (I know one works, do both) - like these for x86:

Spoiler

...Java(JRE) 6U26 x86

[DetectionRegistry]
RegistryPath=HKCR\Installer\Products\4EA42A62D9304AC4784BF238120662FF
KeyName=ProductName
KeyValue=Java™ 6 Update 26

RegistryPath=HKLM\SOFTWARE\JavaSoft\Java Runtime Environment\1.6.0_26\MSI
KeyName=PRODUCTVERSION
KeyValue=6.0.260

...Java(JRE) 6U26 x64

[DetectionRegistry]
RegistryPath=HKCR\Installer\Products\4EA42A62D9304AC4784BF268140662FF
KeyName=ProductName
KeyValue=Java™ 6 Update 26 (64-bit)

RegistryPath=HKLM\SOFTWARE\JavaSoft\Java Runtime Environment\???
KeyName=?
KeyValue=?

Note: Is there an HKLM similar to x86 above - simple, easy to read and update - I would like 2 (1 alternative) for each version

[Cristiano]

> HKCR
this one has an advantage: it can be readable under x64 systems and HKLM can't, because the detection is redirected to wow6432node and due that, the x64 version can't be detected (doesn't exist in that part of the registry)

by other hand, HKCR works under all OS's

[]s

[_def_x_]

I'm trying to determine if Java(JRE) for x64 systems has an additional registry detection, it doesn't have to be in HKLM, this was only an example. Nothing comes up when the registry is searched using 'java' - not one mention of Java Runtime, JavaJRE - that's all I'm asking.

HKCR will be used, is there a second registry detection available for x64 so there is 2 (not just one) detections? This is a question I'm asking in the 'positive', what works - not the 'negative', what doesn't

[Cristiano]

i can try find an alternate registry entry, at home. but the main issue will be find an reliable one that autopatcher can read...

[]s

[_def_x_]

About Extras. It must have been 2 hours after I finally ran AutoPatcher and updated my system Flash that I saw there was another Flash update. I was in the process of beginning the update to Extras (again) when I noticed Silverlight had been updated. I downloaded 3 times yesterday hoping our link would pick up the new Silverlight - nothing so far

About Java. If there is only 1 detection for x64 so be it, I just wanted to know.

About .NET. I would love to figure out a way to get the latest .NET files (from April, maybe more in June) into the .NET release with or without the detections for now. It's a 70+ megabyte download for me on dialup

[Cristiano]

about silverlight, this seems to be the link that WU is downloading v4.0.60531.0

[]s

[ViroMan]

Quote

It's a 70+ megabyte download for me on dialup

sweet jesus!! Someone toss this guy a dsl modem!

[babcocca]

7.0 is out!

x86: http://download.orac...indows-i586.exe
x64: http://download.orac...windows-x64.exe

From: http://www.oracle.co...oad-432155.html

Looks like the direct links work so they can be immediately implemented in AP.

Edited by babcocca, 28 July 2011 - 09:44 PM.

[Cristiano]

sure. but also we are beta testing apup 2 and this takes time

[]s

[babcocca]

I am excited about the APUP 2! Keep up the great work!

[Cristiano]

we are too. it looks great so far. it still have some issues here and there, but all alpha versions are like that.it will take some time, but no problem... at least, most of the issues that the current version have are already fixed

[]s