> To me, a better solution would be for the system to pop up a notification informing the user that printing is not supported on this platform

That's the whole point of this article - when you can't control the various platforms that your application is run on, you want to try to do the "least bad" thing, even if that platform didn't anticipate the situation of, in this case, telling people that printing isn't supported.

The article is the other way around -- it's written from the perspective of a platform developer trying to deal with apps that didn't anticipate the situation.

Thanks for the clarification, you're correct. The nuance/complexity is that the platform developer must conform to a platform spec (in this case, the Windows API) that usually makes some underlying assumptions about the capabilities of the system that runs it, which may not always be correct.

Yes, I'd add to that by pointing out that the "spec" is a de facto spec subject to Hyrum's Law, that is, people have built their apps against other implementations of the platform and inevitably don't handle any behavior not seen on those other implementations.

I waffle whether I agree with you. On the one hand, it makes sense to tell the user that clicking that juicy print button isn't going to work. On the other, it's a popup they'll have to dismiss telling them some recoverable error they cannot do anything to fix.

Yes exactly, but Microsoft isnt the one who can implement that.

This was about the Xbox printing subsystem, right? Of course they can implement that.

It would be whoever writes the software (ie the game) for the xbox.

The Xbox OS can very well pop up a system notification directly to the user if an unsupported API is being accessed. This is not Unix where you have to assume no UI may even exist - the Xbox OS knows full well how to draw its own dialog on the screen.