15 ms·

If you're just going to sit there doing nothing, at least do nothing correctly

432 points by AndrewDucker 3y ago

tsimionescu 3y ago
I find nothing quite as frustrating as UIs that suggest a device could exist, but it's not there right now. I then have to spend time to discover that these devices are not supported, and that screen was just some mock someone came up with.
- kentonv 3y ago
  Sure, but you'd be more frustrated if your app just crashed. If the app is not prepared for printing not being supported, and printing just throws an exception, the app probably just crashes. That's bad. If the app is prepared for printing not being supported, it should be calling the explicit API to check if printing is supported, and then not displaying the UI for printing if it isn't. The article is not about these apps, it's about what to do about apps that fail to check first. The bug is with the app, but a good platform does its best to make bad apps work anyway, rather than have them just crash.
  - tsimionescu 3y ago
    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.
    - hn_throwaway_99 3y ago
      > 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.
      - kentonv 3y ago
        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.
        hn_throwaway_99 3y ago
        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.
        kentonv 3y ago
        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.
    - nonethewiser 3y ago
      Yes exactly, but Microsoft isnt the one who can implement that.
      - tsimionescu 3y ago
        This was about the Xbox printing subsystem, right? Of course they can implement that.
        nonethewiser 3y ago
        It would be whoever writes the software (ie the game) for the xbox.
        tsimionescu 3y ago
        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.
    - BeFlatXIII 3y ago
      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.
  - nerdponx 3y ago
    > Sure, but you'd be more frustrated if your app just crashed. I don't know about that. If it crashes, I might not try that thing again.
  - yungporko 3y ago
    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?
    - badsectoracula 3y ago
      > 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.
      - tsimionescu 3y ago
        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.
        badsectoracula 3y ago
        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.
        tsimionescu 3y ago
        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.
- nonethewiser 3y ago
  Perhaps the software author is to blame here then not Microsoft. Because they didnt handle the printer case. Where Microsoft comes in is that the software doesnt crash because the software provider didnt account for printers.
Analemma_ 3y ago
I understand the logic here, and I'm aware Microsoft has a large number of convoluted backward-compatibility requirements, but this seems like drinking to solve your problems and just putting off the inevitable hangover. To be clear: what you're doing here is lying to the user and the developer. Maybe that's justified in isolation, but now this lie is one more bit of "hidden state" you have to keep track of in further development and integration testing. And just like in the real world, lies have a tendency to compound on themselves until you're completely lost in them and have no idea what reality is. I have a feeling that "solutions" like this are part of why an increasing number of my computing problems take the form of, "I tried to take an action, nothing happened. No error, no activity, nothing.", and are impossible to debug or diagnose. UX designers made themselves terrified of ever showing an error code to a user, but they took that and replaced it with a world where your shit just doesn't work, and when you try to figure out why, all the OS does is shrug.
- ace2358 3y ago
  This resonates with me. My computers used to crash at the app level, OS level or hardware level. Now when something goes wrong the system just kinda gets lazy and stops working. But it won’t crash. I’ve had my mac pinwheel on the login screen. I can still access the shell and file shares remotely, and even screen share to a logged in user. But login.app refuses to crash so it’ll just pinwheel. I’m glad I never forgot to turn things off and on for troubleshooting :(
  - Analemma_ 3y ago
    I have a suspicion that "number of crashes" got badly Goodharted inside major OS vendors. After all, you can "prevent" most crashes by just having a top-level "catch(Exception e) {}" handler, which of course just leads to the program doing nothing instead in an un-debuggable way, but hey: crashes went down! KPI achieved!
  - bombcar 3y ago
    My experience is that macOS especially really REALLY absolutely hates when the Internet goes sideways - not actually down, but really bad packet loss; DNS starts being slow and failing sometimes but not completely ... then you enter hell. Next time it happens try turning network connections all the way off.
Jabrov 3y ago
"The idea here is to have the printing functions all behave in a manner perfectly consistent with printing being fully supported, yet mysteriously there is never a printer to print to." This must be satire. Otherwise I can't comprehend how something as infuriating as this could be presented as a good or smart thing to do UX-wise
- recursive 3y ago
  The alternative is that the app fails to run at all. Doesn't seem like satire to me.
  - GMoromisato 3y ago
    Or worse, crashes at a random spot because it tried to initialize the printer stack.
    - bombcar 3y ago
      Anyone who has spent some time with vintage or otherwise older software (and even some new stuff) should have experienced a "don't do this, it explodes" - often the cause is something akin to what Raymond is pointing out. The software asks for something, gets back an answer it can't handle, explodes.
- avery17 3y ago
  What do you suggest as an alternative?
- kentonv 3y ago
  No, this is a guy who has been one of the architects of Windows for more than 30 years giving you hints about how they achieved their reputation for amazing backwards compatibility. He really, really knows what he's talking about.
- daveoc64 3y ago
  If the two options are "this app can't run on your Xbox" or "this app runs on your Xbox, but the printing functions don't work and some of the messages are a little weird", which option do you think users would prefer?
lucianbr 3y ago
Once upon a time it was considered a great strategy for browsers to make the best effort to display a page, even if the html code had errors. Just try to guess the author's intention as well as you can, and go ahead. Errors are bad. Users don't want errors. I thought we learned from that experience. Apparently not.
- debacle 3y ago
  "We" did. Microsoft didn't. Not unexpected.
  - recursive 3y ago
    Is this part of a fan fiction where MS isn't amazing at legacy compatibility?
    - Peter0x44 3y ago
      I think their BC is overrated. Wine manages to do a better job.
- subarctic 3y ago
  What did you think we learned?
  - lucianbr 3y ago
    That every single behavior that attempts to guess the users's intent becomes a relied upon part of the software, and this over time grows to an impossible amount of cruft. See this, hilariously hosted also by microsoft: https://techcommunity.microsoft.com/t5/discussions/funny-story-of-browser-wars-from-the-beginning-of-the-time-user/m-p/1079832 https://techcommunity.microsoft.com/t5/discussions/funny-sto... > And then Google built Chrome, and Chrome used Webkit, and it was like Safari, and wanted pages built for Safari, and so pretended to be Safari. And thus Chrome used WebKit, and pretended to be Safari, and WebKit pretended to be KHTML, and KHTML pretended to be Gecko, and all browsers pretended to be Mozilla, and Chrome called itself Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13, and the user agent string was a complete mess, and near useless, and everyone pretended to be everyone else, and confusion abounded.
throwawayfrsbob 3y ago
And they ask why we're cynical. I'm about done with this whole "personal computing" fad.
fidrelity 3y ago
Your ecosystem has gone so complex that you can't test it anymore. So instead of handling errors properly you suggest to implement a convoluted user flow that offers always failing actions (install a printer when there's none available). If that's really the suggestion of product and engineering leadership at MSFT no wonder all their products...err...work as designed.
- gruez 3y ago
  >Your ecosystem has gone so complex that you can't test it anymore. An operating system with billion+ install base, and millions of developers tends to be complex. I'm not sure what you're proposing here, have your platform/software be more niche? Somehow get all of them to fall in line? >So instead of handling errors properly you suggest to implement a convoluted user flow that offers always failing actions (install a printer when there's none available). How are you going to "handle errors properly" if the publisher of the software in question went out of business?
- Arainach 3y ago
  What is "your ecosystem" here? Part of running a platform is that the code running on it is written by other people, not you, and that your customers will be relying on that code. When the software your customers are relying on breaks because of a change you made, it doesn't matter whose "fault" it is. It's broken, it broke because of something you did, and you have burned customer trust - not the trust of whoever wrote the software you believe is "wrong" or "to blame", trust of your platform and company.
  - xp84 3y ago
    It is so obvious from reading these comments here who is not, and would never ever want to be, a platform engineer. It’s hard for some people to grasp that you need to not only interact with, but thoroughly accommodate, software written by others whom you don’t control (often due to the one-way direction of time flow).
- nearbuy 3y ago
  Not at all what he is saying. Microsoft has no problem testing their printer function across all platforms in their apps and removing the print button on platforms where it's not supported. Ideally, everyone would do this. This is for other developers who are writing 3rd party apps for Microsoft's platforms and who don't always test perfectly. They may have written their app primarily for Windows and didn't consider what happens when someone installs it on their Xbox and clicks "print". In that case, the API should "just work", instead of crashing with an error message.
