scratchfoundation / scratchfoundation/scratch-desktop

discussion: Windows 64-bit vs 32-bit builds

Open
#121 4 comments 0 reactions 1 assignee View on GitHub

@cwillisf is already working on this.

Since Jun 4, 2020.

discussion enhancement High Severity Low Impact needs discussion
Dominant language
JavaScript
Stars
426
Forks
268
Avg merge
16h 6m
Merged PRs (30d)
25

Description

I recently fixed #114 by changing the NSIS ("direct download") build for Windows to use a 32-bit version of Electron. However, we should discuss this situation in more detail.

Facts:

  • There are both 32-bit and 64-bit installations of Windows 10 in the world. A 64-bit version of Windows can run both 32-bit and 64-bit applications, but a 32-bit version of Windows generally can't run 64-bit applications.
  • scratch-desktop is built on Electron, which is available in both 32-bit and 64-bit forms.
  • the direct-download version of Scratch Desktop was a 32-bit application through version 3.6.0; it looks like I unintentionally changed it to a 64-bit application around version 3.7.0 or so: https://github.com/LLK/scratch-desktop/issues/114#issue-596424686

Possibilities:

  • The direct-download installer could install a 64-bit version of Scratch Desktop. This is what it does in version 3.10.x, for example.
    • Pro: on 64-bit versions of Windows with a lot of RAM, Scratch Desktop might be able to run very large Scratch projects better / faster.
    • Con: 32-bit versions of Windows cannot use this version of Scratch Desktop at all.
  • The direct-download installer could install a 32-bit version of Scratch Desktop. This is what we did for 3.6.x and below, and is what we're doing again as of c36c5c90f4378a4360096fe6d725605bd656fdb1.
    • Pro: both 32-bit and 64-bit versions of Windows can run this.
    • Con: Scratch Desktop cannot use more than about 3.25 GB of memory on Windows, even on 64-bit Windows.
  • The direct-download installer could detect your system type and install either a 32-bit or 64-bit version of Scratch Desktop, as appropriate.
    • Pro: both 32-bit and 64-bit versions of Windows can run this.
    • Con: the download is roughly double the size (right now: ~220 MB instead of ~110 MB).
    • Con: twice as many Windows direct-download builds to test
  • We could offer both 32-bit and 64-bit downloads separately.
    • Pro: both 32-bit and 64-bit versions of Windows can run this, and nobody's download gets larger.
    • Con: twice as many Windows direct-download builds to test
    • Con: some users might not be sure which version to download when visiting our download page. We would need to be very careful how we present the links in order to help reduce confusion.
    • Optionally, we could also have an "online" installer which automatically downloads the 32-bit or 64-bit version as appropriate. See https://github.com/LLK/scratch-desktop/issues/121#issuecomment-642396694
      • Pro: could help with "some users might not be sure which version to download" if we design the download page right
      • Con: yet another thing to test (though this would be much smaller than a full build)

My opinion:
Offering only a 32-bit build is the best option for the moment, until and unless we find that projects which require more than 3.25 GB of memory are common enough to reconsider this. It's possible that there are Scratch projects which would run poorly or not at all due to this limitation, but I'm not currently aware of any such projects.

Most likely, this limitation would be expressed by users saying that certain projects run on the web site but not in Scratch Desktop. If we do start hearing that frequently and determine that memory usage is the limiting factor we can either reconsider providing a 64-bit build, but we should probably try to reduce our memory footprint first ;)

If you have opinions on this, please share!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.