4 ms·

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

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 would jump out into hyperspace since 6 was beyond that lookup table and that memory word could be anything. So Microsoft was stuck folding every possible file open error into code 5, and to this day that's why just about any file error in Windows just says "5 Access Denied". And no, Microsoft couldn't add more error codes and just let the applications break, since then nobody would buy the new operating system versions that their programs wouldn't work on.

gruez 3y ago
> When Microsoft tried to add any error codes (say 6), the program would jump out into hyperspace since 6 was beyond that lookup table and that memory word could be anything. So Microsoft was stuck folding every possible file open error into code 5, and to this day that's why just about any file error in Windows just says "5 Access Denied". And no, Microsoft couldn't add more error codes and just let the applications break, since then nobody would buy the new operating system versions that their programs wouldn't work on. This doesn't pass the sniff test because 1. There's documented error codes that go all the way up to 16k: https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499- https://learn.microsoft.com/en-us/windows/win32/debug/system... 2. There's file related error codes way above 5, eg. ERROR_FILE_EXISTS 80 (0x50) The general gist of your comment is correct though. Suppose windows didn't have file locks before and they were adding it. Returning an error code like FILE_LOCKED or whatever would be much more descriptive, but would also require all existing code to handle this error case. With that in mind returning ACCESS_DENIED makes perfect sense, even if programs aren't using jump tables.
tpm 3y ago
> Much of the crappy legacy behavior that Microsoft maintains is the fault of other applications, not themselves. Well. I have two or three (I am not even sure because for one email address there are probably two accounts, but no way to distinguish between them) MS Teams accounts. There is no painless way to switch between them. Currently there are probably at least three different MS Teams apps installed on my machine, one of them self-installed without my consent (my PC is not managed by an org or domain, it's mine). Switching accounts involves several confusing errors, at least three password inputs, and several complaints by MS Teams that something is wrong, but it won't tell me how to fix it. Use the browser version they said. Well for scheduled meetings it works, but for adhoc calls Firefox does not (there is no reason provided, but at least it does say outright), while Chrome seems to work but does not transmit my voice and camera. All other meeting software, of course, works. I am not the youngest anymore and this is my lifelong experience with Microsoft. Its software works barely enough to sell to corporations; poor users have to endure it.
greatgib 3y ago
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 application. And new app developers will have to build upon that. Imagine the next app developer, you have to take into account that a platform pretends to support printers when it is not the case. So you will do things like: if there is a printer api but i don't see a printer available (/connected), pretend that we can't print and don't show the button... and so on... If you have doubts about that, you can read the history of the openxml format: https://ooxmlisdefectivebydesign.blogspot.com/2007/08/microsoft-office-xml-formats-defective.html https://ooxmlisdefectivebydesign.blogspot.com/2007/08/micros...
- buttercraft 3y ago
  > 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.

gruez 3y ago

> When Microsoft tried to add any error codes (say 6), the program would jump out into hyperspace since 6 was beyond that lookup table and that memory word could be anything. So Microsoft was stuck folding every possible file open error into code 5, and to this day that's why just about any file error in Windows just says "5 Access Denied". And no, Microsoft couldn't add more error codes and just let the applications break, since then nobody would buy the new operating system versions that their programs wouldn't work on. This doesn't pass the sniff test because 1. There's documented error codes that go all the way up to 16k: https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499- https://learn.microsoft.com/en-us/windows/win32/debug/system... 2. There's file related error codes way above 5, eg. ERROR_FILE_EXISTS 80 (0x50) The general gist of your comment is correct though. Suppose windows didn't have file locks before and they were adding it. Returning an error code like FILE_LOCKED or whatever would be much more descriptive, but would also require all existing code to handle this error case. With that in mind returning ACCESS_DENIED makes perfect sense, even if programs aren't using jump tables.

tpm 3y ago

> Much of the crappy legacy behavior that Microsoft maintains is the fault of other applications, not themselves. Well. I have two or three (I am not even sure because for one email address there are probably two accounts, but no way to distinguish between them) MS Teams accounts. There is no painless way to switch between them. Currently there are probably at least three different MS Teams apps installed on my machine, one of them self-installed without my consent (my PC is not managed by an org or domain, it's mine). Switching accounts involves several confusing errors, at least three password inputs, and several complaints by MS Teams that something is wrong, but it won't tell me how to fix it. Use the browser version they said. Well for scheduled meetings it works, but for adhoc calls Firefox does not (there is no reason provided, but at least it does say outright), while Chrome seems to work but does not transmit my voice and camera. All other meeting software, of course, works. I am not the youngest anymore and this is my lifelong experience with Microsoft. Its software works barely enough to sell to corporations; poor users have to endure it.

greatgib 3y ago

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 application. And new app developers will have to build upon that. Imagine the next app developer, you have to take into account that a platform pretends to support printers when it is not the case. So you will do things like: if there is a printer api but i don't see a printer available (/connected), pretend that we can't print and don't show the button... and so on... If you have doubts about that, you can read the history of the openxml format: https://ooxmlisdefectivebydesign.blogspot.com/2007/08/microsoft-office-xml-formats-defective.html https://ooxmlisdefectivebydesign.blogspot.com/2007/08/micros...

buttercraft 3y ago
> 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.