paxys 3y ago
People are reacting negatively as expected, but stuff like this is exactly why you can click on a file that was written in Word '97 or a game that was compiled for MS-DOS three decades ago and it opens on your computer exactly as expected. Backwards compatibility is always messy. You either do it imperfectly or don't do it at all.
- blibble 3y ago
  MS-DOS software doesn't work on modern 64-bit windows you get a dialog saying "unsupported" now you can download dosbox but that isn't really "exactly as expected"
- dupertrooper 3y ago
  Umm but you can’t find a current version of Word that actually does that. Try it sometime.
  - EvanAnderson 3y ago
    Here's a rather large (5MB) vintage 1996 Microsoft Word document: https://archive.org/download/cd-pn-0527a/CD_ROM.ISO/APPENDIX%2FDNS.DOC https://archive.org/download/cd-pn-0527a/CD_ROM.ISO/APPENDIX... That file opens and appears to render just fine for me in Word 2016. This has been my experience w/ Office files in general. Old files open and render very well in newer versions.
    - weinzierl 3y ago
      The point made above was "opens exactly as expected". So, does it look like the authors intended in 1996? I doubt it.
      - Arainach 3y ago
        If you "doubt" it, please provide a specific example of what you believe is inaccurate in the document rendering.
hailmac 3y ago
Why /wouldn't/ I want to print something from my Xbox?
- daveoc64 3y ago
  Due to the input device most people will use (controller), apps that work best on Xbox are those used to consume content like photos or videos. You might be viewing something and want to print it, but that's clearly not desirable enough for Microsoft to build print functionality into the Xbox UI.
  - maerF0x0 3y ago
    I mean, it has USB ports. If I can plug it in, I'd like to be able to use it _somehow_ , even if that means installing another app that does direct port/device access or w/e . ie, it should be possible (but not necessarily super easy)
    - Arainach 3y ago
      The explicit point of video game consoles is to be a locked down experience, not a PC. Hardware access is generally used for piracy, which game developers do not like.
- Arainach 3y ago
  The printer drivers don't run on XBox. XBox isn't exposing all of the legacy Win32 APIs and driver models available in desktop.
  - mrguyorama 3y ago
    It's an x64 CPU running most of Windows with plentiful and fully supported USB ports. Why CAN'T I print from my Xbox? I can print with my phone, so why not my Xbox? I'm sure there's something about "windows print subsystems are pretty terrible and we should excise them from anything we can" and "reduce code to reduce bugs" but like.... There's no technical reason it can't
ofslidingfeet 3y ago
This mindset is even less ethical than it seems, and I'm not surprised to see it present at microsoft.
- Arainach 3y ago
  What do you mean by "ethical" here, and why is it unethical to preserve ABI compatability?
  - chrisjj 3y ago
    > why is it unethical to preserve ABI compatability? Straw man. What's unethical here is deceiving the user.
    - Arainach 3y ago
      There is no deception. There are no printers, and that's what the API returns.
      - chrisjj 3y ago
        The deception is concealment of the fact printing is unsupported. Nk printers is merely a cover story. "NotSupportedException" is there for a reason.
        Arainach 3y ago
        Nothing is being concealed. If you want to know if printing is supported, call IsPrintingSupported. The information is there, the API is there.
        chrisjj 3y ago
        The one deceived is the user. He does not have the option of calling an additional function.
  - 3y ago
happytoexplain 3y ago
The specific thing the author is suggesting is correct (components should suffer before users do), but I take great offense to their framing. "There may be times where you need to make an API do nothing." "The wrong thing to do is to have the printing functions throw a NotSupportedException." No, no, absolutely no - what the author is describing is a hack to support a shitty client. Yes, you have to do this sometimes. No, it is not normal or generalizable advice. The way they've worded this betrays the internalization of their suffering as a MS developer.
- kolektiv 3y ago
  Broadly speaking I agree with you in principle - but in practice over time you come to realise that there are only shitty clients. They might not intend to be, they might not have started out that way, but time is a destructive thing...
