-
|
Just curious, why is this made to be 32-bit? Is Windows really that far behind macOS? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
The library is not limited to 32-bit (though it can be built 32-bit), and in fact the CI and testing is done exclusively on a 64-bit build (due to packaging constraints). Furthermore, Windows being 32-bit is not indicative of it being behind macOS; it is arguably more developed than macOS (e.g. Windows was first to ARM64, Windows was first to AMD64, Windows was first to mobile, etc). 64-bit is not inherently better. Applications on Windows remain 32-bit because it is advantageous. You do not pay the bloat of 8-bytes for pointers, which is a better for code density. It also results in a single build being more compatible across multiple machines (32-bit or 64-bit) and can also be run on ARM64. I suspect that question stems from the project using "win32" which is actually the name of the Windows API and the original platform for native C/C++ application development. See https://docs.microsoft.com/en-us/windows/win32/desktop-programming for more details about Win32. |
Beta Was this translation helpful? Give feedback.
The library is not limited to 32-bit (though it can be built 32-bit), and in fact the CI and testing is done exclusively on a 64-bit build (due to packaging constraints).
Furthermore, Windows being 32-bit is not indicative of it being behind macOS; it is arguably more developed than macOS (e.g. Windows was first to ARM64, Windows was first to AMD64, Windows was first to mobile, etc). 64-bit is not inherently better. Applications on Windows remain 32-bit because it is advantageous. You do not pay the bloat of 8-bytes for pointers, which is a better for code density. It also results in a single build being more compatible across multiple machines (32-bit or 64-bit) and can also be run on AR…