311–320 of 356 posts
Earlier quoted context omitted.
Linux kernel on its own doesn't run software.
> Linux kernel on its own doesn't run software. Linux runs /sbin/init. Which you can make any executable you want. Not to mention initial RAMdisk (loaded by a bootloader like grub) which can be of arbitrary size & loaded up with an arbitrary ton of goodness.
Earlier quoted context omitted.
> probably because they only tested the app on a PC If they made an app only for PC, why would they test it on Xbox?? If they wanted their app to run on Xbox, why would they not make an Xbox version, and test it there?? RC's scenario is taking an app made for only Windows PC and running it on Xbox. I wonder if he has found even one example which permits this in the licence.
> RC's scenario is taking an app made for only Windows PC and running it on Xbox. I wonder if he has found even one example which permits this in the licence. I don't know what program he would be talking about, but I think if Raymond Chen is writing about something, it's usually because it is a real problem that was encountered, even if he's writing about it as if it was hypothetical to avoid naming the software in…
I don't doubt that. But I do doubt the problem can be encountered except by abusing the app.
> He generally avoids naming non-Microsoft software he's found bugs in.
Not relevent, since this failure of Xbox to run a Windows app is not a bug.
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.
Earlier quoted context omitted.
> probably because they only tested the app on a PC If they made an app only for PC, why would they test it on Xbox?? If they wanted their app to run on Xbox, why would they not make an Xbox version, and test it there?? RC's scenario is taking an app made for only Windows PC and running it on Xbox. I wonder if he has found even one example which permits this in the licence.
> RC's scenario is taking an app made for only Windows PC and running it on Xbox. I wonder if he has found even one example which permits this in the licence. I don't know what program he would be talking about, but I think if Raymond Chen is writing about something, it's usually because it is a real problem that was encountered, even if he's writing about it as if it was hypothetical to avoid naming the software in…
I don't doubt that. But I do doubt this problem can be encountered except by abusing the app.
> He generally avoids naming non-Microsoft software he's found bugs in.
Not relevent, since this failure of Xbox to run a Windows app is not a bug.
Earlier quoted context omitted.
GNU/Linux + the linux kernel. Somehow, it feels like you don't actually care about the point I was making as much as putting me down. I misspoke...barely, yet you're so fixated on pointing it out in the most unhelpful manner. You keep replying so why not try using more than one sentence next time?
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?
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 really bad at running old binaries? Because your argument doesn't hold for the Linux kernel itself running statically linked binaries.
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…
There's nothing wrong or buggy about the printing API on Xbox returning a list of no printers instead of an exception.
It's essentially the Null Object design pattern. Even Go implements this in the way that a zero list can still be accessed an jsut behaves as an empty list.
Or in unix how /dev/null exists, which implements the file API but doesn't do anything. This is way nicer than fixing every UNIX program to handle stdout not existing sometimes.
Earlier quoted context omitted.
> Linux kernel on its own doesn't run software. Linux runs /sbin/init. Which you can make any executable you want. Not to mention initial RAMdisk (loaded by a bootloader like grub) which can be of arbitrary size & loaded up with an arbitrary ton of goodness.
Yeah, which is quite far from a full OS experience providing ABI compatibility across several generations of operating systems.
But as you state: it's the OS-level ABI's (C library, desktop environments, middleware libraries, etc) that keep changing constantly. And thus, keep breaking pre-compiled binaries.
Source-level API vs. binary ABI stability. Kind of a philosophical debate imho. But sadly, even that source-level API isn't too stable in some circles.
Earlier quoted context omitted.
> 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.
? Why even have these APIs? Xbox essentially runs Windows. Therefore, the Windows API is available on Xbox.
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…
Not limited to testing time, though.
Earlier quoted context omitted.
? Why even have these APIs? Xbox essentially runs Windows. Therefore, the Windows API is available on Xbox.
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?