-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows: Add portable executable for each architecture #11990
Conversation
Why bother with |
@tomasz1986 I'm not sure about that. I just tried to run the 32-bit version on my 64-bit Windows and it did run (didn't crash and I saw the first screen) with some dedicated DLLs for 32-bit apps. ( |
Seems like the CI failed for unrelated cases. Could you please re-run it again? |
You're right, it works (also tested under actual 32-bit Windows)! This means that #4649 can finally be closed. |
@@ -78,7 +90,7 @@ | |||
"allowToChangeInstallationDirectory": false | |||
}, | |||
"portable": { | |||
"artifactName": "${productName}Portable.${ext}" | |||
"artifactName": "${productName}Portable-${arch}.${ext}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was onboard until I saw this - it means all links to JoplinPortable.exe will be broken afterwards. We could fix those we have in the code, but external links we don't know about will be broken and I'm not sure if it's worth it.
My feeling is that we could simply do nothing and wait for Windows 32-bit to be completely obsolete, at which point we'll only release the 64 version.
- There is no Windows 11 32-bit
- Windows 10 32-bit will be end of support in October 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My feeling is that we could simply do nothing and wait for Windows 32-bit to be completely obsolete, at which point we'll only release the 64 version.
Yes, releasing only the 64-bit version once Windows 32-bit becomes obsolete is reasonable. I think we could also doing this after Electron officially drops support for the 32-bit architecture on Windows and we have migrated to that version, which ensures minimal users are affected.
but external links we don't know about will be broken and I'm not sure if it's worth it.
As I mentioned in the notes, This PR doesn't remove the JoplinPortable.exe
from the release, and this executable will still include both ia32
and x64
architectures. Additionally, JoplinPortable.exe
, JoplinPortable-ia32.exe
and JoplinPortable-x64.exe
will all be uploaded to the GitHub release, so the existing hard-coded links won't be affected at all. This PR only provides users with the option to download a single-architecture portable executable when downloading from the GitHub release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, sorry I missed the notes. Still not sure we really want this. It's extra assets, extra build time and unless we properly advertise it there will just one or two users who will download this.
As you said eventually we won't even be able to support 32-bit, once Electron deprecates it and that should arrive relatively soon so I don't think we need to do anything special for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extra build time
Actually it takes only few seconds to generate a portable executable and publish it. Here are the logs of the recent GitHub Actions for release versions (v3.2.13, v3.3.3) and you can tell the time cost is not very high from the timestamp. The build process does take a lot of time but the packaging step can reuse the build outputs. I also verified generating multiple portables on my machines and it did take only a short period of time.
As you said eventually we won't even be able to support 32-bit, once Electron deprecates it and that should arrive relatively soon
Based on the Joplin release cycle, there will be at least two releases (and lots of pre-releases) before October 2025, which could involves around 232,883 * 2 downloads based on the statistics data for v3.2.x on Windows. Therefore, I think a significant number of users could benefit from the reduced size and faster startup speed.
Plus, It's uncertain for Electron’s timeline of deprecating 32-bit Windows support—it could be delayed. There's also a possibility that Joplin may not immediately switch to the latest Electron version when that happens.
That said, if you still believe this PR doesn’t provide enough value, I can close it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that nobody's going to download this 32-bit version because it's not linked to from anywhere, which means we also need to update the website and I simply don't think it's worth the effort. I appreciate your work but I'd rather not merge at this point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see.
The current portable executable for Windows is over 300MB because it includes binaries for both x86 and x64 architectures. However, in most cases, users only need one of these.

This PR adds portable build targets for each single architecture, reducing the executable size to under 170MB. This also improves startup performance because the portable executable always extracts itself to a temporary folder on Windows before running. A smaller size can reduce the loading time.

Notes
package.json
because some users might still need a universal portable executable. Also, There might be some hard-coded links referring to theJoplinPortable.exe
and removing it could cause failures. However, I can also remove the old build target if you wish.electron-builder
ensures that adding the new-${arch}
suffix won't change the original executable name.electron-userland/electron-builder@7194c38#diff-22c0d94d349d9c673f74434497a2da5bf74ed271ce195b8acf77bf0c756e4867R134
https://github.com/electron-userland/electron-builder/blob/e41c24ca47165a363a2ebb847416058f20047b9c/packages/app-builder-lib/src/targets/nsis/NsisTarget.ts#L173
https://www.electron.build/file-patterns.html#file-macros