janedoe2003
5th April 2004 22:01 UTC

Checking whether 98 or 98SE?
Hi

Since 98 seems to not like my installing MSINET.OCX and MSCOMCTL.OCX while I can't reproduce this error with 98SE over here, I was wondering it someone knew of a way to tell which version of 98 the user has?

For those interested, at best, regsvr32 fails, at worst, I get a GPF in KERNEL.DLL. I guess it's yet another bug of 98.

Thank you
JD.

PS: May I piggy-back on this message while I'm at it? :-)

1. I'd like to compare the version number of an OCX with the information that I listed in a INI file, and _only download + register if the one currently installed is older_ to avoid a needless download.

Does anyone know how to do this, without first downloading the latest and greatest from our site?

2. Can you confirm that the File instruction doesn't allow variables?

;Input : $5 = name of file
Function Check
SetOutPath $SYSDIR
;Compile error
File "d:\temp\$5"
ClearErrors
RegDLL $SYSDIR\$5
IfErrors 0 end
MessageBox MB_OK "Error registering $5"
end:
FunctionEnd

Joost Verburg
5th April 2004 22:33 UTC

1) Combine UpgradeDLL with NSISdl. I think there is not a ready-to-use example yet.

2) If you are using variables, how should the compiler know what files to include? Use the /oname switch for the location.

3) Search Google for possible information about this version conflict with Windows 98. Make sure you have the latest version of the OCX files. If you really want to detect the edition use the build number in the registry.

janedoe2003
6th April 2004 00:31 UTC

Thx Joost for the prompt answer :-)

>> I think there is not a ready-to-use example yet.

Too bad. I'll see if I can find a way to avoid downloading a file needlessly.

>> If you are using variables, how should the compiler know what files to include? Use the /oname switch for the location.

Too bad again that File can't use variables. Not sure why you mentionned the /oname switch though, as the error is the second parameter, ie. the following is NOK:

;Input : $R0 is the name of the file to handle
Function Check
    SetOutPath $SYSDIR

    ;Doesn't work
    File "d:\temp\$R0"
    
    ;Doesn't work any better
    File /oname="$R0" "d:\temp\$R0"

    ;Works
    File "d:\temp\myfile.dll"

    ClearErrors
    RegDLL $SYSDIR\$R0
    IfErrors 0 end
        MessageBox MB_OK "Erreur enregistrement $R0"
end:
FunctionEnd

Joost Verburg
6th April 2004 14:23 UTC

It is possible to create a system with a online INI/data file with versions. It does require some script writing.

The compiler includes a file in your installer. If you use a variable that can have any value, it doesn't know what files to include. Or do you want it to include your whole hard drive? :)

GetWindowsVersion does not check the build number, it returns the same for 98 and 98SE.

janedoe2003
6th April 2004 17:42 UTC

>> It is possible to create a system with a online INI/data file with versions. It does require some script writing.

If someone already has some enhanced UpgradeDLL code to let me check the version of an existing file on the user's HD again some version info without first downloading the possibly newer file, I'm interested :-)

>> The compiler includes a file in your installer. If you use a variable that can have any value, it doesn't know what files to include. Or do you want it to include your whole hard drive?

I'd agree if the filename were entered at runtime through the equivalent of eg. VB's InputBox(), but in this casse, the filenames are in the source code, so it seems to me that it should be possible to use File in such a case. But then, it's not a big issue, such a convenience.

>> GetWindowsVersion does not check the build number, it returns the same for 98 and 98SE

I found an old CD of the original version of 98. For those interested, the Registry shows a distinct build number, so a little bit of hacking in GetWindowsVersion() will enable you to discriminate the two.

Thank you
Fred.

Joost Verburg
6th April 2004 19:06 UTC

Variables can have any value. There is no way the compiler can detect which values it might have.

janedoe2003
6th April 2004 19:57 UTC

Thx for the tip :-)

One last question so I can move on to the UpgradeDLL part: I can't figure out the difference between GetDLLVersion() and GetDLLVersionLocal().

Is the former only allowed at runtime, while the latter is only allowed during compiling? I didn't find much infos in either the examples or the archives here, hence my question.

Thank you
JD.

Joost Verburg
6th April 2004 20:30 UTC

The Local one is for the compiler system, it is actually being converted to two StrCpy commands that set two variables.

With the value of the Local command (which is the version on your system), you can compare the version on the user's system using the other command.

janedoe2003
6th April 2004 20:43 UTC

OK, so the Local version is a way to hold a copy of the version of a DLL inside the generated EXE, so I can compare this info with the same DLL on the customer's host when he runs the EXE. Makes sense :-)

Thank you for your help
JD.