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.
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.
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.
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?
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.
[+] [-] devbent|1 year ago|reply
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.
[+] [-] abraxas|1 year ago|reply
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.
[+] [-] layer8|1 year ago|reply
[+] [-] flohofwoe|1 year ago|reply
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.
[+] [-] mike_hearn|1 year ago|reply
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...
[+] [-] fidotron|1 year ago|reply
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.
[+] [-] TeMPOraL|1 year ago|reply
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.
[+] [-] xnx|1 year ago|reply
[+] [-] arcbyte|1 year ago|reply
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.
[+] [-] MrBuddyCasino|1 year ago|reply
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.
[+] [-] pjc50|1 year ago|reply
.. 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?
[+] [-] andrewstuart|1 year ago|reply
[+] [-] julian_t|1 year ago|reply
[+] [-] flohofwoe|1 year ago|reply
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).
[+] [-] pjmlp|1 year ago|reply
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.
[+] [-] fl0ki|1 year ago|reply
[+] [-] PeterStuer|1 year ago|reply
[+] [-] anonzzzies|1 year ago|reply
[+] [-] killerstorm|1 year ago|reply
...
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.
[+] [-] chasemiller|1 year ago|reply