[HN Gopher] Recreating the lost SDK for a 42-year-old operating ...
       ___________________________________________________________________
        
       Recreating the lost SDK for a 42-year-old operating system:
       VisiCorp Visi On
        
       Author : nkali
       Score  : 92 points
       Date   : 2025-12-04 10:25 UTC (3 days ago)
        
 (HTM) web link (git.sr.ht)
 (TXT) w3m dump (git.sr.ht)
        
       | jdougan wrote:
       | Wow, just what I wanted for Christmas. Back in the day I found
       | VisiOn's approach fascinating since almost everything at the time
       | was either more tightly integrated or completely unintegrated.
       | 
       | 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.
        
       | msla wrote:
       | 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.
        
         | jdougan wrote:
         | The latter 2 usages are pretty much the same. They just have
         | different virtual instruction sets.
        
           | msla wrote:
           | > The latter 2 usages are pretty much the same.
           | 
           | Only if you ignore most of reality, sure.
        
         | retrac wrote:
         | 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.
        
           | bananaflag wrote:
           | Also in this OS textbook
           | 
           | https://pages.cs.wisc.edu/~remzi/OSTEP/
        
           | msla wrote:
           | > On Linux or Windows, processes are provided with the
           | illusion of infinite memory.
           | 
           | OK, how does this apply to what MS-DOS was doing? Remember
           | that VisiOn is an MS-DOS shell.
        
           | 01HNNWZ0MV43FF wrote:
           | Yeah I remember an ad for an early x86 OS saying, "Each
           | program here is running on a virtual 8086" and I was like
           | "No... wait yes?".
           | 
           | Virtual machines are such a cool idea that they just keep
           | getting reinvented. You can solve any problem with more
           | abstraction!
        
       | dsand wrote:
       | My partner Elaine Gord was on VisiOn's C compiler team in
       | 1982-1984 with two others. They experimented with having two
       | instruction sets: the native 8088 code for best performance, and
       | a C virtual machine bytecode for code density. The two modes were
       | mixed at the function level, and shared the same call/return
       | stack mechanism. This was terrible for speed, but was thought
       | necessary because the target machines did not have enough ram for
       | the total VisiOn functionality. I don't know if the bytecode
       | scheme got into "production".
        
         | pdw wrote:
         | All of Microsoft's applications used to do that! The 16-bit
         | versions of Word, Excel, PowerPoint, etc all were implemented
         | using bytecode. That technology was only integrated in
         | Microsoft C and made public in 1992 [1], before that the
         | Microsoft applications group used their own private C
         | toolchain. A copy of it can be found in the Word 1.1 source
         | release [2] ("csl").
         | 
         | [1] https://sandsprite.com/vb-
         | reversing/files/Microsoft%20P-Code... [2]
         | https://github.com/danielcosta/MSWORD
        
           | reactordev wrote:
           | C was very much the _Javascript_ of its day. Hand rolling
           | toolchains and compilers to the bytecode they knew and loved
           | (or despised).
           | 
           | 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.
        
           | classichasclass wrote:
           | I think Multiplan for 8-bit systems was implemented in a
           | similar fashion, which enabled it to be widely ported.
        
       | cramcgrab wrote:
       | Yep Mitch Kapor and the eff.
        
       ___________________________________________________________________
       (page generated 2025-12-07 23:02 UTC)