5 ms·

In hindsight, I think Microsoft should have done the following, going back to the mid 90s: As soon as Java comes out and you see that some developers actually

In hindsight, I think Microsoft should have done the following, going back to the mid 90s: As soon as Java comes out and you see that some developers actually like AWT layouts, develop a C++ wrapper over Win32 that mimics that ability to lay out a UI in code. That would have muted my disgust at Win32 and MFC when I got Visual C++ 6 as a teenager. Not a new OS API, mind you; all of this has to be done in a way that works downlevel, back to Windows 95 and NT4. (I was using NT4 at my first job until I lost that job in early 2002.) When the industry discovers the pain of registering COM components and ActiveX controls for VB6 apps, come out with a new registration-free flavor of COM (edit: or maybe go straight to registration-free WinRT) that lets application developers just drop the DLL and OCX files in the same folder as the app. Again, not an OS feature, just new interfaces and conventions to be used by applications, components, and VB itself. Implement something like Chrome's installer and updater, so mere mortal application developers can have fast installation and smooth automatic updates. Something baked into the OS like MSIX is better, of course, but every advance has to work on the machines of users running old versions of Windows, or the rest of the industry will just ignore it. Every advance in UI technology and fashion should be done in a way that can be incrementally adopted in Win32 apps, as the parent discussed. Direct2D did this right; it's just a shame that the internal UI frameworks Microsoft built on top of Win32 and Direct2D were only internal. When developing a new high-level language like C# as an alternative to VB, go with ahead-of-time compilation, so mere mortal developers can ship self-contained, fast-starting applications that work on their users' older Windows machines. But also keep real VB alive; the jump from VB6 to VB.NET only further fractured the platform for third-party developers. Edit to add: Also don't lure Anders Hejlsberg away from Delphi. Perhaps Microsoft didn't fully appreciate the value of a third-party development environment, free of Microsoft's internal politics, that was enabling ISVs to kick ass with self-contained applications that exclusively targeted Windows. One of the most successful Windows-first apps of the 2000s, Skype, was developed in the early 2000s with Delphi. I think with these moves, Windows would have stayed dominant in desktop apps, possibly even preventing the rise of web apps.

pjmlp 4y ago
Officially, as answered by Anders on an interview, he was lured by former Borland colleagues, and he declined multiple times, until he saw there was time to move on from Borland. https://behindthetech.libsynpro.com/001-anders-hejlsberg-a-craftsman-of-computer-language https://behindthetech.libsynpro.com/001-anders-hejlsberg-a-c...
mike_hearn 4y ago
"Implement something like Chrome's installer and updater" MSIX does implement the same UX and comes with every Windows 10+ install, the runtime can be installed to older Windows too. So they did do this in the end. Conveyor produces them and it now also implements a web-like update UX (for macOS too) where the app checks for an update on every launch and will update/relaunch itself synchronously with no user intervention. Delta updates make it fast - on a decent internet connection like those we have here in Switzerland it's practically as fast to update to a new version and start a desktop app as loading a web app! I gotta say it feels great, quite different to the old desktop app feel. Especially neat is the way Windows can share files and even file blocks between unrelated apps, which means if you install an e.g. Electron or JVM app and then another one, Windows won't download the files twice, it'll hard-link them into place. So they can even share the underlying memory when the two apps are running, reducing memory usage! And if they're slightly different it'll only download the changed blocks. Why didn't MS do it 20 years ago? When Google's updater engine was new it was very controversial. We've all forgotten about it now, but the idea that apps would upgrade themselves silently, in the background, if you weren't even running the app at all, and you'd not even be notified, well this made a lot of programmer control-at-any-cost types extremely angry. Google did it anyway because Larry Page had an unusually extreme focus on simplicity and wanted a web-like experience, so pushed it through despite opposition. Now it's accepted as the right way to do things. Page doesn't get enough credit IMO for his product management insight and sheer force of will. The web would probably still have risen, but maybe a lot slower. Even a hypothetical much improved Win32 wasn't ever going to be a good way to represent documents, and on the web a lot of "apps" are closer to interactive documents than apps, or evolve out of documents. Microsoft didn't and still doesn't have anything in the platform that recognizes this. The goal of Conveyor is to make it as easy to distribute desktop apps as it is for web apps (or much easier if you need things like hardware access or offline support, of course). The long term idea is that if it's easy to do stuff outside the browser, it'll become possible to explore alternative architectures that are maybe more appropriate than HTML. One idea I keep coming back to is file associations. The web doesn't have any such concept because it doesn't recognize that apps can exist independently from documents. Imagine there's a simple way to form a little graph, such that a piece of data can point to another node using edge labels like "view", "edit", "transform-to:text/json" or whatever. These are like the verbs that file explorers allow apps to associate with files. And then the target node can itself be a file like a script with an association like "execute". By following the links you build up the entire software stack needed to work with the target file, you can sandbox that stack and execute it, and users can override the associations for any kind of node to replace the default functionality with something else. This would make the original XML vision of separating data and presentation actually happen because you can define a custom Markdown+JSON format that holds the content for your blog, associate it with a separate program that renders that to <whatever>, associate that in turn with something that renders your <whatever> format to pixels and so on. I think that sort of addition would have been a possible way that Microsoft/Apple/Linux could have combatted the competitive threat of the web. But nobody was thinking about it.

