DualArch-Installers        Previous pageReturn to chapter overviewNext page

There are basically two ways of handling the OSArch issue(s): 

Type 1

SingleArch-Installer --> SingleArch-Installed. It is the most primitive but effective way of deploying apps. It only requires the release-package to designate the target OSArch in the .app-file (under <Architecture>). It is also going to have the smallest-sized deployment packages. But to be complete, one will need to create two such packages: one for x86 (32-bit) and another for x64 (64-bit). They'll also have separate but different file-names for each package, as discussed in "File-Naming Best Practices" already (see bullet point 10).


Type 2

    1. DualArch-Installer --> SingleArch-Installed. It is the scheme used almost exclusively with ssApps -- because their original installers were designed to install this way. We say almost exclusively because until now this was only used by ssApps -- this is a scheme that has been devised recently to work with ppApps as well. 
    2. DualArch-Installer --> DualArch-Installed. It is a scheme only used by ppApps -- because only ppApps can utilize it. 'Nuff said.


This new scheme had created a bit of a problem for someone looking at a DualArch ppApp. Is it a Type 2a or 2b? Previously, the assumption could have been made that if it's an ssApp it's Type 2a and if it's a ppApp then it's Type 2b. So a decision was made on how to designate the two kinds of Type 2's and how to start naming the resulting deployment packages.


There's no question that ssApp packages were on the scene first (so to speak) and they are in fact the more traditional-behaving unattended installing technique; whereas, ppApps are a more extreme and unique method of deployment that they are also an exclusive design of ssTek tools.


Looking at it thus, it's obvious that the Type 2a DualArch used by ssApps (and now ppApps) should therefore be the default when "Any" is selected under <Architecture>. It will also require no extra filename tag since this is the naming scheme ssApp packages have been utilizing for quite some time already. (Note: there was a tag for these, "_x86-x64", but it was rarely used if at all.)


Type 2b is a universal DualArch but will now need a special tag added to the filename in order to distinguish this particular type of DualArch ppApp from it's Type 2a brother. It is this type that truly deserves to be called "DualArch" because it IS a true Dual Architecture -- and in every sense of the definition.


Both types of "DualArch-Installer" ppApp packages are using the already established form of including both OSArch's under their respective subfolders ("_x86\" & "_x64\") -- all contained in the ppApp.7z archive -- and the shortcut flags for handling the respective OSArch's ("Is_x86" & "Is_x64").


So to toggle between either type of "DualArch-Installer" ppApp package, one only needs to "Edit" the .app-file (or .apz-file) with ssEditor and simply select Architecture "Any" (for Type 2a) or "DualArch" (for Type 2b)


The first one, "Any" -- the default -- will merely install the single-OSArch package of the target system. To accomplish this, SetupS excludes installing the other OSArch package of the target system (i.e., the "_x86\" or "_x64\" subfolders). For example, if installing one of these packages on an x86 system, the "_x64\" subfolder will be missing. This is important in case any common files or folders are also included in the ppApp.7z archive. To get the other OSArch installed, one will need to boot into an OS of the other arch and re-install the ppApp from its original deployment package.


The last one, "DualArch" installs both OSArch packages regardless of the target system's OSArch. To establish shortcuts of the other OSArch, one will simply need to boot into an OS of the other arch and run Regenerator (or use SendTo SetupS on the ppApp's installed folder).

Created with the Personal Edition of HelpNDoc: Make the switch to CHM with HelpNDoc's hassle-free WinHelp HLP to CHM conversion tool