- GMoromisato 3y ago
  The issue is that sometimes you need to implement an API which existing clients are already using. You can't go back in time and re-compile, much less re-write the clients. It all depends on how the clients are currently using the API. If the clients are already testing for NotSupportedException, then that's what you should return. But if not, you need a different approach.
  - pas 3y ago
    well, that seems like an important piece of the contextual puzzle, because the Xbox printing example by itself seems extremely dumb. (issuing/publishing games on Xbox is not a wild wild west of unknown binaries, if someone cannot get the source code for their thing they are very unlikely to get their thing on Xbox. yes, there are probably binary blobs, but still, to me in this context it's ridiculous that instead of a an exception handling wrapper on the application side the platform does these fakes.)
- Scarblac 3y ago
  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.
forrestthewoods 3y ago
> Well, the wrong thing to do is to have the printing functions throw a NotSupportedException. The app that the user installed on the Xbox was probably tested primarily, if not exclusively, on a PC, where printing is always available. When run on an Xbox, the exception will probably go unhandled, and the app will crash. Exceptions are such a catastrophically bad idea in almost all cases. It is absolutely infuriating as a programmer to call a function and not know if it can throw and, if it can, not know what it can throw. It’s a disaster. I so desperately wish that C++ had Rust’s Result type and pattern matching. std::optional and std::expected are kinda sorta ok, but you really want compiler enforced pattern matching. What a tragedy.
- mike_hock 3y ago
  > if it can throw and, noexcept. Granted, it may not have the annotation but still not throw in reality, but a Rust function can also declare a Result return type but never actually return an error. > if it can, not know what it can throw How do you square that with backward compatibility? If you declare what you can throw, what do you or any of your transitive dependencies do when they want to change their implementation in a way that makes a new error a possibility? Either you shove it all into an UNKNOWN error that you hopefully declared from the get go to be future-proof, or you break all your downstream users every time. So either no compatibility, or over time your API converges to a meaningless UNKNOWN error code for almost everything and a bunch of legacy error codes that are never used.
  - forrestthewoods 3y ago
    I’ve never, ever seen a codebase that reliably used noexcept. boost and Python are my arch-nemesi because they make heavy use of exception errors and it makes the APIs an absolutely miserable nightmare to use. > How do you square that with backward compatibility? Huh? The same way normal code handles changing function arguments or return types? I have absolutely never relied on exceptions to “future proof” return error types! Yikes. The only thing I have ever used exceptions for is to escape bad input/data. It gets trapped internally in the “private” API and same result types are returned through the public API. I would much rather have a return type of Result<T, Exception const*> than T but also maybe it throws or maybe not and you almost definitely forgot to check which is why people do filthy filthy hacks like the OP article.
thimp 3y ago
It's a crap analogy. Why would you expose a printing API on a device without printing support? Just ifdef it out on the build.
- gruez 3y ago
  How about an app originally designed for iPhone but is running on an iPad? iPhones can make calls, but iPads can't. Sure, a properly designed iPad app wouldn't try to use the phone functionality, but what if the developer is too lazy to develop a dedicated iPad app? Surely a crappy iPhone app running on iPad is better than no app at all?
  - alpaca128 3y ago
    Wouldn't that be part of Apple's app reviews?
    - Arainach 3y ago
      There are plenty of apps already in the store. Apple wants to launch their new device and have tons of apps available. The best way to do that is for the apps to just run, not to require millions of developers (plenty of which no longer exist) to rebuild.
    - deleted 3y ago
      [deleted]
    - gruez 3y ago
      Only if you try to publish it as an iPad app. See also: https://hacknicity.medium.com/how-iphone-only-apps-appear-on-ipad-59f7902da4c9 https://hacknicity.medium.com/how-iphone-only-apps-appear-on...
  - chrisjj 3y ago
    > Surely a crappy iPhone app running on iPad is better than no app at all? Bogus comparison. Non-crappy apps are a thing.
deleted 3y ago
[deleted]
iamtedd 3y ago
> the function for installing a printer can return immediately with a result code that means “The user cancelled the operation.” I hope this is never shown to the user, because one of the most infuriating things that can happen is when the computer tells me that I did something I actually didn't.
- xp84 3y ago
  It would be unlikely that it would be, since to any properly implemented app, the fact that the user cancelled is not an error since it thinks you did it yourself on purpose. On the other hand, I recall a few years ago (in the days of one of Apple’s least stable Mac OS [X] releases) seeing the message frequently after a random kernel panic “You restarted your computer because of a problem.” And I would be pretty ticked, saying “Nope! YOU restarted yourself. 0% of this was me. I was sitting here and you just died and rebooted.” They changed it to use passive voice instead, a year or two after that!
- benjaminpv 3y ago
  Or more broadly, don't do something unbidden on my behalf then complain when it doesn't work. I swear 75% of the times I've daydreamed about a return to a single-tasking OS like DOS was on account of software trying to 'help' me.
maerF0x0 3y ago
I've learned this as "swallowing errors" and IMO it's a poor practice. Not only does it not solve the issue at hand (you cannot print on an xbox), but it actively hides how broken the software is, which makes bug discovery and testing much harder. This is one thing I like about Go's panic. You're mostly not supposed to use it or recover from it at run time. It serves as a great vehicle to blare loud sirens at testing time that you (the programmer) screwed up (and that's ok, we all do), and it's time to figure out where and how to fix it :) PS this analogy works in a lot of domains - If you have actors in a system actively trying to hide their flaws/errors it will be exponentially harder to root them out and solve the issues.
- gruez 3y ago
  >It serves as a great vehicle to blare loud sirens at testing time that you (the programmer) screwed up (and that's ok, we all do), and it's time to figure out where and how to fix it :) Right, but if you read the article, the author is talking less about the developer experience and more about the user experience. "blare loud sirens" is great if you're a tester/developer, not so much if you're an end user. When it comes to the end user, "swallowing errors" is preferable to crashing.
  - ploxiln 3y ago
    If you read the article, this isn't swallowing errors, it's just returning more-backwards-compatible errors. > ...when the app tries to print, it will ask the user to select a printer, and show an empty list. The user realizes, “Oh, there are no printers,” and cancels the printing request. > To deal with apps that get fancy and say “Oh, you have no printers installed, let me help you install one,” the function for installing a printer can return immediately with a result code that means “The user cancelled the operation.” > a documented return value is ERROR_CANCELLED to mean that the user cancelled the creation of the widget. Therefore, apps are already dealing with the possibility of widgets not being created due to conditions outside their control, so we can take advantage of that I'm annoyed when "modern web apps" (or similar desktop apps) seemingly do nothing when there's some error, you don't know if you need to wait a bit, or click again (great fun when the UI jumps 1ms before your re-click), or full reload/restart ... luckily that's not at all what this article recommends!
anonacct37 3y ago
I love and hate this. On a visceral level I don't like dealing with issues via malicious compliance. OTOH I absolutely agree this is a good call if your goal is for more users to be able to run more software on your platform, even if printing is broken.
elwell 3y ago
> With this behavior, when the app tries to print, it will ask the user to select a printer, and show an empty list. I see Microsoft has not learned from 30 years: https://www.reddit.com/r/hacking/comments/djvzd/windows_nt_login_hack_gif/ https://www.reddit.com/r/hacking/comments/djvzd/windows_nt_l...
- nonethewiser 3y ago
  That os amazing
1970-01-01 3y ago
This is also very good for security. Correctly dismissing an API call means these programs aren't able to go off and do extra naughty things.
leaf8937 3y ago
throw checked exception so that xbox will have to handle the exception. xbox implementation can donothing if they want.
- Arwill 3y ago
  Sometimes this kind of error handling is the cause of program slowdowns. So the API fails, but the program retries anyway, and so fails again endlessly. The user doesn't see anything from this happening, only that "the app is slow". Windows is plagued by this kind of behaviour. Its both what the article suggests can cause this, but throwing and ignoring exceptions can have this effect too. The goal, IMO, would be to force the app not to try (or not to try once it failed) something that is bound to fail.
leaf8937 3y ago
if possible, throw checked exception which must be handled.
zxcvbnm 3y ago
Wrong, errors should not go unnoticed, let alone helping them to propagate. Cascading effects should be kept on a short leash. System takes one step in the wrong direction, kill it. The two most miserable things are, things not happening and there's no feedback on why, and, the other extreme, when things are overengineered and no one can predict where problems might cascade to.
- 12_throw_away 3y ago
  lord grant me the confidence of someone who reads a thoughtful explanation of a problem and its solution by Raymond Chen and responds with "Wrong, "
  - deleted 3y ago
    [deleted]
  - B1FF_PSUVM 3y ago
    It's hilarious, Chen has been doing this right - on the bleeping internets for all to see - for thirty years and we've greenhorns going "Nah, mate, you're doing it wrong."
- thrwwycbr 3y ago
  Maybe you should build an operating system from scratch, keep building it for more than 25 years and then come back to revise your comment?
patapong 3y ago
Hmmm I see and appreciate the idea behind this. That said, it seems confusing for the user to be shown an empty list of printers if no printers can be installed on the platform. In my opinion, it would be preferable to show the user a dialog that says "This platform does not support printing" and, once they dismiss the dialog, inform the program that the user cancelled the print action.
- city41 3y ago
  I agree, using the empty list to communicate to the user the situation is making an assumption about the user. A lot of users have never set up or dealt with printers ever. I can say for sure that an empty list of printers would confuse a lot of people in my household.
o11c 3y ago
Making it a linker error doesn't even seem to be considered. Xbox is a separate target so a recompile is needed anyway ...
- Arainach 3y ago
  No, it's not - that's the point of the Universal Windows Platform - compile once, put in store, run everywhere. This also isn't just about new platforms. If you have a desktop operating system and want to change the behavior of an API in a future version, you have to do this same process.
Throw6away 3y ago
Microsoft’s MDM APIs will return a 500 (server error) on a VM if you try to get a list of wireless networks, instead of the saner approach of returning an empty list. The same APIs will return a 418 (I’m a teapot) if you mistakenly try to add an already-existing setting, instead of just updating it as one might expect. They get points for originality, but don’t follow the advice in this article.
- yau8edq12i 3y ago
  Microsoft has around 238000 employees according to Wikipedia. That they are not all strictly following Raymond Chen's latest blog post isn't surprising.
philipwhiuk 3y ago
I'm sorry but that code sample is an incomprehensible eyesore. And I've written PHP4.
- LASR 3y ago
  What's crazy is that I didn't even realize it until you pointed it out. I've been doing Win32 for so long it's like reading the green symbols in The Matrix. This all looks "normal" to me.
- zerr 3y ago
  Besides being unreadable, it is well known that Win32 API code is unwritable. It is only copy/paste-able.
- jeroenhd 3y ago
  Windows headers like uppercase. They also like very explicit types, as far as the language accepts them, of course. For example, HRESULT really is just a 32 bit integer with special rules (top bits set subsystem that cause the error, bottom bits set error code, hence the conversion function for best practice). Stripping out the Windows types and compile-time validation and the wrappers, and picking non-Windows error codes, you can turn the code into more Unix-like C++: int32_t CreateWidget(int32_t* widget) { *widget = nullptr; return ECANCELED; } int32_t GetWidgetAliases(wchar_t* aliases, uint16_t capacity, uint16_t* actual) { *actual = 0; return EBADF; } int32_t EnableWidget(int32_t widget, bool value) { return EBADF; } int32_t Close(int32_t widget) { return EBADF; } However, this code may not function if you're building for 32-bit Windows and it may not work on every compiler; it just assumes certain bit sizes that the API only guarantees in the form of typedefs.
sirspacey 3y ago
I missing what the magic is here. This seems like a long way to go for “we know that this device is an Xbox and Xbox doesn’t support printing, let’s tell the user” Only it doesn’t tell the user. It leads them down a path implying implementation is possible. On the other hand, I now know why so many issues I’ve troubleshooted on MS products end in tears and complete confusion as to why they wouldn’t just say “this is not a feature you can use on this device.”
- filleduchaos 3y ago
  > This seems like a long way to go for “we know that this device is an Xbox and Xbox doesn’t support printing, let’s tell the user” You're missing the fact that Xbox can run apps developed for (desktop) Windows, and that the scenario in the article is about the platform <-> end user relationship and does not involve the app developer at all.
  - sirspacey 3y ago
    Ok, appreciate the insight. Doesn’t the platform: 1. Know that is a windows app 2. Know that it is Xbox So it could override the “print” request with a user appropriate notification?
- comicjk 3y ago
  I agree. The author's description of what is "reasonable" sounds like a blueprint for many of my late nights struggling with Windows: "apps that assume that printing works will still behave in a reasonable manner: You’re just on a system that doesn’t have any printers and all attempts to install a printer are ineffective." Maybe the underlying assumption is that the users will give up before spending an "unreasonable" amount of time on these tar pit features.
crooked-v 3y ago
Doing nothing correctly sounds like hard work. I guess I'll try it out sometime later when I have more energy.
denysvitali 3y ago
Wouldn't it be simpler to just create a "Save to PDF" printer and use that in the Xbox? This way the API stays compatibile, and it actually makes it useful
LuciBb 3y ago
[dead]
SillyUsername 3y ago
Exception safety guarantees have been around for decades and were originally defined by David Abrahams who was on the C++ standards board. As the author is a Microsoft employee I'm a little surprised no attribution or reference to the original author of (the levels of) exception safety guarantees which his article partly describes. Raymond Chen (article author) is refering to the "no throw guarantee" in his article as opposed to one of the other outcomes https://en.m.wikipedia.org/wiki/Exception_safety https://en.m.wikipedia.org/wiki/Exception_safety
laserbeam 3y ago
Good: average apps continue to work as expected. Bad: good apps can't know what's supported or not. What's missing from the article is adding a way for apps to detect and handle this behavior. (Using the printer example) There should also be some API that tells me "printing is not supported on this platform" somehow. If I want to be a good software developer I should hide the print button in the UI in a very predictable way. It's great that if I actually try to print nothing happens as expected. It's bad if I can't detect that printing would never work, and I should be able to do that via at least some function call that doesn't magically noop.
- josephcsible 3y ago
  From the article: > Now, you probably also want to add a function to check whether printing even works at all. Apps can use this function to hide the Print button from their UI if they are running on a system that doesn’t support printing at all.
  - laserbeam 3y ago
    Somehow I missed that. Thanks!
cratermoon 3y ago
This is also like Null Object or Special Case pattern. It simplifies error handling, and because error handling code is often poorly tested it ends up being a big source of catastrophic failures. Making illegal states unrepresentable, or as John Ousterhout puts it: define errors out of existence: https://wiki.tcl-lang.org/page/Define+Errors+Out+of+Existence https://wiki.tcl-lang.org/page/Define+Errors+Out+of+Existenc...
armchairhacker 3y ago
Slightly tangential, this reminds me of how to `sleep` in JavaScript without using async: https://stackoverflow.com/a/37575602 https://stackoverflow.com/a/37575602
Wowfunhappy 3y ago
> “I asked for a widget, and you gave me one, and then when I showed it to you, you said, ‘That’s not a widget.’ This API is gaslighting me!” The entire point, it should be noted, is to gaslight the app. But the API must be good enough at gaslighting that the app doesn't discover the lie.
johngossman 3y ago
The point the critics of this piece seem to be missing is that there is not an exceptional case here that needs an error to be thrown. There are NO printers attached to the device (in this case by definition), and an app should cleanly handle that case, not crash. You wouldn’t throw an exception on a laptop just because it couldn’t reach the printer.
- PennRobotics 3y ago
  If you want a clear, modern example of a popular non-Microsoft product doing printer availability wrong, it's gnome-control-center. Add a printer in Settings. While the printer is installing, click over to the "Color Profiles" tab. If you time it right, gnome-control-center will crash. If you dive into the details, you see that it was trying to enumerate the available printers (it knows one should be there) but that info doesn't exist yet. So it just crashes. Thankfully, the fix is to just wait a few seconds for GNOME to finish installing the printer and restart Settings. Still, it's the principal app responsible for making your desktop work correctly as an end user with some unknown computing background. In a perfect world, this app should never crash. It's hard to think about edge cases. It's even harder to imagine your handling of edge cases has its own edge cases. Right or wrong, at least the author is thinking deeper than "bad app, needs to be rewritten to support Wayland"
evnc 3y ago
From the title alone, I initially thought this would be about meditation.
_Algernon_ 3y ago
The only reason an X-box doesn't support printing is because Microsoft has defined it as such. A x-box is just as capable to print as the Windows machine in the next room over from a hardware perspective. Which means this "solution" to a stupid, self-created problem is stupid. I bet this workflow will lead at least a handful of people to ask "How do I add a printer to my X-box?" instead of "Fuck the app crashed, better not do that again." Microsoft has so much stupid, corporate driven decision making. Can't wait for it to follow in IBM's footsteps.
yungporko 3y ago
"The idea here is to have the printing functions all behave in a manner perfectly consistent with printing being fully supported, yet mysteriously there is never a printer to print to." this is exactly the kind of stupid shit that makes me hate using anything from microsoft. on what planet is this desirable behaviour? is it beyond microsoft's capability to just show a message saying "Printing is not available on Xbox"?
fullstackchris 3y ago
> The idea here is to have the printing functions all behave in a manner perfectly consistent with printing being fully supported, yet mysteriously there is never a printer to print to. What? Why would you ever do this? This post screams of "can't see the forest from the trees" Sure, now you don't have your app crashing, and instead you have this weird state of seeming like you can print but ultimately can't, wasting users time and perhaps frustrating them even more. Why not literally just show a dialog like "printing is not supported from an Xbox"? Easy to develop, easy to understand... everyone wins.
korginator 3y ago
There are widely used practices for API design and versioning that work well today. While this article's kludgy approach to backward compatibility may have been passable a few decades ago, this is a terrible way to approach the problem in 2024, specially with services & APIs being deployed & distributed across platforms. The article illustrates how *not* to build APIs.
akho 3y ago
This starts with an Xbox not being able to print, while being able to run computer applications. The correct solution is not to have that. There is no graceful way to recover otherwise, no matter how "inert" you are.
saagarjha 3y ago
Everyone here is hung up on doing "nothing" and handling "errors" and I feel like the post does a poor job explaining how it is not just swallowing everything that's going wrong and going kumbaya. The actual context is that the author is doing emulation/compatibility for software that will not change, and that's very different from most contexts. This is especially confusing because Microsoft often blurs the line between the two themselves, and that's not actually what is being talked about here at all. Really, emulation is all about telling lies. Your Xbox doesn't actually have a way to attach a printer. You're running a game on Linux, not Windows. Your fake iPhone is actually a ARM server in AWS. The point here is that if you're going to lie you better do so convincingly. That's because you need existing applications to still work! When Microsoft says you can port your existing Windows app to Xbox the promise for the Windows app was that it would be able to print, and so Xbox needs to lie for that to happen. This is very different from a normal error. If a program does a use after free, and you silently pretend the bug doesn't exist by working around it, then you're not doing anything correctly. That's because nobody promises that your existing use after frees will be bug-for-bug compatible on a new platform.
- lucianbr 3y ago
  > There may be times where you need to make an API do nothing. It’s important to have it do nothing in the correct way. > For example, Windows has an extensive printing infrastructure. But that infrastructure does not exist on Xbox. What should happen if an app tries to print on an Xbox? It says nowhere that the context is doing emulation for software that will not change. You just assume that because it supports the position you like. In fact, everything written applies to a program that I might write tomorrow for an XBox, and try to print something. There is nothing that designates this behavior only for old, unmaintained software.
  - buttercraft 3y ago
    If you write a program tomorrow, use the API correctly and this issue will not apply to you. This is for apps that aren't well written and don't check for the capabilities ahead of time.
sporkland 3y ago
I wish the concept of dev mode and prod mode were baked deeper into all language runtimes/libraries. e.g. before going to production with real users these cases should error as hard as possible, including potentially logging crashing the program to make the program errors super visible. Then in production it should largely log these things in error logs and keep chugging along. And not like an environment variable with conditions. Something as first class as changing the standard exception and fatal calls behaviors.
mrcsharp 3y ago
What a weird thread of comments this was. There are clearly people who just don't like anything Microsoft does. The point of the blog is to make the process of bringing apps (UWP) to XBOX be frictionless: no recompile required, no messy ifdefs, none of that extra work. The App would "just work". Then, it's up to the developers to start adjusting the app to fit the XBOX platform more. The important thing here is that the developer was able to bring the app with no effort to XBOX. This is good for both the platform and the developer. To the user, it's a clear signal that they can't print since the list of printers are empty. But most importantly for them, the app did not crash or show the most hated error: "oops something went wrong. Try again later." Is that message a better experience for the user? No. Sure, the developers can recompile the app and add a more descriptive message but then we're back to square one.
- PH95VuimJjqBqy 3y ago
  I honestly feel like 95% of the people in this thread didn't understand the article. for example, accusations of swallowing errors. That's not the point, not at all.
empuxr 3y ago
As a Platform Engineer who has to work with Azure on a daily basis, I am so tired of their APIs and services making exceptions left and right, sometimes for their own shitty clients. The result is a Patchwork product suite, services never work as expected but deviate from their documentation (or rather what they are claiming is their documentation). The Daily Azure shit Mastodon account has more than enough examples of this. For example https://azsh.it/167 https://azsh.it/167 or https://azsh.it/107 https://azsh.it/107 This article made me realize while Azure is the way it is - unreliable and broken.
RhondaAyala 3y ago
[dead]

432 points by AndrewDucker 3y ago

I find nothing quite as frustrating as UIs that suggest a device could exist, but it's not there right now. I then have to spend time to discover that these devices are not supported, and that screen was just some mock someone came up with.

kentonv 3y ago
Sure, but you'd be more frustrated if your app just crashed. If the app is not prepared for printing not being supported, and printing just throws an exception, the app probably just crashes. That's bad. If the app is prepared for printing not being supported, it should be calling the explicit API to check if printing is supported, and then not displaying the UI for printing if it isn't. The article is not about these apps, it's about what to do about apps that fail to check first. The bug is with the app, but a good platform does its best to make bad apps work anyway, rather than have them just crash.
- tsimionescu 3y ago
  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.
  - hn_throwaway_99 3y ago
    > 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.
    - kentonv 3y ago
      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.
      - hn_throwaway_99 3y ago
        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.
        kentonv 3y ago
        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.
  - nonethewiser 3y ago
    Yes exactly, but Microsoft isnt the one who can implement that.
    - tsimionescu 3y ago
      This was about the Xbox printing subsystem, right? Of course they can implement that.
      - nonethewiser 3y ago
        It would be whoever writes the software (ie the game) for the xbox.
        tsimionescu 3y ago
        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.
  - BeFlatXIII 3y ago
    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.
- nerdponx 3y ago
  > Sure, but you'd be more frustrated if your app just crashed. I don't know about that. If it crashes, I might not try that thing again.
- yungporko 3y ago
  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?
  - badsectoracula 3y ago
    > 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.
    - tsimionescu 3y ago
      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.
      - badsectoracula 3y ago
        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.
        tsimionescu 3y ago
        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.
nonethewiser 3y ago
Perhaps the software author is to blame here then not Microsoft. Because they didnt handle the printer case. Where Microsoft comes in is that the software doesnt crash because the software provider didnt account for printers.

Analemma_ 3y ago

I understand the logic here, and I'm aware Microsoft has a large number of convoluted backward-compatibility requirements, but this seems like drinking to solve your problems and just putting off the inevitable hangover. To be clear: what you're doing here is lying to the user and the developer. Maybe that's justified in isolation, but now this lie is one more bit of "hidden state" you have to keep track of in further development and integration testing. And just like in the real world, lies have a tendency to compound on themselves until you're completely lost in them and have no idea what reality is. I have a feeling that "solutions" like this are part of why an increasing number of my computing problems take the form of, "I tried to take an action, nothing happened. No error, no activity, nothing.", and are impossible to debug or diagnose. UX designers made themselves terrified of ever showing an error code to a user, but they took that and replaced it with a world where your shit just doesn't work, and when you try to figure out why, all the OS does is shrug.

ace2358 3y ago
This resonates with me. My computers used to crash at the app level, OS level or hardware level. Now when something goes wrong the system just kinda gets lazy and stops working. But it won’t crash. I’ve had my mac pinwheel on the login screen. I can still access the shell and file shares remotely, and even screen share to a logged in user. But login.app refuses to crash so it’ll just pinwheel. I’m glad I never forgot to turn things off and on for troubleshooting :(
- Analemma_ 3y ago
  I have a suspicion that "number of crashes" got badly Goodharted inside major OS vendors. After all, you can "prevent" most crashes by just having a top-level "catch(Exception e) {}" handler, which of course just leads to the program doing nothing instead in an un-debuggable way, but hey: crashes went down! KPI achieved!
- bombcar 3y ago
  My experience is that macOS especially really REALLY absolutely hates when the Internet goes sideways - not actually down, but really bad packet loss; DNS starts being slow and failing sometimes but not completely ... then you enter hell. Next time it happens try turning network connections all the way off.

Jabrov 3y ago

"The idea here is to have the printing functions all behave in a manner perfectly consistent with printing being fully supported, yet mysteriously there is never a printer to print to." This must be satire. Otherwise I can't comprehend how something as infuriating as this could be presented as a good or smart thing to do UX-wise

recursive 3y ago
The alternative is that the app fails to run at all. Doesn't seem like satire to me.
- GMoromisato 3y ago
  Or worse, crashes at a random spot because it tried to initialize the printer stack.
  - bombcar 3y ago
    Anyone who has spent some time with vintage or otherwise older software (and even some new stuff) should have experienced a "don't do this, it explodes" - often the cause is something akin to what Raymond is pointing out. The software asks for something, gets back an answer it can't handle, explodes.
avery17 3y ago
What do you suggest as an alternative?
kentonv 3y ago
No, this is a guy who has been one of the architects of Windows for more than 30 years giving you hints about how they achieved their reputation for amazing backwards compatibility. He really, really knows what he's talking about.
daveoc64 3y ago
If the two options are "this app can't run on your Xbox" or "this app runs on your Xbox, but the printing functions don't work and some of the messages are a little weird", which option do you think users would prefer?

lucianbr 3y ago

Once upon a time it was considered a great strategy for browsers to make the best effort to display a page, even if the html code had errors. Just try to guess the author's intention as well as you can, and go ahead. Errors are bad. Users don't want errors. I thought we learned from that experience. Apparently not.

debacle 3y ago
"We" did. Microsoft didn't. Not unexpected.
- recursive 3y ago
  Is this part of a fan fiction where MS isn't amazing at legacy compatibility?
  - Peter0x44 3y ago
    I think their BC is overrated. Wine manages to do a better job.
subarctic 3y ago
What did you think we learned?
- lucianbr 3y ago
  That every single behavior that attempts to guess the users's intent becomes a relied upon part of the software, and this over time grows to an impossible amount of cruft. See this, hilariously hosted also by microsoft: https://techcommunity.microsoft.com/t5/discussions/funny-story-of-browser-wars-from-the-beginning-of-the-time-user/m-p/1079832 https://techcommunity.microsoft.com/t5/discussions/funny-sto... > And then Google built Chrome, and Chrome used Webkit, and it was like Safari, and wanted pages built for Safari, and so pretended to be Safari. And thus Chrome used WebKit, and pretended to be Safari, and WebKit pretended to be KHTML, and KHTML pretended to be Gecko, and all browsers pretended to be Mozilla, and Chrome called itself Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13, and the user agent string was a complete mess, and near useless, and everyone pretended to be everyone else, and confusion abounded.

throwawayfrsbob 3y ago

And they ask why we're cynical. I'm about done with this whole "personal computing" fad.

fidrelity 3y ago

Your ecosystem has gone so complex that you can't test it anymore. So instead of handling errors properly you suggest to implement a convoluted user flow that offers always failing actions (install a printer when there's none available). If that's really the suggestion of product and engineering leadership at MSFT no wonder all their products...err...work as designed.

gruez 3y ago
>Your ecosystem has gone so complex that you can't test it anymore. An operating system with billion+ install base, and millions of developers tends to be complex. I'm not sure what you're proposing here, have your platform/software be more niche? Somehow get all of them to fall in line? >So instead of handling errors properly you suggest to implement a convoluted user flow that offers always failing actions (install a printer when there's none available). How are you going to "handle errors properly" if the publisher of the software in question went out of business?
Arainach 3y ago
What is "your ecosystem" here? Part of running a platform is that the code running on it is written by other people, not you, and that your customers will be relying on that code. When the software your customers are relying on breaks because of a change you made, it doesn't matter whose "fault" it is. It's broken, it broke because of something you did, and you have burned customer trust - not the trust of whoever wrote the software you believe is "wrong" or "to blame", trust of your platform and company.
- xp84 3y ago
  It is so obvious from reading these comments here who is not, and would never ever want to be, a platform engineer. It’s hard for some people to grasp that you need to not only interact with, but thoroughly accommodate, software written by others whom you don’t control (often due to the one-way direction of time flow).
