[HN Gopher] If you're just going to sit there doing nothing, at ...
___________________________________________________________________
If you're just going to sit there doing nothing, at least do
nothing correctly
Author : AndrewDucker
Score : 143 points
Date : 2024-02-16 19:11 UTC (3 hours ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| tsimionescu wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Analemma_ wrote:
| 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 wrote:
| 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_ wrote:
| 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 wrote:
| 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.
| acheron wrote:
| To be fair, sometimes you get "Oops, an error occurred, LOL!"
| FreeFull wrote:
| As far as alternatives to what the article suggested go, I
| think the ideal solution would be to have a compile-time error,
| so the developers never even get as far as having their
| printing code try to run on the Xbox. And since it's a compile-
| time error, there doesn't need to be any kind of runtime error
| handling or cost either.
| paxys wrote:
| Except now you have lost the ability to run all the software
| that cannot be fixed and recompiled for whatever reason.
| FreeFull wrote:
| You could still offer the mocked APIs, but have them be
| opt-in. Also, having the compiler throw an error doesn't
| mean that an older, already compiled executable won't work.
| jonas21 wrote:
| > _Also, having the compiler throw an error doesn 't mean
| that an older, already compiled executable won't work._
|
| And when the older, already compiled executable calls the
| API, how do you make things "work"? That's exactly what
| the article is about.
| Arainach wrote:
| Apps aren't being compiled here. Apps already exist and new
| platforms and platform functionalities are being made
| available.
|
| Launching platforms is an eternal chicken and egg problem:
| You want to launch a new platform. Users want apps before
| they buy into the platform. Developers want users and a
| guarantee they will spend money before investing time and
| money building apps for the platform. If you're really really
| rich, you can literally pay developers to write apps for you,
| but ask Microsoft how that went with Windows Phone.
|
| Instead, the most reliable way (I said _most_ reliable, not
| reliable) is to leverage an existing group of apps onto your
| platform. Maybe you have a phone ecosystem and want to get
| into tablets. So you take the already existing phone apps in
| your store and let them run on your new platform.
|
| There is no recompiling. There is no build.
|
| There is no "build" because the source code was lost when all
| of the company's assets were sold off in 2002.
|
| There is no "build" because the developer made a game, put it
| on your app store, moved on to the next game and has no
| interest in supporting this game that isn't providing any
| significant new revenue.
|
| There is no "build" because this is FooManager 6.0, the
| company that makes FooManger wants everyone to buy FooManager
| 7.0 and isn't making any further changes to 6.0.
|
| etc. etc. etc.
|
| Binary compatibility is what matters. Nothing else is of
| particular significance.
|
| In addition, if recompiling an app for your new platform
| yields compile errors and requires work (as opposed to
| targeting a new platform version in a manifest and just
| hitting build), developers on your platform are significantly
| less likely to spend the time to do so.
| notatoad wrote:
| as the article says, the correct solution is to provide an API
| that applications can access to check if the functionality is
| offered at all.
|
| functions that return correct null responses isn't the ideal
| behaviour, it's the fallback for when you're already off the
| happy path.
| mike_hock wrote:
| So what's your solution then? Break all apps simultaneously
| that _do not_ have extensive tests for gracefully handling
| cases that were impossible when they were created?
|
| This is not weird "hidden state" on the implementer's side.
| It's a straightforward dummy API and all you need to do to test
| it are a few straightforward asserts that it returns the
| correct dummy values and doesn't crash.
|
| > 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.
|
| That's precisely _not_ what this is. The whole point of the
| article is to do nothing _correctly._ Presenting an empty list
| of printers is consistent with a PC that simply doesn 't have
| any printers installed. A wrong thing to do would be, for
| example, presenting a dummy printer that accepts jobs but of
| course never prints anything.
|
| You don't break the users of your API, period. That shouldn't
| be controversial. Unfortunately, too many people seem to think
| they need to do everything over every couple of years only to
| produce a solution that is no more extensible and resistant to
| bitrot than the one they're replacing.
| chrisjj wrote:
| > So what's your solution then? Break all apps simultaneously
| that do not have extensive tests
|
| No test required. Just try... catch.
|
| > for gracefully handling cases that were impossible when
| they were created?
|
| You can never know they are impossible. That is why you have
| a top-level try...catch.
| Jabrov wrote:
| "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 wrote:
| The alternative is that the app fails to run at all. Doesn't
| seem like satire to me.
| GMoromisato wrote:
| Or worse, crashes at a random spot because it tried to
| initialize the printer stack.
| bombcar wrote:
| 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.
| kentonv wrote:
| 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.
| avery17 wrote:
| What do you suggest as an alternative?
| daveoc64 wrote:
| 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?
| chrisjj wrote:
| But the first option is not "this app can't run on your
| Xbox". It is "This app possibly cannot run after trying to
| print".
| elevatedastalt wrote:
| No it's not satire. It's a demonstration of the excellence in
| backward compatibility and cross-compatibility that Microsoft
| has always been known for, and that so-called modern players
| like Google and Apple don't take seriously.
|
| Just because an XBox can't print doesn't mean that an app that
| prints shouldn't run on XBox. It should just mean that the
| printing function shouldn't run. How to achieve that is exactly
| what Raymond Chen, a Microsoft and Windows veteran, is trying
| to explain here.
| toss1 wrote:
| Perhaps you missed the context in which it was made clear that
| this imperfect solution was still less bad than all other
| options.
|
| It seems the point resembled: 'this device doesn't support
| printing, don't return obscure, unhelpful or crashing errors;
| return something that makes sense so that the user can figure
| out and move on'. I.e.: Fail gracefully.
| Contortion wrote:
| I wouldn't call creating mystery failing gracefully. As a
| user I would prefer a full crash to the application gas
| lighting me by suggesting there's something wrong with my
| setup (we can't find your printer vs you're not allowed to
| print).
|
| If anything creating mystery about what the app is doing is
| the direct opposite of good UX.
| xp84 wrote:
| User spends two hours creating content. User hits print.
|
| 1. App crashes back to the desktop/Home Screen/etc
|
| 2. App can't find any printers. User cancels and saves the
| document, prints elsewhere.
|
| You really think option 1 is better?
|
| Also, none of this precludes the ability to display a
| message. He's talking about the system calls themselves and
| how they should respond. I suppose if the call for the "Add
| Printer Wizard" is called, it could not only return the
| "user cancelled it" status but also display an error
| message. It depends on the implementation details and
| whether someone probably 20 years ago foresaw the need for
| a modal but not fatal system error message to be triggered
| by that API call. Which again is not in the today
| developer's control.
| chrisjj wrote:
| > 1. App crashes back to the desktop/Home Screen/etc
|
| Why do think it would crash, rather that simply return to
| main loop?
| chrisjj wrote:
| > I.e.: Fail gracefully.
|
| There's no grace in misleading the user and wasting his time.
| alpaca128 wrote:
| MS being okay with the user clicking somewhere and never
| getting any reaction out of it explains _many_ of my
| interactions with Windows 10.
| bastawhiz wrote:
| So what, you crash the app? What if there's no API to say
| "there's no printing on this device"? What is the difference
| between a device where printing isn't supported and a device
| where a printer isn't set up yet? Showing an empty list of
| printers isn't a bad solution, frankly.
| Jabrov wrote:
| Ahh I completely misunderstood the article from a quick
| reading. It seems like the only solution to a tricky problem.
|
| Thanks to anyone who replied to me pointing that out. It's a
| good example of when one should read the article more closely
| before commenting!
| lucianbr wrote:
| 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 wrote:
| "We" did. Microsoft didn't. Not unexpected.
| recursive wrote:
| Is this part of a fan fiction where MS isn't amazing at
| legacy compatibility?
| Peter0x44 wrote:
| I think their BC is overrated. Wine manages to do a better
| job.
| subarctic wrote:
| What did you think we learned?
| lucianbr wrote:
| 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-
| 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.
| eastbound wrote:
| In 2024, so we still have websites that are served
| differently depending on the User Agent?
|
| Could we possibly do away with the User-Agent header, or
| reset it to a simple "Chrome 150.01"?
| xp84 wrote:
| Meh. For all the silliness, it's not that hard to parse
| one for the main purpose it should be used for, which is
| determining in aggregate what platforms your users use.
| As such, we still need things like OS in there anyway. So
| it wouldn't get quite that short.
|
| Also I'm amused checking mine that the user agents still
| say "Intel Mac OS X" even on Apple silicon. I guess they
| were afraid someone's parser would think we are on
| PowerPC without that!
| kentonv wrote:
| Browsers still follow that strategy. The effort to replace it
| with strict validation (XHTML) failed. What succeeded instead
| was HTML5, which went back and explicitly defined how every
| possible invalid sequence should be interpreted, so that
| browsers would at least be consistent about it.
| fidrelity wrote:
| 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.
| Arainach wrote:
| 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 wrote:
| 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).
| gruez wrote:
| >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?
| nearbuy wrote:
| 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.
| throwawayfrsbob wrote:
| And they ask why we're cynical. I'm about done with this whole
| "personal computing" fad.
| paxys wrote:
| 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.
| dupertrooper wrote:
| Umm but you can't find a current version of Word that actually
| does that. Try it sometime.
| EvanAnderson wrote:
| Here's a rather large (5MB) vintage 1996 Microsoft Word
| document: 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 wrote:
| The point made above was _" opens exactly as expected"_.
| So, does it look like the authors intended in 1996? I doubt
| it.
| Arainach wrote:
| If you "doubt" it, please provide a specific example of
| what you believe is inaccurate in the document rendering.
| morsch wrote:
| As it happens, we just had this discussion regarding a
| Word document from 1990:
| https://news.ycombinator.com/item?id=39357709
| EvanAnderson wrote:
| Just flipping thru it I'm not seeing obvious issues. In
| terms of being usable for reference I think it's
| reasonable. The diagrams and tables look intelligible and
| not garbled. Layout isn't visible screwed-up.
|
| Will it be a 1-to-1 with printed output from 1996?
| Probably not.
| MichaelZuo wrote:
| "exactly as expected" is a much higher bar to clear then
| roughly as expected.
| judge2020 wrote:
| Was able to do it just fine with these government files[0,1]
| I found on Google. Word version 16.82 on Mac (Apple Silicon
| too).
|
| 0: https://www.legis.state.pa.us/cfdocs/Legis/LI/uconsCheck.c
| fm....
|
| 1: https://archive.ada.gov/briefs/andersbr.doc
| weinzierl wrote:
| The point made above was _" opens exactly as expected"_.
| So, does it look like the authors intended in 1996? I doubt
| it.
| weinzierl wrote:
| A file that was written in Word '97 did not even open exactly
| as expected on two different computers 25 years ago. Formatting
| depended on the installed printer drivers. Good luck with that
| document today.
|
| My LaTeX files from 35 years ago, on the other hand - they just
| do fine.
| gruez wrote:
| >My LaTeX files from 35 years ago, on the other hand - they
| just do fine.
|
| Yeah, because they're plain text. A fairer comparison would
| be whether they render pixel perfectly as 35 years ago, which
| I doubt.
| bombcar wrote:
| If you compile them to DVI you'll get the same DVI file.
|
| Compiled to PDF you might get very slight differences.
| gruez wrote:
| >the same DVI file.
|
| Which is used by approximately no one. Good luck
| uploading your resume in DVI.
| mnw21cam wrote:
| Good luck uploading your CV in PDF. I tried that a few
| times and got moaned at a load that my CV _must_ be in
| Word format. In the end I converted the PDF into images,
| and created a Word document in OpenOffice (this was a
| _while_ ago) with one page image per page. Got moaned at
| for that too.
| derefr wrote:
| The only reason they want your resume at all is to run a
| keyword extractor over it. If you know this, why are you
| making their job harder?
| ahazred8ta wrote:
| Heh. A buddy of mine once applied for a Linux job and
| sent his resume as a PDF. They called him back: "OMG,
| you're the only applicant who didn't send a Word file.
| _We 're not worthy._"
| mnw21cam wrote:
| If you're rendering to DVI, it's explicitly defined as a
| bug if it doesn't compile to exactly the same pixel-
| perfect output as a previous version.
| wrs wrote:
| If I recall correctly, the common phenomenon where you open a
| Word document, immediately close it, and are asked whether
| you want to save your changes (???) has something to do with
| printer settings.
| wewtyflakes wrote:
| I hear that refrain often regarding Microsoft, but with games,
| I have not had good luck. I resort to using GOG, which itself
| ends up virtualizing the environment anyway. For example, I do
| not think anyone would have success installing the original Sim
| City on Windows 11.
| awkwardpotato wrote:
| Fallout 3 was unplayable (without mods/patches) on Windows 10
| for _many_ years because of its dependency on "Games for
| Windows Live" from Windows 7
| benjaminpv wrote:
| Yeah, people frequently trot out the Sim City classic
| example, but the fact is that games in particular have borne
| the brunt of Windows API changes. If it didn't happen we'd
| have no need for wrappers like dgVoodoo: software once only
| meant to wrap Glide calls, but now used to get around
| deprecation to DirectX as well. Not to mention the breaking
| changes to the audio stack that happened between 9x and
| Vista.
| alpaca128 wrote:
| A file from 1997? Maybe if you get lucky, but there's also a
| good chance that it will simply look wrong in any office
| application you try. With Word you can't even guarantee that
| reopening the file on the same computer & version won't change
| its formatting. That was the reason I learned TeX.
|
| And games? Microsoft broke numerous games by shutting down
| GFWL. I had to pirate Dark Souls as my original copy wasn't
| playable until it got re-released on Steam.
| gruez wrote:
| >With Word you can't even guarantee that reopening the file
| on the same computer & version won't change its formatting.
|
| Source? This seems utterly bizarre.
| benjaminpv wrote:
| I don't know if anything's changed but for a long time a
| lot of Word's formatting was impacted by the printer you
| had installed and/or selected. So it was pretty easy to run
| into scenarios on a network where printers being taken
| offline/their capabilities changed resulted in documents
| getting reformatted.
| alpaca128 wrote:
| Difficult to prove considering that was a decade ago, but
| it did happen to me. Randomly changed font in a random
| paragraph, randomly repositioned images, etc. Maybe I
| accidentally broke the document in some way, I don't know,
| but Word certainly failed to restore it to the exact state
| it was saved in, and it was always on the same PC and
| software.
| apetresc wrote:
| Before the new '.docx`, '.xslx', etc. formats, when it was
| still just .doc, .xsl, etc., the document format was (as
| I've heard it told) essentially just a memory dump of
| Word/Excel's state for that document at the time you saved.
| And since it's easy to imagine that
| serializing/deserializing such a complex thing might not be
| always 100% perfectly idempotent, it would indeed happen
| that just the act of opening a file would change it in some
| subtle way.
|
| That hasn't been the case in a long time, though.
| repler wrote:
| the new formats are actually zip archives believe it or
| not
| mnw21cam wrote:
| I had the same with OpenOffice (before LibreOffice was a
| thing). I created a nice document while logged in remotely to
| a Linux computer over Xvnc. When I opened it on the native
| terminal, the layout was different. Same computer, same
| version of OpenOffice, different X server.
| bakugo wrote:
| I assume the negative reactions are due to the large Apple user
| base on HN. Most of these people are likely so used to being
| told "this software was built for a version of your OS released
| 2 years ago so you can't use it anymore, tough shit", they've
| come to expect it.
| pas wrote:
| nah, it's because all of this is just lip service. windows11
| is getting worse and worse.
|
| and cool that Mr Chen thinks about UX and compatibility, but
| MS as whole does not really. important business apps got
| special treatment, and that's it. (MS and its corporate
| entourage solved this mostly by providing Windows and
| "security" patches for it, for a lot of money.)
| spiderice wrote:
| You just created a scenario in your head that confirmed an
| existing bias in your head and then assumed that your made up
| scenario matched reality. Very weird to read.
| blibble wrote:
| 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"
| Waterluvian wrote:
| I wish this was actually truthful. I've had a gigantic headache
| getting every childhood game I kept working. In almost every
| case I gave up or re-bought from GOG, basically paying for the
| work done to sort out compatibility.
| hailmac wrote:
| Why /wouldn't/ I want to print something from my Xbox?
| daveoc64 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| kbolino wrote:
| You go to print a document. Your printer is temporarily
| unavailable. The print job hits the spooler and sits in a
| queue. You get bored and launch a game. The printer becomes
| available. The print driver has to convert the job to PCL
| or whatever proprietary format the printer uses. Your game
| hangs or even worse crashes because it's not really
| designed to run with background tasks on the same cores.
|
| Who do you blame, especially since the usual diagnostic
| tools of a PC with a full operating system aren't
| available?
|
| It's a feature very few people will use with lots of sharp
| edges that people accept on a PC but would find intolerable
| on a video game console.
| Arainach wrote:
| It's not running "most of Windows". In particular, as far
| as I know (no insider knowledge), it's not running any of
| the Win32 APIs (USER, etc.). So that rules out any printers
| which require coordination with their desktop app (which,
| to be honest, to get full functionality is still a
| shockingly high number of them). It's highly unlikely the
| XBox hypervisor implements _any_ of the printing APIs, even
| UWP because this is a video game console, and not only does
| almost no one own a networked printer, an even smaller
| group of essentially no one has a printer, opens documents
| on their video game console, and wants to print them.
|
| Features aren't free. What Xbox feature would you drop to
| have an engineer go implement printing APIs on them? Is
| that the best use of their time?
| happytoexplain wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| No, not a shitty client, just one that was written before you
| decided to make this change. If your API breaks it while it
| doesn't change, it's the API that's being shitty, not the
| client.
| codexb wrote:
| It depends. Did the API document that it could raise an
| exception if printing isn't supported? Is that unhandled in
| the client? Then yes, it's a shitty client.
|
| If you're talking about making backwards-incompatible
| breaking changes to an API, that's another thing.
| derefr wrote:
| In the context of the article, no, the existing API never
| threw (or was documented as capable of throwing)
| NotSupportedException.
|
| The article:
|
| > The app that the user installed on the Xbox was probably
| tested primarily, if not exclusively, on a PC, where
| printing is always available.
|
| I.e. there is no concept in the (desktop) Windows printing
| subsystem of printing _as a feature_ not being available;
| on desktop Windows, printing _as a feature_ is available by
| definition.
| TillE wrote:
| The mention of NotSupportedException is a little
| confusing because that's a .NET thing, and the rest of
| the article is talking about Win32, which is a plain old
| C API where exceptions don't exist. I guess he's
| implicitly talking about a C# API built on top of Win32.
|
| It's entirely correct to return error codes, and any
| client is expected to handle that.
| derefr wrote:
| Clients are _not_ expected /required, however, to behave
| correctly in the face of _unknown_ error codes that did
| not exist or have defined semantics at SDK-version-
| selection time.
|
| Actual exceptions -- in languages that have them -- are a
| bit different, in that they "do" something by default:
| they propagate and unwind unless they're caught. And so,
| new (unchecked, if in a language where that's relevant)
| exceptions can be introduced after the fact under the
| presumption that the runtime's default behavior for
| propagating unknown exceptions will kick in, and that
| this will trigger the desired result for applications
| that weren't written in awareness of that particular
| exception.
|
| Error codes aren't like that; they have no default
| semantics as a class, only explicit default semantics per
| function and/or per algebraic error-code type, if-and-
| where documented as such. New error codes simply aren't
| meant to be introduced in most APIs, unless those APIs
| have rules about e.g. generalized default handling for
| defined code ranges that new codes can be later slotted
| into.
|
| Basically, error codes are weak enums. If you're writing
| a dynamic-link library (or a runtime -- same thing,
| basically), you're not supposed to add new potential
| values to an enum used as a return value: client code
| will likely have been written to switch on the value with
| the known options as cases, and your new value won't be
| in there.
| ryandrake wrote:
| I think this is the critical piece that should determine
| how you handle the error. If the API, as used by the
| client, when the client was programmed, was expected to
| potentially throw NotSupportedException or return an
| error code, then doing so sounds like the right way to
| go. Throwing/erroring is part of the API contract and the
| client should handle NotSupportedException.
|
| If the API was never expected to throw
| NotSupportedException or return an error code, then all
| of a sudden starting to throw in a future release breaks
| the API contract, and the client cannot be expected to
| handle it sensibly.
|
| EDIT: Duh! My comment is useless. This was the exact
| conclusion that the article came to, too. So instead of
| reading this comment chain, just finish the article :)
| Aaargh20318 wrote:
| > No, not a shitty client, just one that was written before
| you decided to make this change.
|
| Has the Xbox ever supported printing? Why even have these
| APIs? Just don't offer them at all in the Xbox SDK. You
| shouldn't be able to compile code that tries to call these
| when targeting Xbox.
| skykooler wrote:
| It's an API that also targets Windows. Apps that use it can
| run on both platforms.
| Arainach wrote:
| The "shitty client" was written long ago by a company that is
| out of business. YOUR customers rely on that client, and if it
| stops working because of a change you made they will blame you.
| kentonv wrote:
| If you are building a software platform which has been adopted
| by more than a handful of developers then you're going to have
| some shitty apps, in which case you have to do this stuff. Yes,
| it is completely normal and generalizable to all platforms that
| have wide adoption and take backwards compatibility at all
| seriously.
|
| Raymond is behind arguably the foremost exemplar of this
| (Windows) but the same thing happens in the Linux kernel ABI,
| glibc, the web platform, Java, and so on.
| bitwize wrote:
| > No, no, absolutely no - what the author is describing is a
| hack to support a shitty client.
|
| If you were on the Windows team and I was your manager, I might
| fire you for that.
|
| This is Windows. You do not break applications that users
| depend on. Ever, ever, ever. If you have a "shitty" or
| misbehaving client application, you use whatever workarounds,
| shims, and compatibility hacks it takes to make the application
| work as expected. Even if it means having special memory
| management code for SimCity so it will work.
| lhamil64 wrote:
| I also took issue with the Xbox example, and I think it's a
| context issue. When I read it, I interpreted it as an API for
| new apps/games to use. In that case, they should be testing
| on an actual Xbox before shipping! And why would the app be
| trying to print in the first place if it's designed to run on
| an Xbox?
|
| But I suspect the situation this is being designed for is
| existing PC apps being ported to an Xbox. OK, in that case I
| can see fudging the API since there might be obscure corners
| that the devs didn't think about that try to print. But I'd
| still say the devs should be testing on an Xbox and make an
| effort not to attempt to do things when it doesn't make sense
| for the platform.
| xp84 wrote:
| I really appreciate this approach. It actually takes, in my
| humble opinion, much more discipline (and requires checking
| ego at the door) to implement this idea, compared to the "my
| code just throws exceptions or a 400 Bad Request anytime you
| aren't following the most recent revision of our API"
| mindset. I work on Web apps which are much closer to that
| second approach usually, but if I were working on a platform
| (NT) which was 30 years old and will live another 30 years in
| all likelihood, you 100% have to take the approaches Raymond
| Chen is explaining.
|
| "We've decided software that operates your 100 ten-million-
| dollar-each CNC machines is 'shitty,' so buy new equipment so
| you can get Windows 11" isn't going to fly, it would get the
| whole company laughed out of the room.
|
| Especially because what is allegedly making them shitty would
| just be someone's failure to predict some minor detail about
| the future of the platform. APIs do have to change, and the
| creative part is thinking of how they can be safely rendered
| inoperable without damaging anything that didn't predict that
| removal. Sure, you can't print, but that's in this example a
| deliberate design decision of the platform, probably for good
| reasons.
| orange_fritter wrote:
| > The way they've worded this betrays the internalization of
| their suffering as a MS developer.
|
| While I feel less strongly about this Xbox/printing example, I
| remember Bill Gates saying "I reboot my computer every day"
| which is a similar mindset-- this culture has been forced to
| adopt a certain form of "hygiene" due to that same culture NOT
| adopting hygiene preemptively when they built their systems.
| ofslidingfeet wrote:
| This mindset is even less ethical than it seems, and I'm not
| surprised to see it present at microsoft.
| Arainach wrote:
| What do you mean by "ethical" here, and why is it unethical to
| preserve ABI compatability?
| chrisjj wrote:
| > why is it unethical to preserve ABI compatability?
|
| Straw man. What's unethical here is deceiving the user.
| forrestthewoods wrote:
| > 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 wrote:
| > 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 wrote:
| 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.
| marshray wrote:
| > 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.
|
| Every nontrivial function can fail (in C even a unary operation
| on an int), it's just a question of whether and how the caller
| is informed, how easily the failure is to ignore and continue
| processing in an undefined corrupted state, and what percentage
| of the code ends up being dead branches for impossible-but-
| unprovable error paths.
|
| > I so desperately wish that C++ had Rust's Result type and
| pattern matching.
|
| I'm a fan of Rust too, but what do you think panic() is?
|
| Rust has no concept of code that always succeeds. It's all-but
| impossible on current CPUs.
|
| https://github.com/search?q=repo%3Arust-lang%2Frust+path%3A%...
|
| https://doc.rust-lang.org/std/result/enum.Result.html#method...
| thimp wrote:
| 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 wrote:
| 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 wrote:
| Wouldn't that be part of Apple's app reviews?
| Arainach wrote:
| 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.
| gruez wrote:
| Only if you try to publish it as an iPad app. See also:
| https://hacknicity.medium.com/how-iphone-only-apps-appear-
| on...
| chrisjj wrote:
| > Surely a crappy iPhone app running on iPad is better than
| no app at all?
|
| Bogus comparison. Non-crappy apps are a thing.
| Arainach wrote:
| When you have a platform, apps aren't always being rebuilt for
| it.
|
| There is no "build" because the source code was lost when all
| of the company's assets were sold off in 2002.
|
| There is no "build" because the developer made a game, put it
| on your app store, moved on to the next game and has no
| interest in supporting this game that isn't providing any
| significant new revenue.
|
| There is no "build" because this is FooManager 6.0, the company
| that makes FooManger wants everyone to buy FooManager 7.0 and
| isn't making any further changes to 6.0.
|
| etc. etc. etc.
| nearbuy wrote:
| It's an option, but it has its own downsides. It's a cross-
| platform API.
|
| Someone wants to show some guests some of their photos and
| videos on their TV through their Xbox. Unfortunately they can't
| because their app (eg Samsung Gallery or iCloud or whatever)
| included a print button somewhere.
|
| And with these inert functions, if Microsoft one day adds
| printing support to the Xbox, it'll just work in the photo app
| without any update.
| mminer237 wrote:
| Because then you're making every developer make a special build
| for every device. Most developers aren't going to care enough
| to make a dedicated Xbox or tablet build. You're just going to
| make the platform completely dead. It would be much better if
| all pre-existing apps could mostly run on them.
| iamtedd wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| >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 wrote:
| 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!
| amelius wrote:
| Maybe then raise an assertion error, which only has an effect
| in development mode.
| Arainach wrote:
| Nothing is being compiled here; your customers aren't
| running debug builds of their apps, and the API code is
| part of the platform and isn't running the debug bits.
| ryandrake wrote:
| Even as an end user, I hate when my computer seems to be
| trying to hide something from me. Even if I can't do anything
| about it, I want to know it's happening. Don't worry,
| Microsoft. I'm a grown-up and can handle the bad news. If I'm
| a layman, maybe I just dismiss the dialog and try again. But
| if I'm a little more of a power user, maybe I'll look up the
| error message and see if I can start diagnosing or helping.
|
| If you swallow the error message, I'll have zero idea that
| something is even going wrong! And almost just as bad: if you
| put up one of those useless infantilizing "oopsie doopsie
| computer made a poopsie" error messages, I still won't know
| what went wrong AND I'm being treated like a moron.
|
| I worked for a software company once where our software
| basically crashed every 2-3 hours of continuous use due to a
| huge backlog of technical debt, memory leaks, and years of
| rushing. My manager's solution to this was not to fix the
| bugs--it was to build a separate "launcher" process that
| would detect that the application crashed, eat the error
| messages, and silently re-launch it hoping the user doesn't
| notice. Way to treat your users with respect...
| Arainach wrote:
| There is no error message here - more often than not it's a
| straight up crash. No HRESULT, no popup, just
| NullPointerException, straight to jail.
|
| In many cases like this, crashes like this are in app
| startup, so it's not like you learn not to hit a certain
| button - it's just that the app doesn't work, an awful UX.
|
| As called out in the article, there are (and always should
| be) APIs like "IsPrintingEnabled" so that forward-thinking
| apps can show better UX. These practices aren't for those
| apps, they're for everyone else.
|
| Also, if your app preserves state well enough that a keep-
| alive daemon can restore after a crash and the user doesn't
| notice, that is ABSOLUTELY an improvement in UX over just
| crashing. Sure, you should still fix the bugs, but don't
| let perfect be the enemy of good.
| pjerem wrote:
| I'm sorry, maybe the article used the wrong example but the
| main issue comes from the fact that an Xbox app is trying to
| print something. It should fail, not for the developer
| experience, but because to start, there is no way the user
| would want to print something on an Xbox. Something is
| already really wrong with your app if it tries to do things
| like this.
|
| Also he says that apps are developed and tested on PCs and
| that they could print in this context. I don't know a single
| thing about Xbox development but I hope you can run/debug
| them in the Xbox environment (or a simulation).
|
| Let me hope that nobody is running their Xbox apps/games on
| Windows APIs at development time and releases them on Xbox
| without further testing.
| jacobgkau wrote:
| The point is that the UWP allows running apps developed and
| tested on PCs on an Xbox. It's for the user's convenience
| (not having to wait on developers to port to Xbox) as much
| as the developer's (not having to port to Xbox).
|
| If a user wants to run an app on their Xbox, telling them
| "no, the developer didn't test this on the Xbox, so I'm not
| going to let you do that because you might try to print and
| get confused about it" isn't what the user wants to hear.
|
| When the app tries to print because the developer was
| "lazy" and didn't test on Xbox, telling them "I'm going to
| crash your app now because you clicked Print, even though I
| know you're on an Xbox and I could just ignore that" also
| isn't helpful to the user.
| thfuran wrote:
| That is a dangerous assumption. Unless you know a great deal
| about every possible use case, you can't know the potential
| ramifications of incorrect output. Proceeding from invalid
| state (which would often be the result of swallowing errors)
| is essentially undefined behavior.
| Arainach wrote:
| This isn't invalid state. They're not telling the app about
| a fake corrupt printer, they are using the API contact to
| represent the truth (there is no printer you can use) in a
| way the app already has to support
| mey wrote:
| Error design depends on context. For most of the systems I work
| on, fail fast on request for anything out of spec is the
| correct design. B2B/Microservices/API focused systems. Windows
| however has focused on bending over backwards to provide
| compatibility (including memory patching popular software that
| was broken, like Simcity
| https://arstechnica.com/gadgets/2022/10/windows-95-went-the-...
| ). In the context of a user desktop where a user has no control
| of correcting the system code, the final experience is more
| important that correctness in many cases. It doesn't matter who
| is "in the wrong". Microsoft learned that it doesn't matter why
| the BSOD occurred, just that bad software/hardware was giving
| them the bad reputation.
|
| So yeah, fail fast/halt catch fire on any invalid
| input/condition is my personal preferred design, but I can see
| the value in this approach in this environmental context. The
| important thing here is that context and not applying either
| dogmatically. Don't take Mr Chen's approach in reactor or HFT
| designs for example. Fantastic approach for game engines.
| PaulHoule wrote:
| It's hard to overstate how hard Microsoft has worked to
| maintain backwards compatibility.
|
| Recently I had to read an old Access file and where I work we
| still keep Office '97 around for this purpose and it is quite
| amazing that it installs and works just fine on Win 11,
| Clippy works just fine, in fact all the other lame-ass things
| Office '97 does to take over your desktop all still work even
| if they don't quite visually match the current desktop.
|
| The thing is that Microsoft has a framework built into
| Windows where they can specify different system behaviors
| such as that Simcity case where the game didn't work with a
| new memory allocator so they put in a flag so an application
| that needs it can get the old memory allocator. They have a
| very systematic approach to the half-baked and haphazard
| process of patching the OS so you don't have to patch
| applications.
| MichaelZuo wrote:
| It's close to common sense, end users don't care which
| monkey(s) threw in the wrench if they encounter an error,
| just that some entity did.
|
| The only caveats I can think of are that it must
| prominently display that it's running in a "compatibility
| mode" and that any encrypted subsystems can't revert to a
| lower standard of encryption, which may render the
| application unusable anyways depending on how tightly
| integrated it is.
| elevatedastalt wrote:
| It's hard to overstate*
| PaulHoule wrote:
| Fixed
| delta_p_delta_x wrote:
| > It's hard to overstate how hard Microsoft has worked to
| maintain backwards compatibility.
|
| Here's a pretty detailed list:
|
| - It is possible to target Windows XP SP3 (released 2008,
| EOL 2014, 10 years ago) from Windows 11 and Visual Studio
| 2022[1] using C++23. Windows 2000 can be targeted with a
| little more setup[2].
|
| - It is possible to run a binary written for and compiled
| in Windows NT 3.1 x86 on a modern 2024 Intel/AMD PC running
| Windows 11 with absolutely no modifications to said binary
| whatsoever. Windows NT 3.1 is 31 years old this year.
|
| - It is possible to write one binary and target multiple
| versions of Windows by simply choosing a Platform Toolset,
| which is paired with a Visual C/C++ Redistributable.
|
| - Windows has a run-as mode to run programs in what is
| essentially a super-thin VM; like you mentioned, emulating
| different iterations' behaviour for a given program.
|
| All four of this is nearly impossible on Linux. The fourth
| is essentially Docker, which is needed even to _target_ an
| older glibc (i.e. the equivalent of the first situation). I
| find this both sad and a bit hilarious.
|
| [1]: https://learn.microsoft.com/en-
| sg/cpp/build/configuring-prog...
|
| [2]: https://building.enlyze.com/posts/modern-visual-
| studio-meets...
| greatgib wrote:
| This is the Microsoft way to do things, this is why their
| products like Windows are so crappy, full of bugs, unexpected
| behaviors and a big dump of shit of legacy behaviors expected
| on top of a lot other legacy behaviors on top of another 1989
| legacy behavior that every forgot.
| vikingerik wrote:
| Much of the crappy legacy behavior that Microsoft maintains
| is the fault of other applications, not themselves.
|
| The classic one is the error code for the file open function.
| Early DOS would return error codes of only 3, 4, 5, and no
| more. DOS programs would actually just indirect-jump using
| the error number as an index into a lookup table of
| addresses. When Microsoft tried to add any error codes (say
| 6), the program would jump out into hyperspace since 6 was
| beyond that lookup table and that memory word could be
| anything. So Microsoft was stuck folding every possible file
| open error into code 5, and to this day that's why just about
| any file error in Windows just says "5 Access Denied". And
| no, Microsoft couldn't add more error codes and just let the
| applications break, since then nobody would buy the new
| operating system versions that their programs wouldn't work
| on.
| gruez wrote:
| > When Microsoft tried to add any error codes (say 6), the
| program would jump out into hyperspace since 6 was beyond
| that lookup table and that memory word could be anything.
| So Microsoft was stuck folding every possible file open
| error into code 5, and to this day that's why just about
| any file error in Windows just says "5 Access Denied". And
| no, Microsoft couldn't add more error codes and just let
| the applications break, since then nobody would buy the new
| operating system versions that their programs wouldn't work
| on.
|
| This doesn't pass the sniff test because
|
| 1. There's documented error codes that go all the way up to
| 16k: https://learn.microsoft.com/en-
| us/windows/win32/debug/system...
|
| 2. There's file related error codes way above 5, eg.
| ERROR_FILE_EXISTS 80 (0x50)
|
| The general gist of your comment is correct though. Suppose
| windows didn't have file locks before and they were adding
| it. Returning an error code like FILE_LOCKED or whatever
| would be much more descriptive, but would also require all
| existing code to handle this error case. With that in mind
| returning ACCESS_DENIED makes perfect sense, even if
| programs aren't using jump tables.
| tpm wrote:
| > Much of the crappy legacy behavior that Microsoft
| maintains is the fault of other applications, not
| themselves.
|
| Well. I have two or three (I am not even sure because for
| one email address there are probably two accounts, but no
| way to distinguish between them) MS Teams accounts. There
| is no painless way to switch between them. Currently there
| are probably at least three different MS Teams apps
| installed on my machine, one of them self-installed without
| my consent (my PC is not managed by an org or domain, it's
| mine). Switching accounts involves several confusing
| errors, at least three password inputs, and several
| complaints by MS Teams that something is wrong, but it
| won't tell me how to fix it.
|
| Use the browser version they said. Well for scheduled
| meetings it works, but for adhoc calls Firefox does not
| (there is no reason provided, but at least it does say
| outright), while Chrome seems to work but does not transmit
| my voice and camera. All other meeting software, of course,
| works.
|
| I am not the youngest anymore and this is my lifelong
| experience with Microsoft. Its software works barely enough
| to sell to corporations; poor users have to endure it.
| derefr wrote:
| The point of the article, in large part, is that when you're
| designing an alternative runtime for a new platform, it is _up
| to you_ what conditions are considered to be errors. Deciding
| to make a component of the runtime "inert" exists _before and
| above_ the decision to make the implementation panic.
|
| In this specific case: it is up to Microsoft to decide what the
| semantics of "printing on an Xbox" are. It could be an error;
| or it could be something that "could be supported in theory in
| the future, but for now has no way to actually accomplish it."
| This is a design choice, not a development choice.
|
| After all, in theory, you _could_ print on an Xbox -- plug in a
| USB printer, find a "game" that knows how to print (some
| enhanced port of a Gameboy game that had GB Printer support,
| maybe?), and tell it to do so. It's not _necessarily,
| fundamentally_ an error that a Xbox game is trying to print.
| You could _define_ it as an error -- but that's a choice like
| any other, with trade-offs (in this case, to application
| portability.) You could define it as asking for the user to
| choose from no options, as the Xbox actually does. You could
| have the API lie and say it printed something. You could even
| _actually support printing_. These are all choices.
|
| It's only once you've made that choice, defining the semantics
| of "printing on an Xbox" as an error, that it becomes an
| implementation/debugging problem if that error isn't thrown --
| i.e. gets "swallowed."
| freeone3000 wrote:
| UWP apps that don't require specifically desktop APIs will
| run on Xbox -- including, for instance, Excel.
| WalterBright wrote:
| It has irked me for decades that when the internet connection
| fails, all you get is a message that it failed. But what
| failed?
|
| 1. the software on your computer
|
| 2. the computer's hardware
|
| 3. the ethernet cable or wifi
|
| 4. the switch
|
| 5. the router
|
| 6. the cable modem
|
| 7. the internet cable to your house
|
| 8. the ISP
|
| 9. the remote system you're trying to connect to
|
| Nothing has improved for decades.
| sgustard wrote:
| The fact that Microsoft APIs randomly do nothing explains
| everything you need to know about being a Microsoft developer.
| anonacct37 wrote:
| 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 wrote:
| > 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_l...
| 1970-01-01 wrote:
| 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 wrote:
| throw checked exception so that xbox will have to handle the
| exception. xbox implementation can donothing if they want.
| leaf8937 wrote:
| if possible, throw checked exception which must be handled.
| zxcvbnm wrote:
| 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.
| patapong wrote:
| 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.
| o11c wrote:
| Making it a linker error doesn't even seem to be considered. Xbox
| is a separate target so a recompile is needed anyway ...
___________________________________________________________________
(page generated 2024-02-16 23:00 UTC)