It's interesting how this article deconstructs the buzzwords used in the marketing material to get from "VisiOn is a multitasking object-oriented OS using a VM to be portable" to "VisiOn is a DOS shell that uses C structs in a documented API and was never meaningfully portable"
Seriously, the "VM" thing is stupid:
> The term "virtual machine" used by VisiOn developers means something different from what we mean by the words "virtual machine" today. The closest word we use today would be "API". That's right, Visi On applications use a cross-platform API. Just like almost any other operating system today. I bet it was a really cool idea back in 1983, though.
As if VM isn't overloaded enough already (quick: does it mean "Virtual Memory", "Virtual Machine" as in the JVM, or "Virtual Machine" as in Xen?) using it to mean "API" is just dishonest.
Processes on modern operating systems are a type of virtual machine. On Linux or Windows, processes are provided with the illusion of infinite memory. And there is the illusion of infinite parallel threads of execution, bounded only by storage. That is a kind of virtualization, just not full machine virtualization.
At the machine level the boundary between machine instructions and system calls and API becomes blurry. If you don't have a floating point unit, the instructions trap and a routine in the kernel can perform the same thing. Instruction sets are APIs. Many operating systems present their system calls as if they were special machine instructions.
This kind of phrasing is less common today, where "virtual machine" is usually equivalent to "full machine virtualization", but you'll encounter this broader sense in earlier literature.
The Visi-On API provides a handle-based memory manager. Handles are a kind of managed pointer that allow memory blocks to be moved around even though the hardware does not have virtual memory. So long as the program always follows the rules on acquiring and releasing the handle before using the underlying pointer, it enables a kind of poor man's virtual memory. The first version of Mac OS and Windows 3.x worked in a similar way. I'm guessing that the designers of Visi-On thought of this, and the other abstractions the API provides, as a kind of virtualization.
Hypervisor VM: emulates a virtual computer with virtual, emulated hardware, but a simulated version of the same CPU as the host, allowing 1 OS to run under another.
E.g. Xen, VMware, KVM, bhyve
Bytecode VM: emulates a partial virtual environment, with an emulated CPU and some form of conversion or translation from virtual environment to the underlying real API and real OS, allowing programs to execute on radically different OSes on different CPUs.
E.g. JVM, MoarVM, Parrot VM, Dis in Inferno
Emulator VM: emulates a virtual computer with virtual, emulated hardware, including a virtual CPU.
E.g. MESS, RetroVM, ZesaruX
Container: emulates an OS from userland down, but shares the same OS kernel across instances.
E.g. Docker, LXC, LXD, Incus, FreeBSD jails, Solaris Zones
Seriously, the "VM" thing is stupid:
> The term "virtual machine" used by VisiOn developers means something different from what we mean by the words "virtual machine" today. The closest word we use today would be "API". That's right, Visi On applications use a cross-platform API. Just like almost any other operating system today. I bet it was a really cool idea back in 1983, though.
As if VM isn't overloaded enough already (quick: does it mean "Virtual Memory", "Virtual Machine" as in the JVM, or "Virtual Machine" as in Xen?) using it to mean "API" is just dishonest.