I remember back in the 90s being able to paste a file from, iirc, Corel Draw, into MS word, click on it, and the full set of drawing tools showed up.
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!)
Bill Gates dreamed up creating a single program that would allow you to create content regardless of whether you wanted a document a presentation or a spreadsheet. The office app was to be merged into a single unified app from which all kinds of content could be created and mixed/matched in a single file. A pretty useless idea if you ask me but Microsoft somehow believed it would be revolutionary.
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.
I was told at the time (but I have no clue if it's true or not; it sounded plausible), that the dream was that companies/users could just roll their own applications from OLE components. So if your company workflow for some of the staff would require Word + Excel + Photoshop working in some way together, you would add these 3 to an empty application, hook them up with VBA (which was already included with the empty application) and then write it to an installer. The file format out/in would indeed combine these 3. It still sounds plausible when I write it. And not a bad idea (besides maybe the fileformat, unless you can easily untangle maybe).
The file format exists, its Compound Document Files which are effectively just a little FAT filesystem in a file from memory. both Microsoft and 3rd parties (...Autodesk maybe?) use them.
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
> that the dream was that companies/users could just roll their own applications from OLE components
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).
It’s ironic that in the era of the hyperlinked world wide web, we are farther than ever from that vision of linkable and embeddable software components and application interoperability.
Excuse me jumping on the hype train for a bit, but in a way the web and wasm is just that.
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:
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.
OLE and OpenDoc feel a bit nostalgic because they were the last time anyone tried to really rethink the desktop paradigm (and therefore computing productivity), spinning it away from a machine-oriented "app" mindset towards a data-oriented "doc" mindset. The idea of everything revolving around apps is in some ways a bit odd, if you think about it. App is short for application, and we call apps apps because in the earliest days of computers the most common question was "but what are they good for?". Well, here's an application of computers: running the numbers. Here's another application for computers: writing letters. Etc.
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.
> 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.
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.
> 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.
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.
Yeah, I thought of that game when writing that sentence. Thanks for the recommendation; I've never heard of "War for the Overworld", I'll check it out!
EDIT: I initially mistyped Overworld as Overlord, revealing that I played way too much StarCraft as a kid.
>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.
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.
How often does that happen though? In practice very few developers work that way, and Mac apps tend to interact with each other more/better than Linux apps because of things like Cocoa services that aren't too hard to implement and provide N:M "thin waist" rallying points around common interaction patterns.
Google Wave was a pretty radical reimagining, but it was a little too far ahead of its time technologically and way too far ahead of its time conceptually.
> Users don't seem to care and aren't asking for it back.
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.
I suspect OLE was mainly useful when you didn’t have networked file storage that was easy to link to, so you had to stuff a file into another file in order to easily access both.
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.
> Primary evidence in the case against OLE-style compound documents
.. 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?
I think that is a good enough point to be worth trying to counter it.
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).
To be fair, OLE and malicious office macros aren't actually related except that they use a common file format sometimes. Rest of the point is solid though.
Arguably the only good and still relevant part of OLE is COM by way of providing a stable C-ABI-tunnel for versioned C++ APIs in Windows system DLLs (but also trivially mappable to other language bindings like C# or Rust), e.g. it's the stable and backward compatible C++ ABI that C++ compilers never were able to agree on ;)
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).
When I started out self-teaching programming on Windows with Visual Studio, in high school long before university, my greatest fear is that I might one day have to understand COM, OLE, and ActiveX. Luckily some friends had already taken an interest in Linux and BSD, radicalizing me in that direction instead. I made a whole career writing backend services for datacenters and still couldn't tell you the first thing about OLE.
OLE as implemented in compound documents might have been a nightmare, but later generations of COM weren't half bad and led to the arguably very nice .Net platform.
20 years ago I made an ActiveX component which can show an interactive 3D scene in any Office app or in the browser. I was able to make in just a few weeks.
...
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.
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.