nearbuy 3y ago
Not at all what he is saying. Microsoft has no problem testing their printer function across all platforms in their apps and removing the print button on platforms where it's not supported. Ideally, everyone would do this. This is for other developers who are writing 3rd party apps for Microsoft's platforms and who don't always test perfectly. They may have written their app primarily for Windows and didn't consider what happens when someone installs it on their Xbox and clicks "print". In that case, the API should "just work", instead of crashing with an error message.

paxys 3y ago

People are reacting negatively as expected, but stuff like this is exactly why you can click on a file that was written in Word '97 or a game that was compiled for MS-DOS three decades ago and it opens on your computer exactly as expected. Backwards compatibility is always messy. You either do it imperfectly or don't do it at all.

blibble 3y ago
MS-DOS software doesn't work on modern 64-bit windows you get a dialog saying "unsupported" now you can download dosbox but that isn't really "exactly as expected"
dupertrooper 3y ago
Umm but you can’t find a current version of Word that actually does that. Try it sometime.
- EvanAnderson 3y ago
  Here's a rather large (5MB) vintage 1996 Microsoft Word document: https://archive.org/download/cd-pn-0527a/CD_ROM.ISO/APPENDIX%2FDNS.DOC https://archive.org/download/cd-pn-0527a/CD_ROM.ISO/APPENDIX... That file opens and appears to render just fine for me in Word 2016. This has been my experience w/ Office files in general. Old files open and render very well in newer versions.
  - weinzierl 3y ago
    The point made above was "opens exactly as expected". So, does it look like the authors intended in 1996? I doubt it.
    - Arainach 3y ago
      If you "doubt" it, please provide a specific example of what you believe is inaccurate in the document rendering.

