[WIP] 32 and 64 bit installer #476

Lucarda · 2018-09-18T18:49:05Z

This allows to have the 32bit and 64bit Pd installed on the same system without clashing.

It does:

Individual start menu entries.
Individual desktop icons.
Individual default installation paths.

Tested and both installations can coexist with no trouble but more work on src/s_file.c and tcl/pd_guiprefs.tcl needs to be done so that each Pd has its own 'windows registry' settings.

umlaeute

this seems to be an awful lot of duplicate code. i think would be much better to have a single script (both build-nsi.sh and pd.nsi) that take parameters to be instrumented for 32bit or 64bit. then small wrapper scripts to call the generic ones with the proper parameters.

umlaeute · 2018-09-18T19:36:55Z

also i don't understand why you changed the install dir to Pd-32bit and Pd-64bit.
shouldn't the location (%ProgramFiles% vs %ProgramFiles(x86)%) be enough to separate them (don't try to optimize for the obscure case, where somebody wants to install both 32bit and 64bit versions side-by-side into the same directory).

Lucarda · 2018-09-18T19:38:12Z

@danomatika and @umlaeute

These two files needs Pure-Data-32 / Pure-Data-64 ifs.

I can't handle these C / Tcl.

Help needed!

:)

Lucarda · 2018-09-18T19:40:14Z

also i don't understand why you changed the install dir to Pd-32bit and Pd-64bit

This can be changed but it was on purpose to make it totally clear.

umlaeute · 2018-09-18T20:03:12Z

These two files needs Pure-Data-32 / Pure-Data-64 ifs.
https://github.com/pure-data/pure-data/blob/master/src/s_file.c#L284
https://github.com/pure-data/pure-data/blob/master/tcl/pd_guiprefs.tcl#L153
I can't handle these C / Tcl.

on the C-side, the fix is trivial.
the question is more, how to do that properly (for all platforms, not just Win).

in the Tcl/Tk side, i'm not entirely sure, whether we should change it at all.
there is no proper way, to detect (from the GUI-side) which architecture the Pd-core is running (at this stage in the startup phase).
a better idea would be to be able to set the registry base key (or base path or whatever is used on the other systems) by a single configuration file that resides in the tcl/ folder (and which could be generated by the installer - either online or offline)

also i don't understand why you changed the install dir to Pd-32bit and Pd-64bit

This can be changed but it was on purpose to make it totally clear.

why?
i mean, it's probably fine to add such info to the start-menu entry, but there's little point in adding it to the installation path (there's so much information we might want to make totally clear; think C:\Archivos de programa (x86)\Pd-0.49-1 for Windows (64bit) doubleprecision by Miller Puckette - a bit like MaxMSP but BSD3 licensed\ ;-) more seriously, it adds redundancy which can easily be made self-contradictory (in the given example: why is a 64bit binary installed in the 32bit wow path?))

Spacechild1 · 2018-09-18T20:06:19Z

shouldn't the location (%ProgramFiles% vs %ProgramFiles(x86)%) be enough to separate them

I rather agree with @umlaeute. although some programs do this (e.g. REAPER (x64)), I don't think it's necessary.

Lucarda · 2018-09-18T20:10:26Z

shouldn't the location (%ProgramFiles% vs %ProgramFiles(x86)%) be enough to separate them

Ok, no trouble at all with that.

:)

Lucarda · 2018-09-18T20:17:19Z

in the Tcl/Tk side, i'm not entirely sure, whether we should change it at all.
there is no proper way, to detect (from the GUI-side) which architecture the Pd-core is running (at this stage in the startup phase).
a better idea would be to be able to set the registry base key (or base path or whatever is used on the other systems) by a single configuration file that resides in the tcl/ folder (and which could be generated by the installer - either online or offline)

This is Ok if possible with the installer but what about the Zip app?

You already did the magic detection with Deken, I guess this detection is late?

Idea: Now that we have pref file could we not use at all the 'windows registry' exept for file association?

umlaeute · 2018-09-18T20:32:11Z

This is Ok if possible with the installer but what about the Zip app?

