8 ms·
I stopped reading at "The Windows Runtime is based on Component Object Model (COM) APIs..." Is that a bad choice on my part? I see COM and think of OLE, CORBA
by xrd 7y ago
I stopped reading at "The Windows Runtime is based on Component Object Model (COM) APIs..."
Is that a bad choice on my part?
I see COM and think of OLE, CORBA and I remember that I'm old and going to die pretty soon (within the next 40-50 years almost assuredly).
https://en.wikipedia.org/wiki/Component_Object_Model https://en.wikipedia.org/wiki/Component_Object_Model
- sleepinseattle 7y agoIt’s not that different from things like Protocol Buffers, and for application code it’s mostly a hidden implementation detail. The API you’re calling (like the Composition API’s in the Minesweeper example) might be calling into a separate process but you don’t have to care. Disclosure: I work on the Windows team
- blinkingled 7y agoTrouble is you can't really the solve the problem Microsoft had without using something like COM. Good news is you don't have to care - you can use C# or Rust and not worry about COM.
- pjmlp 7y agoSomehow I think .NET would have been much better had it started as something like .NET Native, but yeah cannot turn back in time.
- barrkel 7y agoIt would have been no good for web application servers, which is where the competition was going. Native would have chased the declining native GUI market.
- pjmlp 7y agoSure it would, after all that is where backend development is going to, back to AOT compilation toolchains. If Delphi never managed much on the server side, it has more to do with the downfall from Borland than anything else. So ASP + COM would be ASP.NET with COM+ Runtime instead.
- barrkel 7y agoI just don't buy it. Delphi could have done better, but not good enough. I think on its best day it would have had a hard time time competing with Java, much less Python or Ruby, and Rails was on the up as Delphi's .NET strategy was on the wane. It needed to be an open source cross-platform compiler to be truly viable in the Linux ecosystem, and Linux would be needed to compete with Windows and its licensing fees. Anything other than C# is always a step or two behind on .NET, and .NET was the best route to web apps on Windows. The only reason AOT is coming back for web apps is FaaS, IMO. FaaS works best with minimal boot-up latency, and FaaS delivers operationally as a way to scale out stateless compute on demand, which optimally means acquiring those compute resources just for the duration of a request or job, and no longer.
- oaiey 7y agoWindows UI and Framework beyond Win32 is solidly based on COM. Win 10 works for many years now with a deployment close to a billion. I would say: works.
- alxmdev 7y ago"Under the hood" makes it sound like you wouldn't deal with any COM stuff yourself, it's just how the different languages' APIs were implemented to interface with the OS runtime.
- hota_mazi 7y agoCOM is a fantastic invention and implementation. Granted, it was pretty painful in C and somewhat in C++, but all the other languages (VB and C# mostly, but plenty of others) really unlock the power of COM. Nothing like that remotely exists on Linux or macOS.
- recursive 7y agoMy only experience with COM (that I know of) was trying to do MS Office automation from C# >10 years ago. I recall that it was very awkward, and somehow prone to memory leaks, and unclosed resources. To this day, I still don't really understand what COM is, or is supposed to be. But I still have a negative visceral reaction.
- Ididntdothis 7y agothere is a big difference between out of process COM (like Office Automation) and in process COM (like WinRT and UWP or DirectX). Out of process was always a little tricky and not implemented well. DCOM was even worse. In process COM works really well. Edit: I should add that C# isn’t the best language for COM because it doesn’t release objects when they go out of scope so you either have to release everything manually or wait for the GC to kick in which can cause memory problems. VB and C++ and even PHP are better that way.
- jfkebwjsbx 7y agoWhat is the point of "In process COM"? Is the same as any other library? I thought COM was meant to communicate between processes? Any enlightenment is appreciated...
- jdub 7y agoIt lets you use libraries written in numerous supported languages with a richer, more object oriented interface than a C ABI. You can use the same underlying interface to call out of process or distributed objects.
- 7y ago
- pjmlp 7y agoYes it is. After the whole political disaster that was Longhorn, the Windows team decided to rebuilt Longhorn ideas, originally based on .NET, and redo them with COM. So while many outside Windows have considered COM dead, actually since Vista all major Windows APIs have been provided as COM interfaces, the large majority of Win32 surface has been frozen since Windows XP. With WinRT/UA/UAP/UWP they have gone back to the roots, while pursuing this idea one level up. Basically they replaced COM type libraries with .NET Metadata, added support for generics, structured data types and implementation inheritance, bringing it to what .NET would have been like if they did not decided to copy Java. So while the implementation of this reboot has been somewhat clusmy, COM is not going anywhere on Windows. Also, this isn't a Windows only thing, Linux has gathered around DCOP, Android has AIDL, Fuchsia FIDL, macOS/iOS has XPC, then there is gRPC and plenty of other variants.
- codys 7y agoFor linux I believe you mean D-Bus instead of DCOP. (that said, it's largely similar in concept)
- pjmlp 7y agoYou are right, that was the old protocol.
- KeBugCheckEx 7y agoHistorical note: first versions of .NET were called "COM+ 3.0".
- amaranth 7y agoI think the most similar thing to WinRT on Linux would be GObject Introspection since the main point appears to be a way to somewhat automatically surface the platform API in multiple languages using language-specific idioms. D-Bus is instead for RPC and events, which I guess COM also gets used for?
- pjmlp 7y agoI guess you are kind of right, then it would be a mix of GObject, KParts and D-BUS then. As for COM, yes there are multiple models, in-process, external process and across the network (with DCOM). GObject and KParts would be the in-process variant, with D-BUS for the other execution models.
- Koshkin 7y agoThat's what they called "going native" (vs. using .NET).
- discreteevent 7y agoI don't think the basic architecture is going to go away. Even some of the newest operating systems have something quite similar: https://fuchsia.googlesource.com/docs/+/ea2fce2874556205204d3ef70c60e25074dc7ffd/development/languages/fidl/tutorial.md https://fuchsia.googlesource.com/docs/+/ea2fce2874556205204d...