3 ms·

Longhorn was a failed version of Windows after Windows XP and before Windows Vista. Longhorn was planned to be a dramatic follow-up version of Windows XP in wh

Longhorn was a failed version of Windows after Windows XP and before Windows Vista. Longhorn was planned to be a dramatic follow-up version of Windows XP in which the Windows shell was rewritten on top of .NET with three main pillars: communication (WCF), presentation (WPF), and data (WinFS). WinFS was a new filesystem based on a relational database engine (SQL Server). Longhorn was similar to a previous failed Windows release (Cairo). Longhorn was built on .NET whereas Cairo was built on COM. Longhorn used a new filesystem based on SQL whereas Cairo had a new object-oriented file store. Longhorn use Avalon for the shell with concepts for people/contacts whereas the Cairo used Outlook. Before it became an Office application, Outlook started life as the new Cairo shell in which emails, calendars, task were integrated into explorer. You could do advanced grouping, tagging, and filtering on files. In fact, the first version of Outlook, Outlook 97, as an Office application allowed you to view the file system just like emails. Longhorn was several years late before the Windows release was canceled with no clear end date in sight. A reset was directed to produced an incremental new release of Windows called Windows Vista. It would be purely native and ship in a year and a half. The .NET dependency "Bet on .NET" was jettisoned, and all Window's dependencies needed to be fully released rather than works in progressed. WCF, WPF were released independently. WinFS was killed because it was too slow. See https://longhorn.ms/the-reset/ https://longhorn.ms/the-reset/

pjmlp 5y ago
Apparently Cairo's lesson wasn't good enough, so they ended up rewriting all Longhorn stuff mostly in COM and since it was such a good idea we got WinRT (IInspectable + .NET metadata) as "improvement". Which kind of was, had the respective teams not botched the whole idea with WinRT, UAP, UWP, replacing C++/CX with toolless C++/WinRT, left .NET Native stagnate,.... So now we get WinUI, Reunion sorry AppSDK, and the whole marketing with deemphasis on the COM love of WinRT high marketing push. I feel if there was some actual real cooperation across all the business units instead of the feudal wars, either Cairo or Longhorn would have worked out quite well. What to expect when it was easier for contractors to navigate across units, then asking for stuff directly.
- hdjjhhvvhga 5y ago
  Yeah, what I liked about the 90s you basically got MFC and it was basically it, you could create any desktop app and only waited for incremental upgrades. MFC was supported by Borland and Symantec, so basically whatever you choose you could quickly create a Windows GUI app. What I dislike about the current situation is the lack of certainty as to which toolkit I should invest my time in as I'm sure someone at Microsoft will change their minds again.
  - pjmlp 5y ago
    C++/WinRT tooling is so bad, that MFC feels modern. Ok, I got the point that they decided to stop doing language extensions and C++/CX was a dead end. Surely the PM that signed the idea to replace C++/CX, could have spent one minute considering not to ship a development experience that is worse than MFC. In 30 years haven't they had time to add syntax highlighting and code completion to IDL files? Ah, and the Windows team then ignores C++/WinRT on their own samples, and use their own internal WIL framework instead. https://github.com/microsoft/wil https://github.com/microsoft/wil So you get some samples on MSDN now that after being rewritten from C++/CX into C++/WinRT, are also tainted with WIL library types
  - blackoil 5y ago
    Practical reasons why Electron is winning. A universal base framework and language. Choice of popular development framework, UI and other libraries and million of developers.
    - pjmlp 5y ago
      Electron is winning because people are lazy, really. I do Web development alongside native, and would never pick Electron unless obliged by customer requirements to act accordingly. What to just use HTML/CSS/JS instead of the native OS capabilities? Use Web widgets, PWAs, daemons/services with local browser UI. No need to install hundreds of Chrome instances, and have them run in parallel. If you go with daemons/services with local browser UI, you can even use microservices and a distributed cluster for your app, what about that? Maybe it is worth of an HN blog post.

pjmlp 5y ago

Apparently Cairo's lesson wasn't good enough, so they ended up rewriting all Longhorn stuff mostly in COM and since it was such a good idea we got WinRT (IInspectable + .NET metadata) as "improvement". Which kind of was, had the respective teams not botched the whole idea with WinRT, UAP, UWP, replacing C++/CX with toolless C++/WinRT, left .NET Native stagnate,.... So now we get WinUI, Reunion sorry AppSDK, and the whole marketing with deemphasis on the COM love of WinRT high marketing push. I feel if there was some actual real cooperation across all the business units instead of the feudal wars, either Cairo or Longhorn would have worked out quite well. What to expect when it was easier for contractors to navigate across units, then asking for stuff directly.

hdjjhhvvhga 5y ago
Yeah, what I liked about the 90s you basically got MFC and it was basically it, you could create any desktop app and only waited for incremental upgrades. MFC was supported by Borland and Symantec, so basically whatever you choose you could quickly create a Windows GUI app. What I dislike about the current situation is the lack of certainty as to which toolkit I should invest my time in as I'm sure someone at Microsoft will change their minds again.
- pjmlp 5y ago
  C++/WinRT tooling is so bad, that MFC feels modern. Ok, I got the point that they decided to stop doing language extensions and C++/CX was a dead end. Surely the PM that signed the idea to replace C++/CX, could have spent one minute considering not to ship a development experience that is worse than MFC. In 30 years haven't they had time to add syntax highlighting and code completion to IDL files? Ah, and the Windows team then ignores C++/WinRT on their own samples, and use their own internal WIL framework instead. https://github.com/microsoft/wil https://github.com/microsoft/wil So you get some samples on MSDN now that after being rewritten from C++/CX into C++/WinRT, are also tainted with WIL library types
- blackoil 5y ago
  Practical reasons why Electron is winning. A universal base framework and language. Choice of popular development framework, UI and other libraries and million of developers.
  - pjmlp 5y ago
    Electron is winning because people are lazy, really. I do Web development alongside native, and would never pick Electron unless obliged by customer requirements to act accordingly. What to just use HTML/CSS/JS instead of the native OS capabilities? Use Web widgets, PWAs, daemons/services with local browser UI. No need to install hundreds of Chrome instances, and have them run in parallel. If you go with daemons/services with local browser UI, you can even use microservices and a distributed cluster for your app, what about that? Maybe it is worth of an HN blog post.