Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

devblogs.microsoft.com

Post reply on HN
Print view View original

341–350 of 356 posts

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

#341

Post by saagarjha »

lucianbr wrote: post #329
saagarjha wrote: post #295

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

I generally advocate for things crashing early, for reference. I just happen to work on emulators and compatibility shims a lot, much like what Microsoft is offering here.

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

#342

Post by lucianbr »

buttercraft wrote: post #335
lucianbr wrote: post #329

Earlier quoted context omitted.

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

Nothing Chen wrote motivates me to use the API correctly, that's the whole point. "Just don't do the bad thing" is naive. People will use APIs incorrectly, despite your admonition.

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

#343

Post by lucianbr »

eastbound wrote: post #73
lucianbr wrote: post #25

Earlier quoted context omitted.

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 b…

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”?

Look at all the comments insisting that the way Microsoft does it is the correct, superior way. How could we do away with it then?

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

#344

Post by Aaargh20318 »

plorkyeran wrote: post #320
Aaargh20318 wrote: post #318

Earlier quoted context omitted.

But they are essentially removing parts of the Windows API, that’s what the entire article is about. Wouldn’t it make more sense AND be a lot less work to simply remove these APIs from the header files than to provide a stub implementation?

There are no header files involved. The whole point of this is to support running existing programs without recompiling them for the new platform.

What existing apps could you possibly want to run on a game console without at least a few modifications to make it suitable to run with the completely different control scheme and user expectations of a console.

It seems like an enormous amount of effort for an extreme edge case. It’s this weird obsession Microsoft has with the flawed idea that you should be able to run anything on every device without modifications. It’s their unwillingness to acknowledge that different types of devices require different user experiences.

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

#346

Post by buttercraft »

lucianbr wrote: post #342
buttercraft wrote: post #335

Earlier quoted context omitted.

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.

Nothing Chen wrote motivates me to use the API correctly, that's the whole point. "Just don't do the bad thing" is naive. People will use APIs incorrectly, despite your admonition.

> "Just don't do the bad thing" is naive. People will use APIs incorrectly

That is the whole point! You don't have a choice for software that will not change - all you can do is try to keep it working anyway. Like they did here.

That you are not "motivated" to do things correctly is not a convincing argument otherwise.

If you don't want this behavior in your own apps, you don't have to invoke it. Using the API correctly sidesteps all of this but is not a choice when "doing emulation for software that will not change."

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

#347

Post by gkbrk »

delta_p_delta_x wrote: post #163
PaulHoule wrote: post #115

Earlier quoted context omitted.

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 visual…

> 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]. Windows 2000 is 24 years old this year. - It is possible to run a binary written for and compiled in W…

> Windows has gone to extreme lengths to not only maintain API compatibility, but ABI compatibility as well.

Linux has a stable ABI as well. For a given architecture, like x86_64, syscall numbers and their arguments and their arguments/outputs are expected to be stable.

The stable API/ABI promise of Linux is the syscalls, because at the end of the day that is the interface between userspace applications and the kernel, and kernel devs take not breaking userspace very seriously.

And on Windows, the opposite is true. The stable interface is the Windows DLLs that you are supposed to use dynamically. If you hardcoded the syscalls, you cannot complain if your application breaks because windows only promises that the DLL will not break backwards compatibility, and they reserve the right to change the syscalls with any update.

So you can have a Linux binary that works across many Linux versions without breaking. You can also have a Windows binary that works on one version of Windows but not the next.

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

#348

Post by badsectoracula »

tsimionescu wrote: post #336
badsectoracula wrote: post #309

Earlier quoted context omitted.

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

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.

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

#349

Post by BeFlatXIII »

tsimionescu wrote: post #45
kentonv wrote: post #30

Earlier quoted context omitted.

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 thes…

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.

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.

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

#350

Post by tsimionescu »

badsectoracula wrote: post #348
tsimionescu wrote: post #336

Earlier quoted context omitted.

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

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

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

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

Post reply on HN