Earlier quoted context omitted.
Yes exactly, but Microsoft isnt the one who can implement that.
This was about the Xbox printing subsystem, right? Of course they can implement that.
It would be whoever writes the software (ie the game) for the xbox.
If you're just going to sit there doing nothing, at least do nothing correctly
331–340 of 356 posts
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#332Earlier quoted context omitted.
> No test required. Just try... catch. That doesn't even make any sense. Where on earth would you insert a try...catch? So many people commenting on this article seem to have fundamentally misunderstood what the situation/scenario even is, which is made more jarring by the fact that so many others seem to have gotten it just fine.
> So many people commenting on this article seem to have fundamentally misunderstood what the situation/scenario even is Agreed 100%. Those people have overlooked that this is about attempting to run apps on an unsupported OS. And when printing, the OS attempting to gaslight the user into thinking the fail is his fault for not connecting a printer.
How do you somehow both have a strong opinion about "deceiving users" and completely fail to understand the difference between a platform/OS and a device?
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#333Earlier quoted context omitted.
Now that you got there, which distribution released in 2023 allows me to run a GNU/Linux binary compiled in 2000, regardless of the distribution it was compiled on back in 2000?
If a binary from 2000 doesn't run, it's because of glibc ABI changes. I still have faint memories of glibc crap happening in the early 2000s. But if the binary from 2000 is statically linked, then the Linux kernel probably runs it fine today. Which is weird considering the argument you had with others above about how "Linux (kernel) doesn't run software", was it a buildup to convince us that "GNU(glibc)/Linux" is rea…
Only if those binaries were designed to be called from the Linux kernel directly, using only syscalls.
Last time I checked, hardly anyone uses their computer as an embedded board.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#334Earlier quoted context omitted.
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…
No, it's not. Like what is described in the original post, it is they spirit. For example for the case with the printer and the xbox, they could have an explicit obvious error for the application. Then it is the task of the application dev to validate its application for target it will run on. If it is does not work, it does not work. Otherwise, you will still have dozens of bugs and unexpected behaviors, so a crappy…
> they could have an explicit obvious error for the application.
No, they can't. "The application" has already been written by a 3rd party who could be out of business for all we know.
> If it is does not work, it does not work.
Or you could let it keep working. Somebody might depend on it, and none of this is their fault.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#335Everyone 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 bet…
> 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…
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.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#336Earlier quoted context omitted.
these aren't the only two options. first of all, i certainly wouldn't be more frustrated if the app just crashed, but how about just letting the user know that the xbox can't print? why does everybody seem to think that's out of the question?
> but how about just letting the user know that the xbox can't print? why does everybody seem to think that's out of the question? Because the situation described is about an application that was made for PC (which supports printing) and a user is trying to run it on an Xbox (which doesn't support printing) with the developer never even imagining someone will try to run the program on an Xbox in the first place. You…
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.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#337Earlier quoted context omitted.
This was about the Xbox printing subsystem, right? Of course they can implement that.
It would be whoever writes the software (ie the game) for the xbox.
The Xbox OS can very well pop up a system notification directly to the user if an unsupported API is being accessed. This is not Unix where you have to assume no UI may even exist - the Xbox OS knows full well how to draw its own dialog on the screen.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#338What 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.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#339As 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 or https://azsh.it/107
This article made me realize while Azure is the way it is - unreliable and broken.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#340Earlier quoted context omitted.
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…
> Microsoft learned that it doesn't matter why the BSOD occurred, just that bad software/hardware was giving them the bad reputation. But the primary resolution to that problem was to force hardware vendors to write higher quality drivers (or for MS to write good enough default drivers that HW vendors wouldn't need their own), not to hide the BSOD. Technical details were only removed from them 2 decades after MS star…
Certifications have done a lot, but Windows now supports things like automatically restarting the graphics driver after it crashes instead of bringing down the system. I don't have inside information but from the outside, the HAL on Windows has evolved from freezing on a misbehaving USB device to just prompting you when you have exceeded the max number of USB devices supported. Anyone who remembers trying to dock a laptop back in the Windows 98 days remembers it being a dice roll if you would freeze the laptop or not.