hailmac 3y ago

Why /wouldn't/ I want to print something from my Xbox?

daveoc64 3y ago
Due to the input device most people will use (controller), apps that work best on Xbox are those used to consume content like photos or videos. You might be viewing something and want to print it, but that's clearly not desirable enough for Microsoft to build print functionality into the Xbox UI.
- maerF0x0 3y ago
  I mean, it has USB ports. If I can plug it in, I'd like to be able to use it _somehow_ , even if that means installing another app that does direct port/device access or w/e . ie, it should be possible (but not necessarily super easy)
  - Arainach 3y ago
    The explicit point of video game consoles is to be a locked down experience, not a PC. Hardware access is generally used for piracy, which game developers do not like.
Arainach 3y ago
The printer drivers don't run on XBox. XBox isn't exposing all of the legacy Win32 APIs and driver models available in desktop.
- mrguyorama 3y ago
  It's an x64 CPU running most of Windows with plentiful and fully supported USB ports. Why CAN'T I print from my Xbox? I can print with my phone, so why not my Xbox? I'm sure there's something about "windows print subsystems are pretty terrible and we should excise them from anything we can" and "reduce code to reduce bugs" but like.... There's no technical reason it can't

ofslidingfeet 3y ago

This mindset is even less ethical than it seems, and I'm not surprised to see it present at microsoft.