just use a different default (in the ZIP-file). - one registry root for the 32bit installation - another registry root for the 64bit installation - yet another registry root for all ZIP "installations". if the user want to keep their ZIP-installations in different config spaces, they will have to to tweak manually (just like the users who want to have Pd-0.43 and Pd-0.49 co-exist but with different preferences).

You already did the magic detection with Deken, I guess this detection is late?

yes.

Idea: Now that we have `pref file` couldn't we not use at all the 'windows registry' exept for file association?

heresy. (if you don't want windows, why do you use it?) apart from that: what will this buy us? you are basically exchanging a file on a virtual filesystem with a file on a real filesystem. the only advantage would be, that the preference file could be stored alongside the pd.exe (e.g. in the same directory). however, not every user of %ProgramFiles%\Pd\bin\pd.exe can be assumed to have write access to %ProgramFiles%\Pd\. which prevents these users from saving their preferences. finally: i think it is entirely possible to create a bat/cmd/.ps1 script that starts Pd with `-noprefs -prefsfile my64bit.prefs`

Lucarda · 2018-09-18T20:45:42Z

one registry root for the 32bit installation

another registry root for the 64bit installation

yet another registry root for all ZIP "installations".

How you do the "registry root for all ZIP "installations"?
The installer is made from the zip version.
what did you meant with:

by a single configuration file that resides in the tcl/ folder (and which could be generated by the installer - either online or offline)

?

umlaeute · 2018-09-18T20:50:13Z

How you do the "registry root for all ZIP "installations"?
The installer is made from the zip version.

use the default registry root for ZIP "installations".
add an override of the default for NSI-installations (while building the NSI installer).

what did you meant with:

by a single configuration file that resides in the tcl/ folder (and which could be generated by the installer - either online or offline)

"put a single file containing the registry root into the tcl/-folder. this file could be generated by the installer-script; or missing."
this sounds an awful lot like what I wrote in my incomprehensible style, so I guess it is not much better. which part should i clarify?

Lucarda · 2018-09-18T20:58:55Z

"put a single file containing the registry root into the tcl/-folder. this file could be generated by the installer-script; or missing."
this sounds an awful lot like what I wrote in my incomprehensible style, so I guess it is not much better. which part should i clarify?

I think I got it. Some txt with just:

"HKEY_CURRENT_USER\\Software\\Pure-Data-32"

or

"HKEY_CURRENT_USER\\Software\\Pure-Data-64"

?

I like it. :)

Lucarda · 2018-09-18T21:01:26Z

I think the Txt thing resolves everything.

:)

umlaeute · 2018-09-18T21:03:21Z

yep, something like this. i'd like to hear the opinion of others on this though (@danomatika :-))

Lucarda · 2018-09-18T21:44:12Z

Ok, I'll try to make a nicer nsi script

:).

Lucarda · 2018-09-19T04:55:45Z

@umlaeute I made the changes that you requested, can you review?

The thing now goes with ~~makensis -DARCHI=32 pd.nsi~~

Lucarda · 2018-09-19T07:12:16Z

Something went wrong when trying to do some little fix.

I'll do another PR because I cant fix this one any more.

But this one works with ./build-nsi.sh <path-to-pd-dir> <pd-version-number> <arch (32 or 64)>

umlaeute · 2018-09-19T07:19:03Z

??

anyhow, while doing a new PR please also get rid of the ...\Pd-${ARCHI}bit\ directory.

umlaeute · 2018-09-19T07:20:44Z

here's another point via ...\Pd-${ARCHI}bit\ is a bad idea (apart from my personal preferences):

pd-lib-builder will stop automatically finding the Pd sources for your architecture.

so changing the installation-path is a regression.

umlaeute · 2018-09-19T07:22:54Z

msw/pd.nsi

+;
+; removed as of 0.49 to prevent 32/64 installer clashing. No negative side effects were observed.
+;
+;			!define PRODUCT_DIR_REGKEY "Software\Microsoft\Windows\CurrentVersion\App Paths\pd.exe"


@reduzent what was the original reason to add the PRODUCT_DIR_REGKEY

Most likely it there was no particular reason, but it got there because it was in the original template that I edited

Lucarda · 2018-09-19T07:29:58Z

get rid of the ...\Pd-${ARCHI}bit\ directory.

