cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

OS environment question

I'm just starting to get my hands dirty with Repackager and found a situation regarding 32/64-bit environments.

For example, when repackaging Paint.NET, in the project directory I can see files to be installed in the PROGRAMFILES64Folder. I repackaged this app on a 64-bit OS, so that makes sense. However, what would happen if I tried to deploy this onto a 32-bit system (since there's no PROGRAMFILES64Folder)? Do I need to repackage apps on both 32-bit and 64-bit OS, to accomodate deployments to both environments?
(1) Reply
Charlatat wrote:
I'm just starting to get my hands dirty with Repackager and found a situation regarding 32/64-bit environments.

For example, when repackaging Paint.NET, in the project directory I can see files to be installed in the PROGRAMFILES64Folder. I repackaged this app on a 64-bit OS, so that makes sense. However, what would happen if I tried to deploy this onto a 32-bit system (since there's no PROGRAMFILES64Folder)? Do I need to repackage apps on both 32-bit and 64-bit OS, to accomodate deployments to both environments?


For most applications you can simply repackage them on 32-bit Windows and then send that 32-bit package to both 32-bit and 64-bit machines. That way you don't need to capture the application twice. Otherwise, in situations involving things such as Shell Extensions, you must repackage the application on both 32-bit and 64-bit Windows. You could spend some effort afterwards creating a hybrid package that would deliver the 64-bit components (with things such as 64-bit files and 64-bit shell extensions) to 64-bit machines. You would condition those 64bit components so that they only install on 64-bit Windows (use the condition VersionNT64). However, creating a hybrid 32-bit/64-bit package could be somewhat time-consuming and may not be considered a good value...it would certainly be easier and less error-prone creating two separate packages for 32-bit and 64-bit.