unless a 64-bit version had some way of running 32-bit externals
Pleeease, let's not call it "64-bit" vs. "32-bit". Those terms usually refer to the CPU target architecture. It's "single precision" vs. "double precision"
so any externals built for previous versions would crash
IOhannes added a clever mechanism to avoid runtime crashes. Incompatible externals will instead refuse to load.
What we need is to find an easy way to create "fat" binaries (containing both single and double precision of the same library) and/or come up with a naming convention, so both versions can co-exist (similar to how we use ".*_amd64" and ".*_i386" to distinguish between 64-bit and 32-bit Intel binaries).
it would be effectively a different program, not just a new version.
I would say it's neither. It's just a build option.
Christof
On 24.11.2020 16:07, Martin Peach wrote:
On Tue, Nov 24, 2020 at 5:07 AM jayrope jayrope@gmail.com wrote:
Why do we need _any_ name change? Any obvious version jump would do it already, 0.6, no?
A 64-bit Pd would not be compatible with any previous version because all the memory structures would be differently sized, so any externals built for previous versions would crash. While any patches using vanilla objects would still work, unless a 64-bit version had some way of running 32-bit externals in parallel, it would be effectively a different program, not just a new version.
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list