_     _             
                        _ __ | |__ | | ___   __ _ 
                       | '_ \| '_ \| |/ _ \ / _` |
                       | |_) | | | | | (_) | (_| |
                       | .__/|_| |_|_|\___/ \__, |
                       |_|    ...2022-11-13 |___/ 

What if there was only the OS ?

I've been a follower of the "OS should spawn processes and otherwise get out of the way" school since I learned what an OS was.. On my first computer, the C64, it was normal for programs to entirely disable parts of, or the entire operating system. Side note: I consider Kernal + BASIC to be the OS of the C64, but I digress. It seems like a beautiful idea, you run your application, that's it. I've disliked, and to some degree, still dislike the object oriented paradigm, but not the idea of smalltalk.. Why am I ranting? Struggle on! The idea that objects can provide some functionality, and provide that to the system is beautiful.. In a twisted and local way, that's what you get within a C++ program, and if you stretch your imagination, through dynamic loading of libraries, but.. Where the world ended up seems to be that we have the SO or DLL files and we get all the problems, but almost none of the benefits..

One benefit that I can think of is a niche, overriding DLLs and SOs to provide

updated functionality, for example, on my Windows 10 machine, when I want to play a game that has 3dfx vooodoo glide support, I usually use that, but I replace the glide2x.dll with a new version from the nGlide project, which translates the glide api into a modern API and also gives me control over resolution and stuff that the original program does not know anythig about..

My point is, such things are nice to be able to do, check my site, I have

a hook object that can be preloaded in front of Soldier of Fortune on Linux, which modifies a datastructure in the graphics engine to let you set your own screen resolution instead of having to accept the ones hard-coded into the game.

But these are niche uses, and very much confined to a realtively small percentage

of the general PC using population.

I think part of why we're missing out on the benefits of "smalltalkish" forms

of code-sharing is because the operating systems are doing almost nothing to encourage it.. It's almost as if there's a divide between libraries and programs.. Like, they'er so different, a program will use libraries, but libraries rarely use programs.. Programs usually provide functionality directly to the user, while libraries provide functionality only directly to programs. (Unix pipes is the exception, and my idea borrows a bit from that idea, but they're not where I want to end up at all).

What if we turned everything upside down.. What if there was ONLY the SYSTEM..

And everything was a plugin, literally, everything.. Your drivers, your web browsers your libraries, your shells and GUI and games.. All of it, plugins to the SYSTEM.. What does that even mean? I imagine the SYSTEM is bundled with some standard package of plugins for various things like some drivers and providers for things like TCP/IP and maybe some other protocols, maybe some encryption stuff like TLS and whatnot.. Some plugin to allow windows to be created and populated with widgets and drawable surfaces, and of course some standard set of widgets..

If one were to create a webbrowser for such a system.. One approach would be to

make a single plugin which provides an enduser activity "browse the web", it might make use of the TCP socket functionality provided by the OS and that's about it. It might go a step further and make use of the DNS functioality too.. It'd do that by requesting a DNS provider, basically telling the SYSTEM "I'm providing 'user activity / internet / HTTP browsing' under the name 'Mazolla Wetdog' and I need 'DNS resolution' and 'TCP sockets' to do it" furthermore, it might suggest the OS a particular plugin, like "system standard DNS resolver".. Internally, the browser plugin would still need to implement HTTP protocol details, TLS wrapping for HTTPS and whatever else is needed.. Assuming the SYSTEM came with TLS stuff, the browser could ask for those.. Even nicer was if the browser package has some nice TLS implementation which it provides as a plugin.. Then it can hint to the system, "I have a TLS implementation and I need a TLS implementation", a reasonable behaviour would then be for the system to link provide that particular TLS plugin to the browser activity when it's started.

Why does this matter?

It's a weak point, and a silly example, I'll rant on to a better one later.. But let's say you have an even better, or more trusted TLS implementation, imagine if your "browse the internet" activity was little more than a description of which functionalities to wire together to get a browser.. Then you'd just clone the activity, and, from the system gui, simply tell the system to provide your alternative tls implementation to the browser.. A bit like replacing a DLL, but without it being hackish and a "special thing".. A bit further, a browser may consist of "a window that can render a website" and "a website provider" which then again is made up of several subelements.. What if every buffer in my text-editor registered "I am a source of text, and I am a target of text".. When I open a file, I can chose a file-system plugin to provide the text to the buffer, but I could also use the HTTPS provider if I just wanted the source-code of some website directly into my buffer.. So, I'm a simp, and I chose to open a text-editor buffer with a file as a data source.. Now, my buffer is also a data source, so I can open an instance of my web-browser and instead of the website-provider being the HTTP backed one, link the browsers text-input to my text-editor buffers output, boom, whatever is in my text-editor buffer is instantly rendered in the web-browser, actually, I don't need a web-browser.. I could just spawn the HTML rendering engine and link that to my text-editors buffer.

Imagine how radically different it'd be to use a computer if we had a lot of nice

software packages, but they were all these pre-built lego-sets that we could easily rearrange and remix and combine across each-other, taking some functionality from your 3D editor and embed it into your spreadsheet for data visualization.. Whatever applications provide the right stuff.. Maybe one of your graphics packages has a really nice filter effect, but you want to apply it to the output of another program ? I don't think I can imagine it entirely.. It's so far from how we're used to thinking about computers, and I'm sure there is a lot of technical challenges (data exchange formats for instance) but I don't think they're impossible to fix.. Something like being able to declare which outputs you provide precisely, and exactly how you expect data you consume to look, and which fields are optional and which are required, and providing the user some means of resolving conflicts.. This rants me on the next benefit: forcing apis and formats to be well-thought out and as simple as they can be, when you're not only designing for the machine, but for the end-user, you can't just put flags all over the place, you can't just send messages that are needed for some internal state, you have to really think "How do I make this API end-user understandable and friendly" and if you can't do that, you're at the wrong abstraction layer anyway. Go one up or one down and try again. wtf was this..