4 ms·

No, not a shitty client, just one that was written before you decided to make this change. If your API breaks it while it doesn't change, it's the API that's be

No, not a shitty client, just one that was written before you decided to make this change. If your API breaks it while it doesn't change, it's the API that's being shitty, not the client.

codexb 3y ago
It depends. Did the API document that it could raise an exception if printing isn't supported? Is that unhandled in the client? Then yes, it's a shitty client. If you're talking about making backwards-incompatible breaking changes to an API, that's another thing.
- derefr 3y ago
  In the context of the article, no, the existing API never threw (or was documented as capable of throwing) NotSupportedException. The article: > The app that the user installed on the Xbox was probably tested primarily, if not exclusively, on a PC, where printing is always available. I.e. there is no concept in the (desktop) Windows printing subsystem of printing as a feature not being available; on desktop Windows, printing as a feature is available by definition.
  - TillE 3y ago
    The mention of NotSupportedException is a little confusing because that's a .NET thing, and the rest of the article is talking about Win32, which is a plain old C API where exceptions don't exist. I guess he's implicitly talking about a C# API built on top of Win32. It's entirely correct to return error codes, and any client is expected to handle that.
    - derefr 3y ago
      Clients are not expected/required, however, to behave correctly in the face of unknown error codes that did not exist or have defined semantics at SDK-version-selection time. Actual exceptions — in languages that have them — are a bit different, in that they “do” something by default: they propagate and unwind unless they’re caught. And so, new (unchecked, if in a language where that’s relevant) exceptions can be introduced after the fact under the presumption that the runtime’s default behavior for propagating unknown exceptions will kick in, and that this will trigger the desired result for applications that weren’t written in awareness of that particular exception. Error codes aren’t like that; they have no default semantics as a class, only explicit default semantics per function and/or per algebraic error-code type, if-and-where documented as such. New error codes simply aren’t meant to be introduced in most APIs, unless those APIs have rules about e.g. generalized default handling for defined code ranges that new codes can be later slotted into. Basically, error codes are weak enums. If you’re writing a dynamic-link library (or a runtime — same thing, basically), you’re not supposed to add new potential values to an enum used as a return value: client code will likely have been written to switch on the value with the known options as cases, and your new value won’t be in there.
    - felsokning 3y ago
      > I guess he's implicitly talking about a C# API built on top of Win32. Correct. The error `ERROR_CANCELLED` is defined in WinErr.h and it's translated via `HRESULT_FROM_WIN32` in the same[1]. It was this change pointed out in `CreateWidget` to get around returning the null pointer that he was suggesting would be better to make the API inert. [1] - https://learn.microsoft.com/en-us/windows/win32/api/winerror/nf-winerror-hresult_from_win32 https://learn.microsoft.com/en-us/windows/win32/api/winerror...
  - ryandrake 3y ago
    I think this is the critical piece that should determine how you handle the error. If the API, as used by the client, when the client was programmed, was expected to potentially throw NotSupportedException or return an error code, then doing so sounds like the right way to go. Throwing/erroring is part of the API contract and the client should handle NotSupportedException. If the API was never expected to throw NotSupportedException or return an error code, then all of a sudden starting to throw in a future release breaks the API contract, and the client cannot be expected to handle it sensibly. EDIT: Duh! My comment is useless. This was the exact conclusion that the article came to, too. So instead of reading this comment chain, just finish the article :)
Aaargh20318 3y ago
> No, not a shitty client, just one that was written before you decided to make this change. Has the Xbox ever supported printing? Why even have these APIs? Just don’t offer them at all in the Xbox SDK. You shouldn’t be able to compile code that tries to call these when targeting Xbox.
- skykooler 3y ago
  It's an API that also targets Windows. Apps that use it can run on both platforms.
- delta_p_delta_x 3y ago
  ? Why even have these APIs? Xbox essentially runs Windows. Therefore, the Windows API is available on Xbox.
  - Aaargh20318 3y ago
    But they are essentially removing parts of the Windows API, that’s what the entire article is about. Wouldn’t it make more sense AND be a lot less work to simply remove these APIs from the header files than to provide a stub implementation?
    - plorkyeran 3y ago
      There are no header files involved. The whole point of this is to support running existing programs without recompiling them for the new platform.
      - Aaargh20318 3y ago
        What existing apps could you possibly want to run on a game console without at least a few modifications to make it suitable to run with the completely different control scheme and user expectations of a console. It seems like an enormous amount of effort for an extreme edge case. It’s this weird obsession Microsoft has with the flawed idea that you should be able to run anything on every device without modifications. It’s their unwillingness to acknowledge that different types of devices require different user experiences.