Arainach 3y ago
What do you mean by "ethical" here, and why is it unethical to preserve ABI compatability?
- chrisjj 3y ago
  > why is it unethical to preserve ABI compatability? Straw man. What's unethical here is deceiving the user.
  - Arainach 3y ago
    There is no deception. There are no printers, and that's what the API returns.
    - chrisjj 3y ago
      The deception is concealment of the fact printing is unsupported. Nk printers is merely a cover story. "NotSupportedException" is there for a reason.
      - Arainach 3y ago
        Nothing is being concealed. If you want to know if printing is supported, call IsPrintingSupported. The information is there, the API is there.
        chrisjj 3y ago
        The one deceived is the user. He does not have the option of calling an additional function.
- 3y ago

happytoexplain 3y ago

The specific thing the author is suggesting is correct (components should suffer before users do), but I take great offense to their framing. "There may be times where you need to make an API do nothing." "The wrong thing to do is to have the printing functions throw a NotSupportedException." No, no, absolutely no - what the author is describing is a hack to support a shitty client. Yes, you have to do this sometimes. No, it is not normal or generalizable advice. The way they've worded this betrays the internalization of their suffering as a MS developer.

kolektiv 3y ago
Broadly speaking I agree with you in principle - but in practice over time you come to realise that there are only shitty clients. They might not intend to be, they might not have started out that way, but time is a destructive thing...
GMoromisato 3y ago
The issue is that sometimes you need to implement an API which existing clients are already using. You can't go back in time and re-compile, much less re-write the clients. It all depends on how the clients are currently using the API. If the clients are already testing for NotSupportedException, then that's what you should return. But if not, you need a different approach.
- pas 3y ago
  well, that seems like an important piece of the contextual puzzle, because the Xbox printing example by itself seems extremely dumb. (issuing/publishing games on Xbox is not a wild wild west of unknown binaries, if someone cannot get the source code for their thing they are very unlikely to get their thing on Xbox. yes, there are probably binary blobs, but still, to me in this context it's ridiculous that instead of a an exception handling wrapper on the application side the platform does these fakes.)
Scarblac 3y ago
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.

forrestthewoods 3y ago

> Well, the wrong thing to do is to have the printing functions throw a NotSupportedException. The app that the user installed on the Xbox was probably tested primarily, if not exclusively, on a PC, where printing is always available. When run on an Xbox, the exception will probably go unhandled, and the app will crash. Exceptions are such a catastrophically bad idea in almost all cases. It is absolutely infuriating as a programmer to call a function and not know if it can throw and, if it can, not know what it can throw. It’s a disaster. I so desperately wish that C++ had Rust’s Result type and pattern matching. std::optional and std::expected are kinda sorta ok, but you really want compiler enforced pattern matching. What a tragedy.

mike_hock 3y ago
> if it can throw and, noexcept. Granted, it may not have the annotation but still not throw in reality, but a Rust function can also declare a Result return type but never actually return an error. > if it can, not know what it can throw How do you square that with backward compatibility? If you declare what you can throw, what do you or any of your transitive dependencies do when they want to change their implementation in a way that makes a new error a possibility? Either you shove it all into an UNKNOWN error that you hopefully declared from the get go to be future-proof, or you break all your downstream users every time. So either no compatibility, or over time your API converges to a meaningless UNKNOWN error code for almost everything and a bunch of legacy error codes that are never used.
- forrestthewoods 3y ago
  I’ve never, ever seen a codebase that reliably used noexcept. boost and Python are my arch-nemesi because they make heavy use of exception errors and it makes the APIs an absolutely miserable nightmare to use. > How do you square that with backward compatibility? Huh? The same way normal code handles changing function arguments or return types? I have absolutely never relied on exceptions to “future proof” return error types! Yikes. The only thing I have ever used exceptions for is to escape bad input/data. It gets trapped internally in the “private” API and same result types are returned through the public API. I would much rather have a return type of Result<T, Exception const*> than T but also maybe it throws or maybe not and you almost definitely forgot to check which is why people do filthy filthy hacks like the OP article.

thimp 3y ago

It's a crap analogy. Why would you expose a printing API on a device without printing support? Just ifdef it out on the build.

gruez 3y ago
How about an app originally designed for iPhone but is running on an iPad? iPhones can make calls, but iPads can't. Sure, a properly designed iPad app wouldn't try to use the phone functionality, but what if the developer is too lazy to develop a dedicated iPad app? Surely a crappy iPhone app running on iPad is better than no app at all?
- alpaca128 3y ago
  Wouldn't that be part of Apple's app reviews?
  - Arainach 3y ago
    There are plenty of apps already in the store. Apple wants to launch their new device and have tons of apps available. The best way to do that is for the apps to just run, not to require millions of developers (plenty of which no longer exist) to rebuild.
  - deleted 3y ago
    [deleted]
  - gruez 3y ago
    Only if you try to publish it as an iPad app. See also: https://hacknicity.medium.com/how-iphone-only-apps-appear-on-ipad-59f7902da4c9 https://hacknicity.medium.com/how-iphone-only-apps-appear-on...
- chrisjj 3y ago
  > Surely a crappy iPhone app running on iPad is better than no app at all? Bogus comparison. Non-crappy apps are a thing.

deleted 3y ago

[deleted]

iamtedd 3y ago

> the function for installing a printer can return immediately with a result code that means “The user cancelled the operation.” I hope this is never shown to the user, because one of the most infuriating things that can happen is when the computer tells me that I did something I actually didn't.

xp84 3y ago
It would be unlikely that it would be, since to any properly implemented app, the fact that the user cancelled is not an error since it thinks you did it yourself on purpose. On the other hand, I recall a few years ago (in the days of one of Apple’s least stable Mac OS [X] releases) seeing the message frequently after a random kernel panic “You restarted your computer because of a problem.” And I would be pretty ticked, saying “Nope! YOU restarted yourself. 0% of this was me. I was sitting here and you just died and rebooted.” They changed it to use passive voice instead, a year or two after that!
benjaminpv 3y ago
Or more broadly, don't do something unbidden on my behalf then complain when it doesn't work. I swear 75% of the times I've daydreamed about a return to a single-tasking OS like DOS was on account of software trying to 'help' me.

maerF0x0 3y ago

I've learned this as "swallowing errors" and IMO it's a poor practice. Not only does it not solve the issue at hand (you cannot print on an xbox), but it actively hides how broken the software is, which makes bug discovery and testing much harder. This is one thing I like about Go's panic. You're mostly not supposed to use it or recover from it at run time. It serves as a great vehicle to blare loud sirens at testing time that you (the programmer) screwed up (and that's ok, we all do), and it's time to figure out where and how to fix it :) PS this analogy works in a lot of domains - If you have actors in a system actively trying to hide their flaws/errors it will be exponentially harder to root them out and solve the issues.

gruez 3y ago
>It serves as a great vehicle to blare loud sirens at testing time that you (the programmer) screwed up (and that's ok, we all do), and it's time to figure out where and how to fix it :) Right, but if you read the article, the author is talking less about the developer experience and more about the user experience. "blare loud sirens" is great if you're a tester/developer, not so much if you're an end user. When it comes to the end user, "swallowing errors" is preferable to crashing.
- ploxiln 3y ago
  If you read the article, this isn't swallowing errors, it's just returning more-backwards-compatible errors. > ...when the app tries to print, it will ask the user to select a printer, and show an empty list. The user realizes, “Oh, there are no printers,” and cancels the printing request. > To deal with apps that get fancy and say “Oh, you have no printers installed, let me help you install one,” the function for installing a printer can return immediately with a result code that means “The user cancelled the operation.” > a documented return value is ERROR_CANCELLED to mean that the user cancelled the creation of the widget. Therefore, apps are already dealing with the possibility of widgets not being created due to conditions outside their control, so we can take advantage of that I'm annoyed when "modern web apps" (or similar desktop apps) seemingly do nothing when there's some error, you don't know if you need to wait a bit, or click again (great fun when the UI jumps 1ms before your re-click), or full reload/restart ... luckily that's not at all what this article recommends!

anonacct37 3y ago

I love and hate this. On a visceral level I don't like dealing with issues via malicious compliance. OTOH I absolutely agree this is a good call if your goal is for more users to be able to run more software on your platform, even if printing is broken.

elwell 3y ago

> With this behavior, when the app tries to print, it will ask the user to select a printer, and show an empty list. I see Microsoft has not learned from 30 years: https://www.reddit.com/r/hacking/comments/djvzd/windows_nt_login_hack_gif/ https://www.reddit.com/r/hacking/comments/djvzd/windows_nt_l...

nonethewiser 3y ago
That os amazing

1970-01-01 3y ago

This is also very good for security. Correctly dismissing an API call means these programs aren't able to go off and do extra naughty things.

leaf8937 3y ago

throw checked exception so that xbox will have to handle the exception. xbox implementation can donothing if they want.

Arwill 3y ago
Sometimes this kind of error handling is the cause of program slowdowns. So the API fails, but the program retries anyway, and so fails again endlessly. The user doesn't see anything from this happening, only that "the app is slow". Windows is plagued by this kind of behaviour. Its both what the article suggests can cause this, but throwing and ignoring exceptions can have this effect too. The goal, IMO, would be to force the app not to try (or not to try once it failed) something that is bound to fail.

leaf8937 3y ago

if possible, throw checked exception which must be handled.

zxcvbnm 3y ago

Wrong, errors should not go unnoticed, let alone helping them to propagate. Cascading effects should be kept on a short leash. System takes one step in the wrong direction, kill it. The two most miserable things are, things not happening and there's no feedback on why, and, the other extreme, when things are overengineered and no one can predict where problems might cascade to.

12_throw_away 3y ago
lord grant me the confidence of someone who reads a thoughtful explanation of a problem and its solution by Raymond Chen and responds with "Wrong, "
- deleted 3y ago
  [deleted]
- B1FF_PSUVM 3y ago
  It's hilarious, Chen has been doing this right - on the bleeping internets for all to see - for thirty years and we've greenhorns going "Nah, mate, you're doing it wrong."
thrwwycbr 3y ago
Maybe you should build an operating system from scratch, keep building it for more than 25 years and then come back to revise your comment?

patapong 3y ago

Hmmm I see and appreciate the idea behind this. That said, it seems confusing for the user to be shown an empty list of printers if no printers can be installed on the platform. In my opinion, it would be preferable to show the user a dialog that says "This platform does not support printing" and, once they dismiss the dialog, inform the program that the user cancelled the print action.

city41 3y ago
I agree, using the empty list to communicate to the user the situation is making an assumption about the user. A lot of users have never set up or dealt with printers ever. I can say for sure that an empty list of printers would confuse a lot of people in my household.

o11c 3y ago

Making it a linker error doesn't even seem to be considered. Xbox is a separate target so a recompile is needed anyway ...

Arainach 3y ago
No, it's not - that's the point of the Universal Windows Platform - compile once, put in store, run everywhere. This also isn't just about new platforms. If you have a desktop operating system and want to change the behavior of an API in a future version, you have to do this same process.

Throw6away 3y ago

Microsoft’s MDM APIs will return a 500 (server error) on a VM if you try to get a list of wireless networks, instead of the saner approach of returning an empty list. The same APIs will return a 418 (I’m a teapot) if you mistakenly try to add an already-existing setting, instead of just updating it as one might expect. They get points for originality, but don’t follow the advice in this article.

yau8edq12i 3y ago
Microsoft has around 238000 employees according to Wikipedia. That they are not all strictly following Raymond Chen's latest blog post isn't surprising.

philipwhiuk 3y ago

I'm sorry but that code sample is an incomprehensible eyesore. And I've written PHP4.

LASR 3y ago
What's crazy is that I didn't even realize it until you pointed it out. I've been doing Win32 for so long it's like reading the green symbols in The Matrix. This all looks "normal" to me.
zerr 3y ago
Besides being unreadable, it is well known that Win32 API code is unwritable. It is only copy/paste-able.
jeroenhd 3y ago
Windows headers like uppercase. They also like very explicit types, as far as the language accepts them, of course. For example, HRESULT really is just a 32 bit integer with special rules (top bits set subsystem that cause the error, bottom bits set error code, hence the conversion function for best practice). Stripping out the Windows types and compile-time validation and the wrappers, and picking non-Windows error codes, you can turn the code into more Unix-like C++: int32_t CreateWidget(int32_t* widget) { *widget = nullptr; return ECANCELED; } int32_t GetWidgetAliases(wchar_t* aliases, uint16_t capacity, uint16_t* actual) { *actual = 0; return EBADF; } int32_t EnableWidget(int32_t widget, bool value) { return EBADF; } int32_t Close(int32_t widget) { return EBADF; } However, this code may not function if you're building for 32-bit Windows and it may not work on every compiler; it just assumes certain bit sizes that the API only guarantees in the form of typedefs.

sirspacey 3y ago

I missing what the magic is here. This seems like a long way to go for “we know that this device is an Xbox and Xbox doesn’t support printing, let’s tell the user” Only it doesn’t tell the user. It leads them down a path implying implementation is possible. On the other hand, I now know why so many issues I’ve troubleshooted on MS products end in tears and complete confusion as to why they wouldn’t just say “this is not a feature you can use on this device.”

filleduchaos 3y ago
> This seems like a long way to go for “we know that this device is an Xbox and Xbox doesn’t support printing, let’s tell the user” You're missing the fact that Xbox can run apps developed for (desktop) Windows, and that the scenario in the article is about the platform <-> end user relationship and does not involve the app developer at all.
- sirspacey 3y ago
  Ok, appreciate the insight. Doesn’t the platform: 1. Know that is a windows app 2. Know that it is Xbox So it could override the “print” request with a user appropriate notification?
comicjk 3y ago
I agree. The author's description of what is "reasonable" sounds like a blueprint for many of my late nights struggling with Windows: "apps that assume that printing works will still behave in a reasonable manner: You’re just on a system that doesn’t have any printers and all attempts to install a printer are ineffective." Maybe the underlying assumption is that the users will give up before spending an "unreasonable" amount of time on these tar pit features.

crooked-v 3y ago

Doing nothing correctly sounds like hard work. I guess I'll try it out sometime later when I have more energy.

denysvitali 3y ago

Wouldn't it be simpler to just create a "Save to PDF" printer and use that in the Xbox? This way the API stays compatibile, and it actually makes it useful

LuciBb 3y ago

[dead]

SillyUsername 3y ago

Exception safety guarantees have been around for decades and were originally defined by David Abrahams who was on the C++ standards board. As the author is a Microsoft employee I'm a little surprised no attribution or reference to the original author of (the levels of) exception safety guarantees which his article partly describes. Raymond Chen (article author) is refering to the "no throw guarantee" in his article as opposed to one of the other outcomes https://en.m.wikipedia.org/wiki/Exception_safety https://en.m.wikipedia.org/wiki/Exception_safety

laserbeam 3y ago

Good: average apps continue to work as expected. Bad: good apps can't know what's supported or not. What's missing from the article is adding a way for apps to detect and handle this behavior. (Using the printer example) There should also be some API that tells me "printing is not supported on this platform" somehow. If I want to be a good software developer I should hide the print button in the UI in a very predictable way. It's great that if I actually try to print nothing happens as expected. It's bad if I can't detect that printing would never work, and I should be able to do that via at least some function call that doesn't magically noop.

josephcsible 3y ago
From the article: > Now, you probably also want to add a function to check whether printing even works at all. Apps can use this function to hide the Print button from their UI if they are running on a system that doesn’t support printing at all.
- laserbeam 3y ago
  Somehow I missed that. Thanks!

cratermoon 3y ago

This is also like Null Object or Special Case pattern. It simplifies error handling, and because error handling code is often poorly tested it ends up being a big source of catastrophic failures. Making illegal states unrepresentable, or as John Ousterhout puts it: define errors out of existence: https://wiki.tcl-lang.org/page/Define+Errors+Out+of+Existence https://wiki.tcl-lang.org/page/Define+Errors+Out+of+Existenc...

armchairhacker 3y ago

Slightly tangential, this reminds me of how to `sleep` in JavaScript without using async: https://stackoverflow.com/a/37575602 https://stackoverflow.com/a/37575602

Wowfunhappy 3y ago

> “I asked for a widget, and you gave me one, and then when I showed it to you, you said, ‘That’s not a widget.’ This API is gaslighting me!” The entire point, it should be noted, is to gaslight the app. But the API must be good enough at gaslighting that the app doesn't discover the lie.

johngossman 3y ago

The point the critics of this piece seem to be missing is that there is not an exceptional case here that needs an error to be thrown. There are NO printers attached to the device (in this case by definition), and an app should cleanly handle that case, not crash. You wouldn’t throw an exception on a laptop just because it couldn’t reach the printer.

PennRobotics 3y ago
If you want a clear, modern example of a popular non-Microsoft product doing printer availability wrong, it's gnome-control-center. Add a printer in Settings. While the printer is installing, click over to the "Color Profiles" tab. If you time it right, gnome-control-center will crash. If you dive into the details, you see that it was trying to enumerate the available printers (it knows one should be there) but that info doesn't exist yet. So it just crashes. Thankfully, the fix is to just wait a few seconds for GNOME to finish installing the printer and restart Settings. Still, it's the principal app responsible for making your desktop work correctly as an end user with some unknown computing background. In a perfect world, this app should never crash. It's hard to think about edge cases. It's even harder to imagine your handling of edge cases has its own edge cases. Right or wrong, at least the author is thinking deeper than "bad app, needs to be rewritten to support Wayland"

evnc 3y ago

From the title alone, I initially thought this would be about meditation.

_Algernon_ 3y ago

The only reason an X-box doesn't support printing is because Microsoft has defined it as such. A x-box is just as capable to print as the Windows machine in the next room over from a hardware perspective. Which means this "solution" to a stupid, self-created problem is stupid. I bet this workflow will lead at least a handful of people to ask "How do I add a printer to my X-box?" instead of "Fuck the app crashed, better not do that again." Microsoft has so much stupid, corporate driven decision making. Can't wait for it to follow in IBM's footsteps.

yungporko 3y ago

"The idea here is to have the printing functions all behave in a manner perfectly consistent with printing being fully supported, yet mysteriously there is never a printer to print to." this is exactly the kind of stupid shit that makes me hate using anything from microsoft. on what planet is this desirable behaviour? is it beyond microsoft's capability to just show a message saying "Printing is not available on Xbox"?

fullstackchris 3y ago

> The idea here is to have the printing functions all behave in a manner perfectly consistent with printing being fully supported, yet mysteriously there is never a printer to print to. What? Why would you ever do this? This post screams of "can't see the forest from the trees" Sure, now you don't have your app crashing, and instead you have this weird state of seeming like you can print but ultimately can't, wasting users time and perhaps frustrating them even more. Why not literally just show a dialog like "printing is not supported from an Xbox"? Easy to develop, easy to understand... everyone wins.

korginator 3y ago

There are widely used practices for API design and versioning that work well today. While this article's kludgy approach to backward compatibility may have been passable a few decades ago, this is a terrible way to approach the problem in 2024, specially with services & APIs being deployed & distributed across platforms. The article illustrates how *not* to build APIs.

akho 3y ago

This starts with an Xbox not being able to print, while being able to run computer applications. The correct solution is not to have that. There is no graceful way to recover otherwise, no matter how "inert" you are.

saagarjha 3y ago

Everyone here is hung up on doing "nothing" and handling "errors" and I feel like the post does a poor job explaining how it is not just swallowing everything that's going wrong and going kumbaya. The actual context is that the author is doing emulation/compatibility for software that will not change, and that's very different from most contexts. This is especially confusing because Microsoft often blurs the line between the two themselves, and that's not actually what is being talked about here at all. Really, emulation is all about telling lies. Your Xbox doesn't actually have a way to attach a printer. You're running a game on Linux, not Windows. Your fake iPhone is actually a ARM server in AWS. The point here is that if you're going to lie you better do so convincingly. That's because you need existing applications to still work! When Microsoft says you can port your existing Windows app to Xbox the promise for the Windows app was that it would be able to print, and so Xbox needs to lie for that to happen. This is very different from a normal error. If a program does a use after free, and you silently pretend the bug doesn't exist by working around it, then you're not doing anything correctly. That's because nobody promises that your existing use after frees will be bug-for-bug compatible on a new platform.

lucianbr 3y ago
> There may be times where you need to make an API do nothing. It’s important to have it do nothing in the correct way. > For example, Windows has an extensive printing infrastructure. But that infrastructure does not exist on Xbox. What should happen if an app tries to print on an Xbox? It says nowhere that the context is doing emulation for software that will not change. You just assume that because it supports the position you like. In fact, everything written applies to a program that I might write tomorrow for an XBox, and try to print something. There is nothing that designates this behavior only for old, unmaintained software.
- buttercraft 3y ago
  If you write a program tomorrow, use the API correctly and this issue will not apply to you. This is for apps that aren't well written and don't check for the capabilities ahead of time.

sporkland 3y ago

I wish the concept of dev mode and prod mode were baked deeper into all language runtimes/libraries. e.g. before going to production with real users these cases should error as hard as possible, including potentially logging crashing the program to make the program errors super visible. Then in production it should largely log these things in error logs and keep chugging along. And not like an environment variable with conditions. Something as first class as changing the standard exception and fatal calls behaviors.

mrcsharp 3y ago

What a weird thread of comments this was. There are clearly people who just don't like anything Microsoft does. The point of the blog is to make the process of bringing apps (UWP) to XBOX be frictionless: no recompile required, no messy ifdefs, none of that extra work. The App would "just work". Then, it's up to the developers to start adjusting the app to fit the XBOX platform more. The important thing here is that the developer was able to bring the app with no effort to XBOX. This is good for both the platform and the developer. To the user, it's a clear signal that they can't print since the list of printers are empty. But most importantly for them, the app did not crash or show the most hated error: "oops something went wrong. Try again later." Is that message a better experience for the user? No. Sure, the developers can recompile the app and add a more descriptive message but then we're back to square one.

PH95VuimJjqBqy 3y ago
I honestly feel like 95% of the people in this thread didn't understand the article. for example, accusations of swallowing errors. That's not the point, not at all.

empuxr 3y ago

As a Platform Engineer who has to work with Azure on a daily basis, I am so tired of their APIs and services making exceptions left and right, sometimes for their own shitty clients. The result is a Patchwork product suite, services never work as expected but deviate from their documentation (or rather what they are claiming is their documentation). The Daily Azure shit Mastodon account has more than enough examples of this. For example https://azsh.it/167 https://azsh.it/167 or https://azsh.it/107 https://azsh.it/107 This article made me realize while Azure is the way it is - unreliable and broken.

RhondaAyala 3y ago

[dead]