search

mridoni / gix

An IDE and platform for GnuCOBOL, providing a native debugger, ESQL and HTTP REST services
GNU General Public License v3.0
31 stars 3 forks source link

Provide version that doesn't need admin privileges #130

Open bmnascimento opened 1 year ago

bmnascimento commented 1 year ago

Feature Request proposed on #129

Enhancement: either provide a version of the installer that doesn't need admin privileges, or a portable ".zip" release.

GitMensch commented 1 year ago

I'd prefer both, the installer would also allow start menu / file extension setting / ... (all under HKCU) while the ".zip" wouldn't adjust the registry at all.

mridoni commented 1 year ago

This should be fixed in the next release (see 0a2843009cdfdf208e2d3b5686f0d79daa7c8e4e), at least with regard to the non-administrative installer. It works like this:

A "portable" version is in the works, but first I have to check if everything can work without the registry being pre-populated by the installer: this can obviously be remedied, but it will take a bit more.

(BTW: the behavior indicated above will also be applied to the next release of GixSQL)

GitMensch commented 1 year ago

Thank you for the update, just one remark

MSVC runtime files are now installed in-place, there is no need for the Gix-IDE installer to launch the vc_runtime.x86/x64 installers anymore

I'm not sure about this but you may want to check:

A "portable" version is in the works, but first I have to check if everything can work without the registry being pre-populated by the installer: this can obviously be remedied, but it will take a bit more.

The portable version would just be a zip/7z, no? In this case the "common" way of handling this is to check on program start "is there a portable.ini (or data.ini or data folder or...)" and if yes only use this to read/write settings instead of the registry.

mridoni commented 1 year ago

