4 ms·

I'm not sure where you're getting "COM has been the underlying driving technology of Windows since Vista". COM and OLE, which is based on COM, have been a core

by tmzt 6y ago

I'm not sure where you're getting "COM has been the underlying driving technology of Windows since Vista". COM and OLE, which is based on COM, have been a core part of the Windows shell since at least Windows 95/NT 4.0/IE 4. You can see this in the registry where shell extensions are simply registered OLE Components, using OLE Activation to to register themselves as toolbars, folder views, context menus and additional commands in context menus. If you are referring to drivers or core OS concepts at a lower level, you may be right, but DirectX and class drivers were already using COM in places before Vista. COM is a standard vtable implementing a single core interface, called IUnknown which provides a method of reference counting as well as a way to look up implementaions of specific other interfaces from a given pointer. These interfaces dervive from that base, so they can always be cast as IUnknown. The rest builds on this base. source: Inside OLE and Inside Windows 95 https://books.google.com/books/about/Inside_OLE.html?id=adpwQgAACAAJ https://books.google.com/books/about/Inside_OLE.html?id=adpw... https://www.bookdepository.com/Inside-Windows-95-Deluxe-Edition-Jim-Boyce/9781562056957 https://www.bookdepository.com/Inside-Windows-95-Deluxe-Edit... Edit: saw the reply below, the specific Longhorn components only expanded the scope of what is extensible to include searchable/virtual/indexed filesystem extensions and few other places, based on the innovative concepts in Longhorn. My reading of your comment originally was that Vista was a departure from what came before, though it appears that it may have been intended to say it was more of a return to the simpler COM.

deleted 6y ago
[deleted]
pjmlp 6y ago
Maybe I should have phrased it in another way. For you to get where I am coming from, for me Longhorn only failed due to the usual set of politics between DevDiv and WinDev that those of us on Windows know so well throughout the years. Had they actually worked together and Longhorn, with .NET based stack would have happened, just like it did with Android and ChromeOS. When technical limitations exist, they can be sorted out when everyone rows into the same direction. So after its failure, and reboot as Vista, the Windows team took many of the Longhorn ideas and redid them as COM libraries. This decision started a trend (hence my started with Vista), where all major new APIs that were added to Windows since then, were COM based instead of classical Win32. You can see this by following the C++ Hilo tutorial later released for Windows 7. When Windows 8 came to be, they decided to double down on this direction and came up with WinRT, which if you read the Ext-VOS paper, looks quite similar. Ext-VOS being what was being designed as successor to VB/C++/J++ as COM evolution, before all the events that made .NET happen. So you got the Windows team creating WinRT, they also had their own shot at what .NET should be, hence why it uses AOT based compilation with a compiler that only supports the MSIL sets that they cared about. As we all know by now, due to several reasons this did not turn out as expected, still UWP (as COM evolution is now know) is still the way to go to all major APIs, even in the context of Project Reunion. So we changed from Win32 + some relevant projects using COM, to Win32 mostly frozen in Windows XP API level + everything else is COM/UWP based. This was my point about Vista being the turning point where this took place. I might be wrong, but this is how I see the evolution of those events.

by tmzt 6y ago

deleted 6y ago

[deleted]

pjmlp 6y ago

Maybe I should have phrased it in another way. For you to get where I am coming from, for me Longhorn only failed due to the usual set of politics between DevDiv and WinDev that those of us on Windows know so well throughout the years. Had they actually worked together and Longhorn, with .NET based stack would have happened, just like it did with Android and ChromeOS. When technical limitations exist, they can be sorted out when everyone rows into the same direction. So after its failure, and reboot as Vista, the Windows team took many of the Longhorn ideas and redid them as COM libraries. This decision started a trend (hence my started with Vista), where all major new APIs that were added to Windows since then, were COM based instead of classical Win32. You can see this by following the C++ Hilo tutorial later released for Windows 7. When Windows 8 came to be, they decided to double down on this direction and came up with WinRT, which if you read the Ext-VOS paper, looks quite similar. Ext-VOS being what was being designed as successor to VB/C++/J++ as COM evolution, before all the events that made .NET happen. So you got the Windows team creating WinRT, they also had their own shot at what .NET should be, hence why it uses AOT based compilation with a compiler that only supports the MSIL sets that they cared about. As we all know by now, due to several reasons this did not turn out as expected, still UWP (as COM evolution is now know) is still the way to go to all major APIs, even in the context of Project Reunion. So we changed from Win32 + some relevant projects using COM, to Win32 mostly frozen in Windows XP API level + everything else is COM/UWP based. This was my point about Vista being the turning point where this took place. I might be wrong, but this is how I see the evolution of those events.