there's no such dir.
Is the 'start menu' / 'desktons icons' thing.

umlaeute · 2018-09-19T07:34:50Z

msw/pd.nsi

+; removed as of 0.49 to prevent 32/64 installer clashing. No negative side effects were observed.
+;
+;
+;			InstallDirRegKey HKLM "${PRODUCT_DIR_REGKEY}" ""


looking up the NSIS Documentation, I think the usage of this is to remember the installation directory across re-installs. As such, it seems clear that their are no immediate side-effects visible when doing a single installation. The change will only become apparent in consecutive use of the installer.
As such, I guess it should stay in (probably with a explanatory comment why it should stay)

If that is present you get the wrong default installation dir for the parallel 2nd installation something like: c:\program files\pd\bin. I tested it.

i guess, that's because the InstallDirRegKey must be different for 32bit and 64bit installations

I'm not sure how to play with these 4 that were removed:

!define PRODUCT_DIR_REGKEY "Software\Microsoft\Windows\CurrentVersion\App Paths\pd.exe" InstallDirRegKey HKLM "${PRODUCT_DIR_REGKEY}" "" WriteRegStr HKLM "${PRODUCT_DIR_REGKEY}" "" "$INSTDIR\bin\pd.exe" DeleteRegKey HKLM "${PRODUCT_DIR_REGKEY}"

may be:

InstallDirRegKey HKLM "${PRODUCT_DIR_REGKEY}" "${ARCHI}"

?

umlaeute · 2018-09-19T07:37:06Z

Is the 'start menu' / 'desktons icons' thing.

ah indeed. static code analysis only gets you so far, if you don't know the eco-system well.
sorry for the noise

…pure-data into windows32and64installer # Conflicts: # msw/build-nsi.sh # msw/pd.nsi

Lucarda · 2018-09-19T21:35:55Z

Ok, I have tested and the only known bug is that if you install first the 32 and then the 64, if 64 gets uninstalled the 32 loses the file association.

Not much a big problem as you can fix it with "open with" from the explorer.

@umlaeute can you review?

This only fixes the 32/64 installer. Work must be done on the C/tcl side so that the 32 app don't share the registry with the 64 app.

The installer is ready.

Lucarda · 2018-09-19T23:03:39Z

@millerpuckette

This allows to have 32 and 64 bit Pd installed on the same system.
It defaults installation to:

64bit-OS 64bit-Pd: "%Program Files%\Pd"
64bit-OS 32bit-Pd: "%Program Files (x86)%\Pd"
32bit-OS 32bit-Pd: "%Program Files%\Pd"

It creates different:

Start-menu entries
Desktop icons

Some work must be done outside of the installer so that both apps don't share the same 'registry' but all that can be done with the installer's scripts is done in this PR.

usage:

./build-nsi.sh <path-to-pd-dir> <pd-version-number> <arch (32 or 64)>

:)

danomatika · 2018-09-20T13:30:28Z

Looks good to me.

umlaeute · 2018-09-21T07:45:52Z

i've updated the build-nsi.sh script to automatically detect the arch value if it is missing (please test :-))

"Pd-32bit" looks a bit... LATER: think of getting rid of the ARCHI when it's not needed (e.g. on Win/32bit we can only ever have 32bit applications)

Lucarda · 2018-09-21T09:41:37Z

fdf39d7 is running nicely.

Lucarda · 2018-09-21T10:11:14Z

Why did you erase the commits? they were almost going. :)

I got that part but I'm starting to fell asleep.

will hang out 1 hour more or less :)

umlaeute · 2018-09-21T10:33:07Z

