A real world example of this would be the POSIX semaphore API existing on macOS then returning the “not implemented” error code when you try to use it. So either you had the foresight to check the return value of a function that would just be memset 0 on a futexy OS, or you get to waste a bunch of time figuring out why your thread pool doesn’t work anymore, with the symptoms being 10 miles from the problem.
I did get to talk about this in a job interview at the time, “what kind of problems have you run into when writing cross platform software? oh yeah we got bit by that recently too” so maybe it was actually a win for me overall but in general please just remove it from the API and break the build instead of doing this.
Lots of software in the Microsoft-supported world is about binary compatibility, keeping old exes working on new OS updates whenever practical (and I’d imagine this is even more true on the xbox if it has any kind of backward compatibility; you can’t tell someone to recompile their CD game they’ve had on the shelf for 20 years. But you might tell by reading this I played the original Halo once and then haven’t kept up with the new stuff lol)
They do have named semaphores which is just even more perplexing so you can sort of wrap the one through the other. Other fun corners are passing descriptors over sendmsg/recvmsg with 0 bytes payloads versus 1 bytes on OSX versus the rest. On the other hand for the longest time they didn’t implement PTHREAD_PROCESS_SHARED for mutexes, OpenBSD still doesn’t even though it has the building blocks.
That does sound painful, but IMO the problem is not the macOS behavior but C/C++ making it easy to ignore errors. The path of least resistance must be to propagate or crash on errors, never to ignore them implicitly.
The idea here is that the printing API has always existed on desktop, where printing is supported, and the “get me the list of printers” function is documented not to throw an exception. If you want to port the printing API to Xbox, how do you do it in a way that allows existing desktop apps to continue to run on Xbox?
If you find yourself faced with such an impossible task, you must have made a wrong turn earlier in the process. In this case: accepting the idea that every program that runs on a desktop should also run on an XBox.
If you think about it, it is a dumb idea anyway. Desktops and Xbox’s serve entirely different purpose and have many more differences. There is no keyboard on an XBox, for example.
What is the cross section of applications that have a valid purpose on both devices? Do any of them need to print? I don’t own a Windows desktop, nor do I own an XBox, but I suspect this list is so short that it is better to just let the thing crash and not bother with all the mental gymnastics and the confusing error messages that it will inevitably will produce.
Xbox does actually support keyboards and a range of other input devices for folks who may not have full motor control. It does sound odd at a high level yeah, printing APIs and other things, but there are probably loads of benefits of sharing a subset of the API surface. Cross platform games back in the day were an absolute nightmare so much so that you’d almost be building two separate engines.
MS also introduced a lot more multi-media apps on tablets and xbox (like netflix and friends) which probably contributed to the need for a shared API surface. You can write an app for xbox, tablets and pcs all with roughly one codebase (and phones at one time, rip windows phone, you were taken from us too early)
MS also introduced a lot more multi-media apps on tablets and xbox (like netflix and friends) which probably contributed to the need for a shared API surface. You can write an app for xbox, tablets and pcs all with roughly one codebase
I think that this is a bad idea that leads to the confusing situations as described. No-one wants to have the exact same app on all their different devices. The different types of devices are different for a reason, you don’t use them in the same way. If you would, you would never need to buy both a workstation and a phone, because you could lug your workstation around and do all the things you would do on your phone without a problem.
There is code that could be shared, of course. But that is more on the level of a library like a network stack, not on the level of the user interface or peripherals. If the libraries are so intertwined that you can’t re-use the network stack without also incorporating the printer API then… I don’t know what to say.
I’m not entirely convinced by this, but I guess so long as you have a proper way of asking if e.g. printing is supported on the device, then it’s probably good if you include a kludge that lies to the app if they ask for printing anyway.
I guess a better way to do this from the start might be to handle all API access with capabilities and to include a testing tool that can run the app and refuse to give capabilities sometimes.
Maybe if you have a market cap measured in the trillions, then you can hire a large enough army of software engineers to maintain these various edge cases! Sounds like it would be a nightmare to maintain unless you had that amount of resources.
A real world example of this would be the POSIX semaphore API existing on macOS then returning the “not implemented” error code when you try to use it. So either you had the foresight to check the return value of a function that would just be memset 0 on a futexy OS, or you get to waste a bunch of time figuring out why your thread pool doesn’t work anymore, with the symptoms being 10 miles from the problem.
I did get to talk about this in a job interview at the time, “what kind of problems have you run into when writing cross platform software? oh yeah we got bit by that recently too” so maybe it was actually a win for me overall but in general please just remove it from the API and break the build instead of doing this.
Side note: Mac OS, as of very recently, has an experimental futex-like API:https://developer.apple.com/documentation/os/4316531-os_sync_wait_on_address
They have had it for a while—undocumented, but used by libc++ so it wasn’t going anywhere.
This is assuming there is a build.
Lots of software in the Microsoft-supported world is about binary compatibility, keeping old exes working on new OS updates whenever practical (and I’d imagine this is even more true on the xbox if it has any kind of backward compatibility; you can’t tell someone to recompile their CD game they’ve had on the shelf for 20 years. But you might tell by reading this I played the original Halo once and then haven’t kept up with the new stuff lol)
They do have named semaphores which is just even more perplexing so you can sort of wrap the one through the other. Other fun corners are passing descriptors over sendmsg/recvmsg with 0 bytes payloads versus 1 bytes on OSX versus the rest. On the other hand for the longest time they didn’t implement PTHREAD_PROCESS_SHARED for mutexes, OpenBSD still doesn’t even though it has the building blocks.
That does sound painful, but IMO the problem is not the macOS behavior but C/C++ making it easy to ignore errors. The path of least resistance must be to propagate or crash on errors, never to ignore them implicitly.
If you find yourself faced with such an impossible task, you must have made a wrong turn earlier in the process. In this case: accepting the idea that every program that runs on a desktop should also run on an XBox.
If you think about it, it is a dumb idea anyway. Desktops and Xbox’s serve entirely different purpose and have many more differences. There is no keyboard on an XBox, for example.
What is the cross section of applications that have a valid purpose on both devices? Do any of them need to print? I don’t own a Windows desktop, nor do I own an XBox, but I suspect this list is so short that it is better to just let the thing crash and not bother with all the mental gymnastics and the confusing error messages that it will inevitably will produce.
Xbox does actually support keyboards and a range of other input devices for folks who may not have full motor control. It does sound odd at a high level yeah, printing APIs and other things, but there are probably loads of benefits of sharing a subset of the API surface. Cross platform games back in the day were an absolute nightmare so much so that you’d almost be building two separate engines.
MS also introduced a lot more multi-media apps on tablets and xbox (like netflix and friends) which probably contributed to the need for a shared API surface. You can write an app for xbox, tablets and pcs all with roughly one codebase (and phones at one time, rip windows phone, you were taken from us too early)
I think that this is a bad idea that leads to the confusing situations as described. No-one wants to have the exact same app on all their different devices. The different types of devices are different for a reason, you don’t use them in the same way. If you would, you would never need to buy both a workstation and a phone, because you could lug your workstation around and do all the things you would do on your phone without a problem.
There is code that could be shared, of course. But that is more on the level of a library like a network stack, not on the level of the user interface or peripherals. If the libraries are so intertwined that you can’t re-use the network stack without also incorporating the printer API then… I don’t know what to say.
Presumably Windows and Xbox apps are built on the same shared libraries, and printing happens to be deeply embedded in these.
Or Raymond is stating a hypothetical, using examples his readers are familiar with.
I’m not entirely convinced by this, but I guess so long as you have a proper way of asking if e.g. printing is supported on the device, then it’s probably good if you include a kludge that lies to the app if they ask for printing anyway.
I guess a better way to do this from the start might be to handle all API access with capabilities and to include a testing tool that can run the app and refuse to give capabilities sometimes.
Maybe if you have a market cap measured in the trillions, then you can hire a large enough army of software engineers to maintain these various edge cases! Sounds like it would be a nightmare to maintain unless you had that amount of resources.