these aren't the only two options.

first of all, i certainly wouldn't be more frustrated if the app just crashed, but how about just letting the user know that the xbox can't print? why does everybody seem to think that's out of the question?

> but how about just letting the user know that the xbox can't print? why does everybody seem to think that's out of the question?

Because the situation described is about an application that was made for PC (which supports printing) and a user is trying to run it on an Xbox (which doesn't support printing) with the developer never even imagining someone will try to run the program on an Xbox in the first place. You can't implement a message about an error you don't even know will happen.

The Xbox system APIs can certainly notify the user directly. It's not like they don't have the ability to pop up system UIs.

The Xbox can (and probably can do that while simulating the "user pressed cancel" dialog API for adding printers) but my understanding for what yungporko wrote was that the program would be the thing that lets the user know the xbox can't print.

The original article is about how the Xbox implementation of the Windows printing subsystem should behave, from one of its designers. They considered making it throw an Exception, but decided to instead behave as if printing is supported but there are no printers, so that Windows apps would not crash.

My point was that, as an end user of such apps on Xbox, my preference would have been to have the Xbox OS tell me directly that printing is not supported on this system, even if the app doesn't know about this.

I do not have an Xbox to try but i do not see how these two are mutually exclusive. If you try to use an app to print you wont be able to do that because there are no printers. If you try to add a printer using the Windows API for adding printers (which AFAICT from the article is done via a GUI that Windows itself provides) then the Xbox OS could show an error message that Xbox does not have printer support and once you close it, have the API call the application made tell the application that the user cancelled the request (which is something, according to article, it already does - though i don't have an Xbox to tell if it displays an error message or silently returns the cancel code).

Xbox cannot tell you that there is no printer support before you try to do something related to printing because it doesn't know you may want that. An application that was made for Windows also can't do that because on Windows you can add printers (even fake ones that print to PDFs, no hardware needed).

An application asks the OS for the list of printers. The question is what should an OS with no support for printing do. The article says it should return an empty list. My point is that it should pop up a notification directly to the user telling them "hey, the app you're using is trying to access printing, but that's not supported on this machine" or some other language like this (it could then return an empty list).

Trying to enumerate printers doesn't imply that the application will use them, it could easily be part of the initialization of some framework, shared library, language runtime, or whatever. Unless there is some actual user interaction, there is no way for the OS to know what the user is trying to do. It is best to err on the side of not making assumptions.

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, and then whatever other solution is OK.

> 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.