Object Linking and Embedding
en.wikipedia.org
en.wikipedia.org
OLE was the opposite of silod apps.
It was also a serious resource hog and that above bit of magic involves my disk thrashing and nearly a minute of waiting for things to happen. (I suspect I didn't have enough ram for both a photo editor and MS word!)
Still though, cool idea.
My source for this is a book on OLE that I read in the early nineties so I can't provide the exact quotes as I no longer even remember its title.
When that did not work (technically as well as commercially) and the internet was threatening to relegate Microsoft and its software to irrelevance they rebranded OLE as ActiveX and attempted a frontal assault on the opennes of the Web through the Internet Explorer browser and the proprietary ActiveX controls. Luckily for us the thing was full of security holes and more or less blew up in Microsoft's face as a bit of a PR disaster. And that's kids how the web was saved from the first corporitization attempt.
My favourite example of seeing them is VBA macro projects in office documents. The macros used to be stored in CDFs equivalent of a subfolder within a wider Word CDF document. When Office 2007 migrated from .doc to .docx, they just made the VBA project folder its own CDF file and stuck it in the new zip archive format
Since at least the 70s there has been a dream of the software industry that it could be more like the electronics industry: you purchase a set of components and assemble them into something that does what you want. This has never quite worked out like that. It always develops its own unique pathologies, like npm's sprawling software BOMs of hundreds of thousands of libraries.
This idea was ubiquitous in the 90s, only comparable to the AI hype today. All software was going to be written as components which could be combined and embedded into applications. It wasn't just Microsoft with OLE, the other behemoth was CORBA driven by IBM.
Eventually the web browser absorbed and leapfrogged the whole idea (despite, as you mention, the best attempts of the 'establishment' to kill the web).
For instance I was able to embed my emulators (written in C and C++), compiled to WASM, and an old assembler cmdline tool written in the 1990's in C89 compiled to WASI, and integrate those as 'components' into Visual Studio Code:
https://floooh.github.io/2023/12/31/vscode-wasm-wasi.html
That same WASM blob would run without recompilation in any environment which provides a WASM runner and a subset of web APIs (mainly WebGL and WebAudio), and the emulator WASI blob runs out of the box in any WASI runner.
If you think in terms of justifying expensive machines, then making everything revolve around individual "apps" makes sense, but once you're beyond that and think in terms of productivity workflows an app-oriented makes less sense. Computers are not about abstract applications of the tech, they're about produced work artifacts, which we can generically call compound documents, and those may be rich multi-media affairs with many different kinds of program contributing to the final experience.
At least, this was the OLE/OpenDoc argument. Things didn't work out that way but it's worth asking if that was due to implementation deficiencies or because the actual vision was bad.
Primary evidence in the case against OLE-style compound documents is that it's gone out of fashion and is hardly used anymore outside of office suites, and only hardly even there. Users don't seem to care and aren't asking for it back.
Primary evidence in the case for compound documents is the web. Web pages are arguably very similar to OLE style documents, but less engineered and without the ability to edit them. Nonetheless, the <iframe> or <object> tag is roughly similar to OLE's IOleInPlaceSite [1]. In earlier versions of Internet Explorer the <object> tag could in fact embed OLE objects, they are so conceptually similar. URLs are similar to "monikers", XML+XSLT had similar goals to OLE's structured storage (what OpenDoc called Bento) and so on.
I guess the critical difference is that the developer usability of the web is much higher. OLE/COM were the product of C++ architecture astronauts who didn't seem to care much about developer usability. Writing OLE components was a horrifically difficult experience even if you were using Borland's tools instead of Microsoft's. Writing web pages was easy.
OpenDoc was the ultimate expression of compound document purism. In OLE apps could embed other apps, but in OpenDoc there were no apps. Everything started with a blank generic document into which you embedded components and tied them together. Pre-made document templates were available that could approximate apps but they were always editable. It was a highly fungible and malleable computing environment, somewhat similar maybe to Squeak. Jobs was right to kill it though. Apple needed to focus on shipping a good implementation of a proven paradigm at that point in its history, not trying to reinvent the basics.
[1] https://learn.microsoft.com/en-us/windows/win32/api/oleidl/n...
I think our machines weren't up to it in the 90s. Simply the amount of memory it uses caused problems, and the tooling was a horror show.
Part of the reason I submitted this was imo it's how a virtual reality system should work, yet as you point out everyone now is in a "that's an app" mindset.
Microsoft still has deep integration between apps, even outside the direct Office trio (Word, Excel, PowerPoint). Most recently, there have been developments such as "Loop components", which let you embed components like "Checklist" or "Paragraph" or "Progress tracker" or "Table" or "Task list" into a Teams conversation, and I think some other programs too, and this is backed by (AFAIK) SharePoint. At work I haven't seen it used much, so I can't say whether anyone wants it at all, but at first look it sounds nice.
Then there's Unix philosophy; modern Linux systems are built out of tiny components that can be embedded, except instead of COM-like IPC, it's done through a mix of shelling out, exec() calls and filesystem operations. Ironically, Linux is going through its own period of appification - if Unix philosophy is like COM, then Docker, FlatPak, and other ways to containerize software are a push towards siloed out apps.
> OLE/COM were the product of C++ architecture astronauts who didn't seem to care much about developer usability.
I've dabbled in COM and DCOM several times over the past few decades (DirectX, old DCOM-based industrial protocols, ...), and I agree it's a special kind of hell that's laced with landmines on which you continuously step, but the dungeon keeper doesn't let you die until you finish the project... but honestly, it still feels better than the Web and modern distributed development. More raw, but also much less wasteful in terms of compute.
You probably meant dungeon master but had in mind one of the greatest PC games ever made.
Try out War for the Overworld if you haven't already, it's a modern and faithful continuation of the series without the original IP.
EDIT: I initially mistyped Overworld as Overlord, revealing that I played way too much StarCraft as a kid.
I always thought that the main reason MacOS is more appified ("siloed"?) than Linux is because when both programs are open-source, it becomes easier for one developer to make two programs ("projects"?) work more closely together. More precisely, it becomes easier for a developer to make a change that crosses a boundary between projects and get that change integrated into both projects. Unlike the situation with COM, there can be a great variety of methods ("implementation details"?) by which the two Linux projects start working together better.
Funny. Users aren't asking for OLE by name it's true, but there's a multibillion dollar integration industry out there. Consultants wiring up Salesforce into dozens of apps, plugin ecosystems, Zapier, the list is massive.
Users are SCREAMING at the top of their lungs for this.
They want a spreadsheet with updated data from Salesforce combined with info from Servicenow and some stock tickers. Local, web, punchcards, the user does not care.
Today there's a mess of Google Sheets with data pulled in from Zapier, but it's no difference to the user if it's Excel with OLE interfaces from local programs.
Thats just a guess tho, I only remember it being used for graphs that you made in Excel and could then paste into Powerpoint and still be able to make changes.
.. is Word macro viruses.
The old security model assumed that the "system administrator" and "apps" could be trusted, it was just the users which had to be segregated. The modern world has that the other way round: "system administrator" doesn't scale, apps absolutely cannot be trusted not to violate your privacy, and most devices are single-user. Protecting user data in a component system from hostile components is .. conceptually impossible?
The modern app environment (especially mobile) leans heavily on app scoped permissions, and sometimes even app session level permissions. Has anyone tried a component system that attempts component instance level permissions? (And maybe time gated ones at that).
Most COM APIs are quite painful to work with, but in many cases that's just bad API design (the D3D APIs show that it can also be a lot less painful).
Or at very least, all those scenarios where currently only in-proc COM in C++ is allowed, turn into external COM in whatever-you-fancy scenario.
...
It is currently impossible to use full MS Office to edit documents which exist within Teams. You can only use a web-based version of Office apps (which don't have same capabilities, same UI, etc.).
Sad. It's like nobody gives a fuck about user experience anymore...
What's the selling point of Windows? They made all these frameworks, Office, communication software like Teams, One Drive, etc. It is supposed to all work together. But it just doesn't.
Might as well use Linux where each app is on its own.