Brave-browser: [Desktop] Install 64bit to C:\Program Files\

Created on 10 Aug 2020  路  4Comments  路  Source: brave/brave-browser

BraveBrowserStandaloneSetup.exe (64bit) doesn't install to C:Program Files, but rather C:Program Files (x86)

Description

Installing from BraveBrowserStandaloneSetup.exe (64bit) on a 64bit Windows 10 places Brave into C:Program Files (x86) rather than C:Program Files

Steps to Reproduce

On 64bit Windows:

  1. Download BraveBrowserStandaloneSetup.exe from GitHub releases - https://github.com/brave/brave-browser/releases/tag/v1.11.104
  2. Right click downloaded file and "Run as administrator"
  3. Find BraveSoftware folder in C:Program Files (x86)

Actual result:

Brave installs to C:Program Files (x86) rather than C:Program Files

Expected result:

Install a 64bit version of Brave to C:Program Files

Brave version (brave://version info)

v1.11.104

  • Can you reproduce this issue with the current release?
    Yes
  • Can you reproduce this issue with the beta channel?
    Not tried
  • Can you reproduce this issue with the nightly channel?
    Not tried

Miscellaneous Information:

Given Brave uses the Chrome installer, how does one produce installation logs or an MSI?

  • I tried using the --msi, but I couldn't find the MSI, if one was created
Chromiuwaiting upstream ODesktop OWindows prioritP5 setuinstaller

Most helpful comment

I don't believe this is an intentional behaviour of the installer, because the installer has support for

      L"PROGRAMFILES",  // With or without " (x86)" according to exe bitness.
      L"PROGRAMFILES(X86)",  // Always "C:\Program Files (x86)"
      L"PROGRAMW6432",       // Always "C:\Program Files" under WoW64.

https://github.com/chromium/chromium/blob/6efa1184771ace08f3e2162b0255c93526d1750d/base/base_paths_win.cc#L56
https://github.com/chromium/chromium/blob/55f44515cd0b9e7739b434d1c62f4b7e321cd530/chrome/install_static/product_install_details.cc#L62

I also note that #598 refers to a duplicate Chromium bug, which has been closed in favour of https://bugs.chromium.org/p/chromium/issues/detail?id=302491#c27 in which [email protected] has requested enterprise users make contact to confirm the demand for this feature.

Two reasons why I don't believe this should be closed as a duplicate.

  1. this should be a relatively easy fix, because it relates to correctly handling the ENVIRONMENT variable, which should require a tweaking of the existing code, rather than the addition of a new feature. I've checked the "exe bitness" of the installer files using a superuser guide and since they are 64bit, the installer should be correctly selecting the target path as C:\Program Files
  2. although the linked bug requests a feature to "change the install location", which would potentially allow users to correctly direct the installation to C:\Program Files, that feature is completely different to the installer automatically selecting the correct target_path according to the system architecture

All 4 comments

This is behavior of the installer unfortunately. We do have an issue open for being able to change the install directory, if you'd like to subscribe
https://github.com/brave/brave-browser/issues/598

Closing this issue as a duplicate

I don't believe this is an intentional behaviour of the installer, because the installer has support for

      L"PROGRAMFILES",  // With or without " (x86)" according to exe bitness.
      L"PROGRAMFILES(X86)",  // Always "C:\Program Files (x86)"
      L"PROGRAMW6432",       // Always "C:\Program Files" under WoW64.

https://github.com/chromium/chromium/blob/6efa1184771ace08f3e2162b0255c93526d1750d/base/base_paths_win.cc#L56
https://github.com/chromium/chromium/blob/55f44515cd0b9e7739b434d1c62f4b7e321cd530/chrome/install_static/product_install_details.cc#L62

I also note that #598 refers to a duplicate Chromium bug, which has been closed in favour of https://bugs.chromium.org/p/chromium/issues/detail?id=302491#c27 in which [email protected] has requested enterprise users make contact to confirm the demand for this feature.

Two reasons why I don't believe this should be closed as a duplicate.

  1. this should be a relatively easy fix, because it relates to correctly handling the ENVIRONMENT variable, which should require a tweaking of the existing code, rather than the addition of a new feature. I've checked the "exe bitness" of the installer files using a superuser guide and since they are 64bit, the installer should be correctly selecting the target path as C:\Program Files
  2. although the linked bug requests a feature to "change the install location", which would potentially allow users to correctly direct the installation to C:\Program Files, that feature is completely different to the installer automatically selecting the correct target_path according to the system architecture

@bsclifton Are we waiting for an upstream fix for this one?

@rebron can't hurt to wait for upstream; would be a nice to fix

Was this page helpful?
0 / 5 - 0 ratings