Product Launch
anonymous
1 points
18 comments
Posted29 days agoActive17 days ago
Visi On
git.sr.htlaunchedlibrarydevelopers
Key Features
recreated SDK for Visi Oncompatibility with 42-year-old operating systemreverse-engineered API
Tech Stack
C
Key Features
Tech Stack
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.
Only if you ignore most of reality, sure.
No, not really.
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
OK.
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.
OK, how does this apply to what MS-DOS was doing? Remember that VisiOn is an MS-DOS shell.
Virtual machines are such a cool idea that they just keep getting reinvented. You can solve any problem with more abstraction!
[1] https://sandsprite.com/vb-reversing/files/Microsoft%20P-Code... [2] https://github.com/danielcosta/MSWORD
For p-code references, the relevant blog post is https://hardcoresoftware.learningbyshipping.com/p/003-klunde....
There was a proprietary programming language called CSL, also named after CharlesS. This language, based on C, had a virtual machine, which made it easier to run on other operating systems (in theory) and also had a good debugger—attributes that were lacking in the relatively immature C product from Microsoft.
The blog post included excerpts from internal MS docs for apps developers. An OCR version of one such page in the blog post follows:
====
One of the most important decisions made in the development of Multiplan was the decision to use C compiled to pseudo-code (Pcode). This decision was largely forced by technological constraints. In early 1981, the microcomputer world was mainly composed of Apple II's and CP/M-80 machines; they had 8-bit processors, and 64K of memory was a lot; 128K was about the maximum. In addition, each of the CP/M-80 machines was a little different; programs that ran on one would not automatically run on another. Pcode made the development of ambitious applications possible; compiling to machine code would have resulted in programs too big to fit on the machines (even with Pcode it was necessary to do a goodly amount of swapping). It also allowed us to isolate machine dependencies in one place, the interpreter, making for very portable code (all that was necessary to port from one machine to another was a new interpreter). For Multiplan, this was an extremely successful strategy; it probably runs on more different kinds of machines than any other application ever written, ranging from the TI/99 to the AT&T 3B series.
Of course, Pcode has its disadvantages as well, and we've certainly run into our share. One disadvantage is that it's slow; many of our products have a reputation for slowness for exactly that reason. There are of course ways to speed up the code, but to get a great deal of speed requires coding a goodly amount in tight hand-crafted assembly language. Another disadvantage is our Pcode's memory model. Since it was originally designed when most machines had very little memory, the original Pcode specification supported only 64K of data; it was not until Multiplan 1.1 was developed in early 1983 that Pcode was extended to support larger data spaces. A final disadvantage of Pcode is that we need our own special tools in order to develop with it; most obviously these include a compiler, linker, and debugger. In order to support these needs, there has been a Tools group within the Applications Development group almost from the beginning, and we have so far been largely unable to take advantage of development effort in other parts of the company in producing better compilers and debuggers. (It should be noted that the Tools group is responsible for considerably more than just Pcode support these days.)
Although portability was one of the goals of using Pcode, it became apparent fairly early on that simply changing the interpreter was not sufficient for porting to all machines. The major problem lay in the different I/O environments available; for example, a screen-based program designed for use on a 24 by 80 does not adapt well to different screen arrangements. To support radically different environments requires radically rewriting the code; we decided the effort was worth it for two special cases: the TRS-80 Model 100 (first laptop computer) and the Macintosh. In retrospect, the Model 100 was probably not worth the effort we put into it, but the Macintosh proved to be an extremely important market.
====
P-Code was a very important technology for Microsoft's early apps. Cross platform was one reason, as Steven writes. It was also very important for reducing the memory size of code. When I started, we were writing apps for 128k (K, not m or g) RAM Macs. There were not hard drives, only 400k floppy disks. (Did I mention we all had to live in a lake?)
P-Code was much smaller than native code so it saved RAM and disk space. Most Macs had only one floppy disk drive. A market risk for shipping Excel was requiring 512k Macs with two disk drives which allowed for the OS and Excel code to live on the first drive and user's data on the second. Mac OS did not have code swapping functions, each app had to roll its own from memory manager routines, so the P-Code interpreter provided that function as well.
On early Windows versions of Excel the memory savings aspect was extremely important. The size of programs grew as fast as typical RAM and hard disk sizes for many years so saving code size was a primary concern. Eventually Moore's Law won and compilers improved to where the execution trade-off was no longer worth it. When Windows 95 introduced 32 bit code these code size dynamics returned for a different reason – IO bandwidth. 16 bit Excel with P-Code outperformed 32 bit Excel in native code in any scenario where code swapping was needed. Waiting for the hard drive took longer than the ~7x execution overhead of the P-Code interpreter.
I am surprised to hear Steven say that the app teams and Excel in particular were looking in any serious way at the Borland tools. The reality was the CSL compiler had a raft of special features and our only hope of moving to a commercial tool was getting the Microsoft C team to add the features we needed. This was the first set of requirements that came from being the earliest GUI app developers. Because of the early performance constraints a lot of "tricks" were used that became barriers to moving to commercial tools. Eventually this was all ironed out, but it was thought to be quite a barrier at the time. About this time the application code size was starting to press the limits of the CSL P-Code system and we really needed commercial tools.
Technically it was the linker not the compiler. The Excel project was getting big and the apps Tools team was under resource pressure to stop investing in proprietary tools while at the same time the C Tools group was under pressure to win over the internal teams. It was *very* busy with the Systems team, particularly the NT team, on keeping them happy. We’re still 5 years away from Excel and Word getting rid of PCode. Crazy to think about. But the specter of Borland was definitely used by management to torment the Languages team who was given a mission to get Microsoft internally using its tools.This is awesome history. Formal history only remembers the what’s, the when’s, rarely does it catalog the why’s, or how’s. The decision making process of those early programmers helped shape a whole industry.
Maybe someone could do the the old Reason software bus based system next? As detailed in Jan 1984 Byte magazine. Lord only knows if there are surviving copies anywhere in the world.
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.