pjmlp 4y ago

Officially, as answered by Anders on an interview, he was lured by former Borland colleagues, and he declined multiple times, until he saw there was time to move on from Borland. https://behindthetech.libsynpro.com/001-anders-hejlsberg-a-craftsman-of-computer-language https://behindthetech.libsynpro.com/001-anders-hejlsberg-a-c...

mike_hearn 4y ago

"Implement something like Chrome's installer and updater" MSIX does implement the same UX and comes with every Windows 10+ install, the runtime can be installed to older Windows too. So they did do this in the end. Conveyor produces them and it now also implements a web-like update UX (for macOS too) where the app checks for an update on every launch and will update/relaunch itself synchronously with no user intervention. Delta updates make it fast - on a decent internet connection like those we have here in Switzerland it's practically as fast to update to a new version and start a desktop app as loading a web app! I gotta say it feels great, quite different to the old desktop app feel. Especially neat is the way Windows can share files and even file blocks between unrelated apps, which means if you install an e.g. Electron or JVM app and then another one, Windows won't download the files twice, it'll hard-link them into place. So they can even share the underlying memory when the two apps are running, reducing memory usage! And if they're slightly different it'll only download the changed blocks. Why didn't MS do it 20 years ago? When Google's updater engine was new it was very controversial. We've all forgotten about it now, but the idea that apps would upgrade themselves silently, in the background, if you weren't even running the app at all, and you'd not even be notified, well this made a lot of programmer control-at-any-cost types extremely angry. Google did it anyway because Larry Page had an unusually extreme focus on simplicity and wanted a web-like experience, so pushed it through despite opposition. Now it's accepted as the right way to do things. Page doesn't get enough credit IMO for his product management insight and sheer force of will. The web would probably still have risen, but maybe a lot slower. Even a hypothetical much improved Win32 wasn't ever going to be a good way to represent documents, and on the web a lot of "apps" are closer to interactive documents than apps, or evolve out of documents. Microsoft didn't and still doesn't have anything in the platform that recognizes this. The goal of Conveyor is to make it as easy to distribute desktop apps as it is for web apps (or much easier if you need things like hardware access or offline support, of course). The long term idea is that if it's easy to do stuff outside the browser, it'll become possible to explore alternative architectures that are maybe more appropriate than HTML. One idea I keep coming back to is file associations. The web doesn't have any such concept because it doesn't recognize that apps can exist independently from documents. Imagine there's a simple way to form a little graph, such that a piece of data can point to another node using edge labels like "view", "edit", "transform-to:text/json" or whatever. These are like the verbs that file explorers allow apps to associate with files. And then the target node can itself be a file like a script with an association like "execute". By following the links you build up the entire software stack needed to work with the target file, you can sandbox that stack and execute it, and users can override the associations for any kind of node to replace the default functionality with something else. This would make the original XML vision of separating data and presentation actually happen because you can define a custom Markdown+JSON format that holds the content for your blog, associate it with a separate program that renders that to <whatever>, associate that in turn with something that renders your <whatever> format to pixels and so on. I think that sort of addition would have been a possible way that Microsoft/Apple/Linux could have combatted the competitive threat of the web. But nobody was thinking about it.