4 ms·
> 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 f
by bitwize 3y ago
> 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 3y agoI 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.
- dwattttt 3y agoJust to add further context; this isn't apps being ported to an Xbox, they notionally need no porting; the Xbox is a "Windows" system. The only actor in this scenario is the platform developer figuring out how an existing API should behave if called in a context the authors very much didn't expect (who expects their Windows app to be run on an Xbox?)
- lhamil64 3y agoI guess I'm confused then. Is the expectation that you can just run any Windows app on an Xbox, unmodified? I would think you'd have to at least change the UI
- plorkyeran 3y agoYes, that is a thing the Xbox supports (for UWP apps, not every Windows app ever). The UI is indeed often not great.
- xp84 3y agoI 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.
- Joker_vD 3y ago> “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” ...and then you'll also have to re-write your software to support Win 11, of course.