Installer for all CPU's?

[Phantom]

[JeremyR]

[Phantom]

[Paul]

[Phantom]

[Dan East]

Yeah, you can do that! I have one installer for all device types, and it shares HTML and image files that are common to all installations. <br>You have a [SourceDisksNames] section. Use that only for common files. Then have a section specific to each processor type [SourceDisksNames.STRONGARM], where you specify the path for the various device specific files.<br>You do the same for [SourceDisksFiles], where you specify the path ID for each file. You then create one for each processor [SourceDisksFiles.STRONGARM]. You also create [Files] sections. I use [Files.Common] for shared files, then use sections for each device [Files.STONGARM] for the binaries. Finally create [DefaultInstall] sections for each processor, and assign CopyFiles appropriately:<br><br>[DefaultInstall.STRONGARM]<br>CopyFiles = Files.Common, Files.STRONGARM<br>[DefaultInstall.SH3]<br>CopyFiles = Files.Common, Files.SH3<br><br>Dan East

[Dan East]

That all refers to your .inf file of course...<br><br>Dan East

[Birdiestyle]

Just outta curiousity, will that make 3 cab files each with the data in it, so in fact you will have the 9MB of data.. <br><br>I was going to investigate whether or not you can put one CAB file as the Data, which would not be Processor specific, and one cab for each of the EXE files, or does the Application Manager quit once it finds the first relevant CAB file in the setup.ini file... hmmmm..... I would guess this would be possible. But then I would think you would have a completely different INF file for the data.<br><br>????<br><br><br>

[Phantom]

My nutcracker.inf file contains the sections you mentioned. I execute cabwiz like this:<br>cabwiz nutcracker.inf /cpu ARM MIPS SH3<br>This results in three cabs, and since EasySetup takes one at a time, this results in three executable installers. What am I doing wrong? How can I compile to a single cab?<br>

[Dan East]

Okay, I had a brain lapse. That does of course create 3 seperate cab files. Here's another possible solution. Make a seperate CAB installer for all the shared files. Have your device-specific (your main) installer install that CAB file. Now, it may be possible that your main installer can directly launch and install the second cab file. If not, then you can create a very simple setup.dll that the installer will execute on the device. You can the just have that DLL CreateProcess or ShellExecuteEx the second CAB file to install it.<br><br>Dan East

[Phantom]

Hm, OK. I think it's strange that there doesn't exist an installer tool that simply takes care of the CPU identification... Anyway, with all those new ARM devices, the problem will soon be gone. I got a suggestion by e-mail to simply put three installers in a single zip. Because of the huge amounts of identical data, this zip would be quite small. Crystal Balls is 2Mb unzipped, so I expect a 1Mb installer (it's all uncompressed .tga data), and I will thus indeed go for the zip file, even if it would be 3Mb. In fact, if it would be 1Mb, people might consider that 'suspiciously small'.

[Dan East]

EZInstaller compresses it up with gzip when it creates the installer exe. I don't know if you're using that or not.<br><br>Dan East

[Birdiestyle]

  Hmmmm... I assumed that you were using a zip file already... <br>  Did you attempt to make four CAB files 1 each for the different EXE's and one that is device<br>non-specific, or isnt this possible... That way even your zip file would still only contain the compressed data once!<br>  <br>This would depend on two things,<br><br>1. You can make a CAB file that gets installed for all Processors thru the Inf (or its own INF).<br><br>2. When the App Mgr is reading the setup.ini file, it would continue after finding a CAB file that matches, to check the rest of the CAB files for another match, possibly in a 2nd component section. <br><br>If this doesnt work though you can simply call the Installer with your original INI file from your setup program, and then call an additional <br>INI file dealing only with the data. <br><br>But I would guess by the way that the INI file is setup that more than one [Component] can be installed, one component being the data and one being the actual program!!<br><br>Cool<br><br>B

[Zensunni]

I'll be happy if this mess will be over..<br><br>future versions of pocketpc will only support arm processors, and hence cef will be ditched as well..<br><br>but then, that still might take a while