Post by Kerry Main
Re: App backwards compatibility .. interesting development (not sure if
"With iOS 11, set to be unveiled in June at WWDC before it's rolled out
to in around six month's time, Apple looks set to remove support for
32-bit apps and will stop supporting those that don't run natively in
"SensorTower, an app research outfit, is claiming that Apple's move to
stop supporting 32-bit apps will see at least 187,000 apps, or eight
per cent of the App Store, rendered obsolete by iOS 11."
Perhaps something for VSI to consider for OpenVMS V10.. ok, maybe V11?
I'd laugh, but then I'd cry.
The vast majority of apps for OpenVMS are 32-bit, that's not changing
anytime soon, and we will be dealing with the hybrid 32-bit/64-bit
implementation for the foreseeable future.
I really like the OpenVMS 32-/64-bit design, though it intentionally
and centrally optimized for upward compatibility, and for mixing 32-
and 64-bit into one executable. New app development was not a central
target, which means we have a mix of descriptors and entry points and
pointers and preprocessor macros. Complexity. Working with the
64-bit parts of the DEC 32-/64-bit environment sometimes reminds me of
the fun of dealing with the address space on PDP-11/RSX-11.
Thankfully no TKB, but there are parallels to the effort involved with
Unlike DEC, Apple created a new a flat 64-bit address space, and
related tools that build 32- and 64-bit code, and fixed a whole pile of
other latent problems and limits in the process of that work. Unlike
DEC with OpenVMS, 32-bit and 64-bit code is not mixed in the same build
of the code, but can be present in the same binary. This is a little
confusing, in that a single executable file can contain separate
binaries, and macOS and iOS picks the appropriate binary for the
current system environment. Commonly one binary for 32-bit
environments, and one for 64-bit environments, though there are more
permutations for iOS devices. This is a so-called fat binary; more
formally a multi-architecture binary, or a universal binary.
With macOS and iOS, existing 32-bit code is unchanged. But for code
moving to 64-bit, Apple broke compatibility. Developers had to change
their code to migrate to 64-bit. Apple fixed many of the bugs and
limits in the old API when they did that, too. And the 32-bit and
64-bit apps can be combined into the same application package, and into
the same binary.
As for moving to 64-bit, the Apple migration to 64-bit started well
over a decade ago.
With iOS — which was based on macOS — Apple also implemented bitcode,
which allows Apple to generate the necessary executable binaries
directly for current and (likely) new devices, too. The closest
analog to this on OpenVMS is linking on site, and that's not at all
close to what bitcode provides.
Then there's the whole discussion of what going to a flat 64-bit
address space buys for OpenVMS. Which isn't much for the folks at
VSI. Going to a flat 64-bit address space is an investment in the
future for developers, and VSI — given our recent CPRNG discussions
among other threads — isn't really there yet.
Then — in the unlikely event this work gets scheduled — there's the
discussion of whether the existing 32-/64-bit environment should be
preserved — for reasons of upward-compatibility, after all — which just
heaps on more work for everybody involved. For VSI, and for end-user
developers that are looking to use the new features. Again,
upward-compatibility is not free. Absent infinite resources, catering
to apps that are not being actively maintained and are not being
updated inherently comes at the cost of new development, both for VSI
and for end-user developers. Upward-compatibility also completely
blocks various fixes and updates, too. Either because the changes
would be prohibitively expensive, or are simply not possible to
perform. But break too much compatibility too quickly or too
haphazardly, and don't give folks valuable reasons to upgrade to the
newer OpenVMS versions, and things (also) don't end well for VSI and
OpenVMS. Not a fun balance.
None of this is to state that Apple does everything correctly, nor that
VSI should follow all of what Apple does. Apple have had their share
of mistakes, too. VSI — and each of us doing development or support
or operations — should be aware of what else is going on from other
vendors, including Apple, Microsoft and Google, and in the open-source
community, and in areas such as regulatory environments, in security
designs and breaches and mechanisms, and suchlike. An operating system
is a huge project.
Pure Personal Opinion | HoffmanLabs LLC