[Info-vax] redbean and the Actually Portable Executable
Stephen Hoffman
seaohveh at hoffmanlabs.invalid
Mon Jun 20 16:00:25 EDT 2022
On 2022-06-20 18:35:05 +0000, Bill Gunshannon said:
> On 6/20/22 14:28, Arne Vajhøj wrote:
>> On 6/20/2022 12:02 PM, Stephen Hoffman wrote:
>>> On 2022-06-20 13:21:42 +0000, plugh said:
>>>> "Compile and run on any x86 OS"...
>>>
>>> Very clever proof-of-concept work, though probably not going to be all
>>> that workable for production apps given the shifting foundations, and
>>> with increasing requirements for app security.
>>>
>>> As alternatives go, WebAssembly is a shade less hackish, for the folks
>>> that do need cross-platform portability: https://webassembly.org
>>>
>>> Apps can be built to JavaScript, too. As has been posted around here
>>> before: https://emscripten.org and https://bellard.org/jslinux/ and
>>> such.
>>>
>>> And apps running directly on JRE are yet another portable alternative,
>>> and those apps are rather more supportable.
>>>
>>> OpenVMS does have an older JRE available (based on OpenJDK 8), though
>>> no Wasm support and/or emscripten support and/or Wasmer
>>> https://wasmer.io support.
>>
>> The reality is that in 2022 it is more normal to run the same stuff on
>> any platform than not.
>
> UCSD tried that back in 1974. It was popular for about 6 or 7 years.
The 1970s-era UCSD Pascal and its p-Machine and the Terak hardware were
(in aggregate) not known for stability. Things have gotten vastly
better in the ensuing ~40 years.
As for ABI compatibility, JRE/JDK/JVM, WebAssembly, Lua, Dalvik,
CIL/CLR/.NET, and a number of other bytecode implementations are all
based on the same ideas that were involved with the UCSD p-Machine and
its p-code scheme, yes.
The redbean webserver and APE are all about ABI compatibility. This
being roughly analogous to a low-overhead "containerization" or
"virtualization" for executables, as an alternative to run-time
executable translation tools including DECmigrate and Rosetta.
>> Scripts (Python, JavaScript, PHP, Ruby, Perl etc.), JVM languages
>> (Java, Kotlin, Scala, Groovy), and CLR languages (C#, VB.NET, F#) far
>> outweigh the traditional native languages in usage.
>
> Wonder how many of these will last that long and actually run on
> anything other than the PC. :-)
Sun's replacement for COBOL (Java) isn't going away.
Which platforms have a JIT is another part of that whole discussion,
where app performance is a consideration.
The rest of that list of languages will run as long as its proponents
keep profiting from it too, same as usual.
Same as Oracle with Java, Microsoft would prefer CIR/CLR/.NET
everywhere and with Mono and VSC and ilk, whether they ever get much
traction?
"Write once, debug everywhere" was one reference to this (promised) ABI
portability. JRE/JDK/JVM does pretty well, here.
And once you're using JRE/JDK/JVM, you've moved your dependency from
the software and hardware platform vendor(s) to Oracle or OpenJDK or
whoever is providing the bytecode engine; the UCSD p-Machine analog.
Or folks consolidate the apps to Linux and/or Windows of course, or to
whatever else, as has been the common approach for many sites.
--
Pure Personal Opinion | HoffmanLabs LLC
More information about the Info-vax
mailing list