4 ms·

There's kind of a tension between new Microsoft and old Microsoft. Old Microsoft put lots of thought into extensibility of APIs and makes it so that the old in

There's kind of a tension between new Microsoft and old Microsoft. Old Microsoft put lots of thought into extensibility of APIs and makes it so that the old interfaces still work when they introduce new functionality. New Microsoft rewrites components from scratch and deprecates the old one every few years, and doesn't bother to shim over the old interface. The former group has it such that if your app was well written circa 1997-2001, it works well on the current release. The latter group has it so that you have several different copies of .NET on your hard drive and the "recommended" UI libraries for new applications has changed a lot, and the new hotness from a few years ago is deprecated.

JohnFen 4y ago
> New Microsoft rewrites components from scratch and deprecates the old one every few years, and doesn't bother to shim over the old interface. This seems to be a trend across the industry, not just Microsoft. And it's a real shame. It makes it too risky to use a lot of shiny new things in real projects.
- asveikau 4y ago
  I agree it's an industry wide thing. The Microsoft-specific variant of it is something I've seen up close. One of the issues always struck me as confusing interface and implementation. There isn't a good recognition of the fact that when you write against an API, you code against an abstraction, not a particular implementation. If your interface is good enough, you can do the rewrite treadmill thing to justify your current bonus or whatever, but you can point the old interface at a new implementation without most callers knowing the difference. So, I think a good example of this working relatively well would be Windows audio. The WinMM API still works. They rewrote the audio stack a couple of times, and introduced new APIs such as WASAPI and I forget the newer one. Winmm isn't broken. It may not have access to all the latest features, but it works. In contrast, all too often they discard an entire API because they want to rewrite the components underneath. But the I in API stands for interface. A good interface can survive rewrites of what's underneath.
  - JohnFen 4y ago
    > But the I in API stands for interface. A good interface can survive rewrites of what's underneath. Absolutely! But a good interface is also a really difficult thing to engineer, in part because it seems like a relatively easy thing. The gotchas don't become apparent until long after you ship. Sometimes I wonder if some of this is just cost-cutting. A difficult task is an expensive task. Other times, I wonder if it's because API design is an actual specialty, and there are too many devs doing it who don't have the chops for it.
  - jstimpfle 4y ago
    An interface is how you connect your own code to the other code. There is a large interface design space spanning from extremely minimal and simple, to extremely detailed, flexible, giving control over performance etc. Interfaces that are very simple tend to allow a broad range of implementations but may fail to make accessible all the capabilities of the implementation. On the other hand, interfaces that provide good control over runtime characteristics etc. tend to already give away the implementation. If "API" were primarily about abstraction, it would be called APA.
    - asveikau 4y ago
      I disagree with most of this, but everyone is entitled to their opinion. One point I'll offer is that ability to shim an old interface onto a new implementation validates the design of the new thing. If you can't shim them, chances are there's some necessary problem you aren't solving, and possibly aren't aware of. Concrete details of all these things will alter the discussion. I think my example of audio is a good one for the strength of "the old way". The old interface works, even though it does vastly different things than it did in 1995. Like you say, maybe there are some features you can't get with the old interface -- that can be OK. But they didn't break it. The Win32 subsystem on NT-based Windows began as such a shim too. The NT native APIs sometimes look very very different. Most people don't know this. eg. Most people don't know that renaming things isn't its own syscall that operates on a source filename a la unix rename(2), which is what Win9x did -- that there's transparently an NtCreateFile() call that happens inside MoveFile() ... Philosophically, the NT API "hates" doing things based on filenames, most operations that Unix or Winapi have as filenames operate on handles... But nobody needs to know, the Win9x API is the public API.
pjmlp 4y ago
Also add the WinRT folks into the New Microsoft. Deprecated C++/CX and .NET Native, while neither Native AOT nor C++/WinRT are proper replacements in capabilities, replaced UWP/WinUI 2.0 with WinAppSDK/WinUI 3.0 with lots of missing capabilities.

JohnFen 4y ago

> New Microsoft rewrites components from scratch and deprecates the old one every few years, and doesn't bother to shim over the old interface. This seems to be a trend across the industry, not just Microsoft. And it's a real shame. It makes it too risky to use a lot of shiny new things in real projects.

asveikau 4y ago
I agree it's an industry wide thing. The Microsoft-specific variant of it is something I've seen up close. One of the issues always struck me as confusing interface and implementation. There isn't a good recognition of the fact that when you write against an API, you code against an abstraction, not a particular implementation. If your interface is good enough, you can do the rewrite treadmill thing to justify your current bonus or whatever, but you can point the old interface at a new implementation without most callers knowing the difference. So, I think a good example of this working relatively well would be Windows audio. The WinMM API still works. They rewrote the audio stack a couple of times, and introduced new APIs such as WASAPI and I forget the newer one. Winmm isn't broken. It may not have access to all the latest features, but it works. In contrast, all too often they discard an entire API because they want to rewrite the components underneath. But the I in API stands for interface. A good interface can survive rewrites of what's underneath.
- JohnFen 4y ago
  > But the I in API stands for interface. A good interface can survive rewrites of what's underneath. Absolutely! But a good interface is also a really difficult thing to engineer, in part because it seems like a relatively easy thing. The gotchas don't become apparent until long after you ship. Sometimes I wonder if some of this is just cost-cutting. A difficult task is an expensive task. Other times, I wonder if it's because API design is an actual specialty, and there are too many devs doing it who don't have the chops for it.
- jstimpfle 4y ago
  An interface is how you connect your own code to the other code. There is a large interface design space spanning from extremely minimal and simple, to extremely detailed, flexible, giving control over performance etc. Interfaces that are very simple tend to allow a broad range of implementations but may fail to make accessible all the capabilities of the implementation. On the other hand, interfaces that provide good control over runtime characteristics etc. tend to already give away the implementation. If "API" were primarily about abstraction, it would be called APA.
  - asveikau 4y ago
    I disagree with most of this, but everyone is entitled to their opinion. One point I'll offer is that ability to shim an old interface onto a new implementation validates the design of the new thing. If you can't shim them, chances are there's some necessary problem you aren't solving, and possibly aren't aware of. Concrete details of all these things will alter the discussion. I think my example of audio is a good one for the strength of "the old way". The old interface works, even though it does vastly different things than it did in 1995. Like you say, maybe there are some features you can't get with the old interface -- that can be OK. But they didn't break it. The Win32 subsystem on NT-based Windows began as such a shim too. The NT native APIs sometimes look very very different. Most people don't know this. eg. Most people don't know that renaming things isn't its own syscall that operates on a source filename a la unix rename(2), which is what Win9x did -- that there's transparently an NtCreateFile() call that happens inside MoveFile() ... Philosophically, the NT API "hates" doing things based on filenames, most operations that Unix or Winapi have as filenames operate on handles... But nobody needs to know, the Win9x API is the public API.

pjmlp 4y ago

Also add the WinRT folks into the New Microsoft. Deprecated C++/CX and .NET Native, while neither Native AOT nor C++/WinRT are proper replacements in capabilities, replaced UWP/WinUI 2.0 with WinAppSDK/WinUI 3.0 with lots of missing capabilities.