I'm not sure about this but you may want to check:

  • Are you allowed to distribute the runtime files outside of the installer? (You know, that's the kind of issues one has with MSVC only)

Yes, this is explicitly allowed (even it not really encouraged), look here, paragraph #6. There are a few components of the MSVC-supplied runtime that cannot be redistributed, but these are way outside the scope of Gix-IDE (e.g. mobile or SQL Server-related stuff).

  • Should you copy those to the installer (increase in size)?

Despite the (well deserved) reputation of Microsoft products for bloat :smile: , it's just about 700 KBs (uncompressed), and the install time gets shorter too, since there is no need to download the packages and run a full blown installer, but one just needs to copy the runtime files over.

  • Is it a benefit for the user to always have those copied in - wouldn't this prevent the user to benefit of system installed updated versions with security, bugfix and performance adjustments by MS?

That's more of a problem for the MSVC-enabled version of the GixSQL runtime libraries on production systems (I wrote something about my doubts here) and the current GitHub Actions script that builds the installer packages has that part disabled for the embedded version of GixSQL. For Gix-IDE as a whole it is an unfortunate consequence but there is no way around that: since the runtime installers need administrative rights the individual runtime files (i.e. DLLs) must either be installed locally by an unprivileged user or centrally by an administrator with the MS-supplied installer package (vc_runtime.x86/x64). The Gix-IDE installer script could check if the runtime is already installed centrally and optionally copy the runtime files, should this not be the case, but I am not sure it would be worth it: a centrally-installed runtime could be installed at a later date but Gix-IDE would continue to use the "old" one unless the user manually removes the runtime files from the install folder.

The only way around this would be linking everything statically, but this is obviously unfeasible due to the size, memory and library compatibility issues that would arise.

A "portable" version is in the works, but first I have to check if everything can work without the registry being pre-populated by the installer: this can obviously be remedied, but it will take a bit more.

The portable version would just be a zip/7z, no? In this case the "common" way of handling this is to check on program start "is there a portable.ini (or data.ini or data folder or...)" and if yes only use this to read/write settings instead of the registry.

Gix-IDE uses the cross-platform QSettings class from Qt, that by default uses files on Linux and registry entries on Windows. While this architectural choice by the Qt team can be debated, this works very well and with minimal hassle, and I really wouldn't like to change this, but I will try to find a way around it.

GitMensch commented 1 year ago

Gix-IDE uses the cross-platform QSettings class from Qt, that by default uses files on Linux and registry entries on Windows. While this architectural choice by the Qt team can be debated, this works very well and with minimal hassle, and I really wouldn't like to change this, but I will try to find a way around it.

There is a QSettingsconstructor with an explicit string - this will use the ini-file on all systems.

I'd suggest to explicit check for a gixide.ini in the application path - if it is there use this constructor, otherwise the standard one and declare victory.

GitMensch commented 1 year ago

Are you allowed to distribute the runtime files outside of the installer? (You know, that's the kind of issues one has with MSVC only)

Yes, this is explicitly allowed (even it not really encouraged), look here, paragraph #6. There are a few components of the MSVC-supplied runtime that cannot be redistributed, but these are way outside the scope of Gix-IDE (e.g. mobile or SQL Server-related stuff).

Thank you for checking (likely done before, I just wanted to make sure and was "interested enough to know more", but "not interested enough to check") and sharing the result!

Is it a benefit for the user to always have those copied in - wouldn't this prevent the user to benefit of system installed updated versions with security, bugfix and performance adjustments by MS?

That's more of a problem for the MSVC-enabled version of the GixSQL runtime libraries on production systems (I wrote something about my doubts here) and the current GitHub Actions script that builds the installer packages has that part disabled for the embedded version of GixSQL. For Gix-IDE as a whole it is an unfortunate consequence but there is no way around that: since the runtime installers need administrative rights the individual runtime files (i.e. DLLs) must either be installed locally by an unprivileged user or centrally by an administrator with the MS-supplied installer package (vc_runtime.x86/x64). The Gix-IDE installer script could check if the runtime is already installed centrally and optionally copy the runtime files, should this not be the case, but I am not sure it would be worth it: a centrally-installed runtime could be installed at a later date but Gix-IDE would continue to use the "old" one unless the user manually removes the runtime files from the install folder.

I see. What about letting the user decide? Just add a new group "selection of MSVC runtime" (if you can add a description to that group give a short note that Gix-IDE [and the QT libraries distributed?] have a dependency on that) with the option "Download and run Installer" (maybe disable if installer has no admin rights or have it then a note attached that this needs elevation), "Copy into installation directory" (could be the default) and "Don't install MSVC runtime (needs to be installed separately)"?

The same could be used for the standalone installer. The portable version for Win32 could have a link to a downloadable package of the the necessary binaries for "copy in" - or just have two versions one with and one without).

The only way around this would be linking everything statically, but this is obviously unfeasible due to the size, memory and library compatibility issues that would arise.

Whoa, please don't static link, this only increases the problems.

mridoni commented 1 year ago

Gix-IDE uses the cross-platform QSettings class from Qt, that by default uses files on Linux and registry entries on Windows. While this architectural choice by the Qt team can be debated, this works very well and with minimal hassle, and I really wouldn't like to change this, but I will try to find a way around it.

There is a QSettingsconstructor with an explicit string - this will use the ini-file on all systems.

I'd suggest to explicit check for a gixide.ini in the application path - if it is there use this constructor, otherwise the standard one and declare victory.

It's not that simple, it has to be changed in many methods that use the constructor. QSettings should work as a singleton after it is instanced for the first time, but I haven't actually ever tried. I am not saying I won't do it, just that it takes some care not to break something that currently works well. I'll take this under consideration anyway.

mridoni commented 1 year ago

I see. What about letting the user decide? Just add a new group "selection of MSVC runtime" (if you can add a description to that group give a short note that Gix-IDE [and the QT libraries distributed?] have a dependency on that) with the option "Download and run Installer" (maybe disable if installer has no admin rights or have it then a note attached that this needs elevation), "Copy into installation directory" (could be the default) and "Don't install MSVC runtime (needs to be installed separately)"?

Yes, that could be an idea: even if it complicates the installer a bit it's probably the way to go.

Thanks