i erased them because they are in the wrong PR (switching the file-association to Pd-GUI was not going to work without the changes from #481)

so i moved them all over to #481

Lucarda · 2018-09-21T18:00:35Z

Oops. Can you undo this merge.

Is was included on #481

Lucarda · 2018-09-21T18:06:11Z

Sorry for the noise master seems Ok.

Adding files for 32 and 64 bit installer

3cd1b45

Lucarda mentioned this pull request Sep 18, 2018

Pd on Windows should should use different paths for 32 and 64 bit binaries #469

Closed

umlaeute requested changes Sep 18, 2018

View reviewed changes

Lucarda added 3 commits September 19, 2018 01:01

Removing earlier files

fdbbfe4

make installer for different archs with command arguments

07dd248

Merge branch 'master' into windows32and64installer

0032ac7

redoing

17d73a9

umlaeute reviewed Sep 19, 2018

View reviewed changes

pure-data deleted a comment from Lucarda Sep 19, 2018

Lucarda added 3 commits September 19, 2018 14:39

Merge branch 'windows32and64installer' of https://github.com/Lucarda/…

3c0223a

…pure-data into windows32and64installer # Conflicts: # msw/build-nsi.sh # msw/pd.nsi

Puting some thing back.

ee178ac

some little corr

218f15d

umlaeute added 2 commits September 21, 2018 09:44

improved usage info

9425595

autodetect architecture if none is given.

394c70f

umlaeute added 2 commits September 21, 2018 09:51

fixed auto-detection of architecture for windows-installer

fdf39d7

use "Pure Data (??bit)" for startmenus and desktop icons

d37e9f2

"Pd-32bit" looks a bit... LATER: think of getting rid of the ARCHI when it's not needed (e.g. on Win/32bit we can only ever have 32bit applications)

umlaeute mentioned this pull request Sep 21, 2018

Windows installer should launch the Pd-GUI (rather than the Pd-DSP) #480

Closed

umlaeute force-pushed the windows32and64installer branch from a1953e2 to fdf39d7 Compare September 21, 2018 10:06

removed debugging printout

f7ff9b3

millerpuckette merged commit f7ff9b3 into pure-data:master Sep 21, 2018

Lucarda deleted the windows32and64installer branch September 21, 2018 19:56

pure-data deleted a comment from Spacechild1 Dec 10, 2019

[WIP] 32 and 64 bit installer #476

[WIP] 32 and 64 bit installer #476

Conversation

Lucarda commented Sep 18, 2018 • edited

umlaeute left a comment

Choose a reason for hiding this comment

umlaeute commented Sep 18, 2018 • edited

Lucarda commented Sep 18, 2018

Lucarda commented Sep 18, 2018 • edited by umlaeute

umlaeute commented Sep 18, 2018

Spacechild1 commented Sep 18, 2018

Lucarda commented Sep 18, 2018

Lucarda commented Sep 18, 2018 • edited

umlaeute commented Sep 18, 2018 via email • edited

Lucarda commented Sep 18, 2018

umlaeute commented Sep 18, 2018

Lucarda commented Sep 18, 2018

Lucarda commented Sep 18, 2018

umlaeute commented Sep 18, 2018

Lucarda commented Sep 18, 2018

Lucarda commented Sep 19, 2018 • edited

Lucarda commented Sep 19, 2018

umlaeute commented Sep 19, 2018

umlaeute commented Sep 19, 2018

umlaeute Sep 19, 2018

Choose a reason for hiding this comment

reduzent Sep 19, 2018

Choose a reason for hiding this comment

Lucarda commented Sep 19, 2018

umlaeute Sep 19, 2018

Choose a reason for hiding this comment

Lucarda Sep 19, 2018

Choose a reason for hiding this comment

umlaeute Sep 19, 2018

Choose a reason for hiding this comment

Lucarda Sep 19, 2018

Choose a reason for hiding this comment

umlaeute commented Sep 19, 2018

Lucarda commented Sep 19, 2018

The installer is ready.

Lucarda commented Sep 19, 2018

danomatika commented Sep 20, 2018

umlaeute commented Sep 21, 2018

Lucarda commented Sep 21, 2018

Lucarda commented Sep 21, 2018

umlaeute commented Sep 21, 2018 • edited

Lucarda commented Sep 21, 2018

Lucarda commented Sep 21, 2018

Lucarda commented Sep 18, 2018 •

edited

umlaeute commented Sep 18, 2018 •

edited

Lucarda commented Sep 18, 2018 •

edited by umlaeute

Lucarda commented Sep 18, 2018 •

edited

umlaeute commented Sep 18, 2018 via email •

edited

Lucarda commented Sep 19, 2018 •

edited

umlaeute commented Sep 21, 2018 •

edited