No, not a shitty client, just one that was written before you decided to make this change. If your API breaks it while it doesn't change, it's the API that's being shitty, not the client.

codexb 3y ago

It depends. Did the API document that it could raise an exception if printing isn't supported? Is that unhandled in the client? Then yes, it's a shitty client. If you're talking about making backwards-incompatible breaking changes to an API, that's another thing.

derefr 3y ago
In the context of the article, no, the existing API never threw (or was documented as capable of throwing) NotSupportedException. The article: > The app that the user installed on the Xbox was probably tested primarily, if not exclusively, on a PC, where printing is always available. I.e. there is no concept in the (desktop) Windows printing subsystem of printing as a feature not being available; on desktop Windows, printing as a feature is available by definition.
- TillE 3y ago
  The mention of NotSupportedException is a little confusing because that's a .NET thing, and the rest of the article is talking about Win32, which is a plain old C API where exceptions don't exist. I guess he's implicitly talking about a C# API built on top of Win32. It's entirely correct to return error codes, and any client is expected to handle that.
  - derefr 3y ago
    Clients are not expected/required, however, to behave correctly in the face of unknown error codes that did not exist or have defined semantics at SDK-version-selection time. Actual exceptions — in languages that have them — are a bit different, in that they “do” something by default: they propagate and unwind unless they’re caught. And so, new (unchecked, if in a language where that’s relevant) exceptions can be introduced after the fact under the presumption that the runtime’s default behavior for propagating unknown exceptions will kick in, and that this will trigger the desired result for applications that weren’t written in awareness of that particular exception. Error codes aren’t like that; they have no default semantics as a class, only explicit default semantics per function and/or per algebraic error-code type, if-and-where documented as such. New error codes simply aren’t meant to be introduced in most APIs, unless those APIs have rules about e.g. generalized default handling for defined code ranges that new codes can be later slotted into. Basically, error codes are weak enums. If you’re writing a dynamic-link library (or a runtime — same thing, basically), you’re not supposed to add new potential values to an enum used as a return value: client code will likely have been written to switch on the value with the known options as cases, and your new value won’t be in there.
  - felsokning 3y ago
    > I guess he's implicitly talking about a C# API built on top of Win32. Correct. The error `ERROR_CANCELLED` is defined in WinErr.h and it's translated via `HRESULT_FROM_WIN32` in the same[1]. It was this change pointed out in `CreateWidget` to get around returning the null pointer that he was suggesting would be better to make the API inert. [1] - https://learn.microsoft.com/en-us/windows/win32/api/winerror/nf-winerror-hresult_from_win32 https://learn.microsoft.com/en-us/windows/win32/api/winerror...
- ryandrake 3y ago
  I think this is the critical piece that should determine how you handle the error. If the API, as used by the client, when the client was programmed, was expected to potentially throw NotSupportedException or return an error code, then doing so sounds like the right way to go. Throwing/erroring is part of the API contract and the client should handle NotSupportedException. If the API was never expected to throw NotSupportedException or return an error code, then all of a sudden starting to throw in a future release breaks the API contract, and the client cannot be expected to handle it sensibly. EDIT: Duh! My comment is useless. This was the exact conclusion that the article came to, too. So instead of reading this comment chain, just finish the article :)

Aaargh20318 3y ago

> No, not a shitty client, just one that was written before you decided to make this change. Has the Xbox ever supported printing? Why even have these APIs? Just don’t offer them at all in the Xbox SDK. You shouldn’t be able to compile code that tries to call these when targeting Xbox.

skykooler 3y ago
It's an API that also targets Windows. Apps that use it can run on both platforms.
delta_p_delta_x 3y ago
? Why even have these APIs? Xbox essentially runs Windows. Therefore, the Windows API is available on Xbox.
- Aaargh20318 3y ago
  But they are essentially removing parts of the Windows API, that’s what the entire article is about. Wouldn’t it make more sense AND be a lot less work to simply remove these APIs from the header files than to provide a stub implementation?
  - plorkyeran 3y ago
    There are no header files involved. The whole point of this is to support running existing programs without recompiling them for the new platform.
    - Aaargh20318 3y ago
      What existing apps could you possibly want to run on a game console without at least a few modifications to make it suitable to run with the completely different control scheme and user expectations of a console. It seems like an enormous amount of effort for an extreme edge case. It’s this weird obsession Microsoft has with the flawed idea that you should be able to run anything on every device without modifications. It’s their unwillingness to acknowledge that different types of devices require different user experiences.