|
Coffee Mugshot posted:I don't really see why reserving those names is that crazy tbh. Also naming a package/crate after a popular keyword sounds like a bad idea in general. Because the only reason they're reserved is for backwards compatibility with software that was written before directories existed.
|
#
?
May 1, 2017 06:39
|
|
|
|
| # ? Jun 12, 2024 09:29 |
|
|
return0 posted:Depends if it's clinical death or legal death. I typed up an actual response but instead:  
|
|
#
?
May 1, 2017 08:05
|
|
|
vOv posted:Because the only reason they're reserved is for backwards compatibility with software that was written before directories existed.
|
|
#
?
May 1, 2017 14:34
|
|
|
vOv posted:Because the only reason they're reserved is for backwards compatibility with software that was written before directories existed. And all the software written since then that still uses them to access things.
|
|
#
?
May 1, 2017 15:53
|
|
|
fishmech posted:And all the software written since then that still uses them to access things. True. I guess they could've said "we're only going to support these special filenames at the root of each drive" but it's obviously far too late to make that change.
|
|
#
?
May 1, 2017 20:35
|
|
|
return0 posted:Is person to death date one to one? I think it merely approaches 1:1 asymptotically
|
|
#
?
May 1, 2017 21:26
|
|
|
Munkeymon posted:I think it merely approaches 1:1 asymptotically Well, we can solve that with a nice couple of meteors. 
|
|
#
?
May 1, 2017 21:43
|
|
|
vOv posted:True. I guess they could've said "we're only going to support these special filenames at the root of each drive" but it's obviously far too late to make that change. Yeah, but there must have been, what, hundreds of programs that would have needed to be rewritten to accommodate that kind of change
|
|
#
?
May 1, 2017 22:29
|
|
|
Soricidus posted:Yeah, but there must have been, what, hundreds of programs that would have needed to be rewritten to accommodate that kind of change
|
|
#
?
May 1, 2017 22:42
|
|
|
Soricidus posted:Yeah, but there must have been, what, hundreds of programs that would have needed to be rewritten to accommodate that kind of change Doesn't matter how many programs if a) you don't have the source, or b) the source is impenetrable because it was written by a defunct contractor 20 years ago, or c) your business depends on it, or d) you're important enough, or e) that program is actually an OS library, and the risk/reward for refactoring that part of the OS isn't worth it
|
|
#
?
May 1, 2017 22:45
|
|
|
Soricidus posted:Yeah, but there must have been, what, hundreds of programs that would have needed to be rewritten to accommodate that kind of change
|
|
#
?
May 1, 2017 22:53
|
|
|
I don't know why they don't just preserve that behavior in the shell, but remove the stupid restriction from the filesystem, or preserve the current semantics only for filenames without an extension. It seems like there are some pretty easy ways to make almost everyone happy. I ran into this while trying to examine a project we were trying to use (Opensips) at work. The source has files called con.c (and some other similar things). It makes it *really* difficult to work with the source on a Windows machine.
|
|
#
?
May 2, 2017 01:03
|
|
|
Kilson posted:I don't know why they don't just preserve that behavior in the shell, but remove the stupid restriction from the filesystem 
|
|
#
?
May 2, 2017 08:14
|
|
|
Coffee Mugshot posted:I don't really see why reserving those names is that crazy tbh. Also naming a package/crate after a popular keyword sounds like a bad idea in general. There is never a better time to break backwards compatibility than today. Never ever fool yourself and think you can change it later. Every single day the odds of that happening decrease and the graph is a hockey stick. The reason DOS didn't create a C:\Devices directory similar to /dev was to preserve compatibility for less than a million people easily, maybe less than a hundred thousand. Now billions are stuck with the bad tradeoff. Why is Make is stupid about tabs vs spaces? Because Stuart Feldman didn't want to break the <100 makefiles that existed at the time he considered the bug so he left it alone. I'd argue that was the wrong tradeoff too. Don't break compatibility arbitrarily, but if there is a good reason you should treat it like a bandaid: rip it off quickly or you and everyone who follows after you will suffer for eternity.
|
|
#
?
May 2, 2017 08:48
|
|
|
To play devil's advocate, consider this: how many of those projects would not have survived until today had they broken compatibility when they had a small userbase?
|
|
#
?
May 2, 2017 13:39
|
|
|
Simulated posted:The reason DOS didn't create a C:\Devices directory similar to /dev was to preserve compatibility for less than a million people easily, maybe less than a hundred thousand. Now billions are stuck with the bad tradeoff. Then we'd have devices as the directory/file name we couldn't use. I don't see how that'd be better?
|
|
#
?
May 2, 2017 16:32
|
|
|
Kilson posted:I don't know why they don't just preserve that behavior in the shell, but remove the stupid restriction from the filesystem, or preserve the current semantics only for filenames without an extension. People gotta get over the idea that it's every operating system's duty to copy the behavior of unix. Gazpacho fucked around with this message at 16:57 on May 2, 2017 |
|
#
?
May 2, 2017 16:40
|
|
|
fishmech posted:Then we'd have devices as the directory/file name we couldn't use. I don't see how that'd be better? You really don't see how that'd be better than having a list of reserved names in every single directory instead?
|
|
#
?
May 2, 2017 17:15
|
|
|
fishmech posted:Then we'd have devices as the directory/file name we couldn't use. I don't see how that'd be better? It seems far more likely that someone will try to make a document called aux in their user folder than try to create it in a special folder their root directory.
|
|
#
?
May 2, 2017 17:14
|
|
|
Munkeymon posted:You really don't see how that'd be better than having a list of reserved names in every single directory instead? Devices would be reserved in every directory in this system too - remember, DOS 1.0 didn't HAVE any real subdirectories! The only way to implement it would be to reserve "devices" as a name you couldn't use anywhere in the file system.
|
|
#
?
May 2, 2017 17:21
|
|
|
Raymond Chen has explained this at length and repeatedly. There is no point when it is OK to wantonly break compatibility for customers of a successful product that is marketed for business automation. People will sue you. Apple can do it to the extent that they target individuals over businesses.
|
|
#
?
May 2, 2017 17:24
|
|
|
fishmech posted:Devices would be reserved in every directory in this system too - remember, DOS 1.0 didn't HAVE any real subdirectories! The only way to implement it would be to reserve "devices" as a name you couldn't use anywhere in the file system. Uh, what? Yes, the proposed compatibility breaking change breaks compatibility. It also wouldn't have retroactively gone back and changed what the reserved names were in earlier versions of DOS.
|
|
#
?
May 2, 2017 17:34
|
|
|
Gazpacho posted:Raymond Chen has explained this at length and repeatedly. There is no point when it is OK to wantonly break compatibility for customers of a successful product that is marketed for business automation. People will sue you. Apple can do it to the extent that they target individuals over businesses. So this might be a naive question, but has anyone ever actually been successfully sued over breaking backwards compatibility? I searched and couldn't find any examples of it, but maybe there's some famous case or something that I just haven't heard of / my googling skills are poor.
|
|
#
?
May 2, 2017 17:35
|
|
|
Gazpacho posted:Raymond Chen has explained this at length and repeatedly. There is no point when it is OK to wantonly break compatibility for customers of a successful product that is marketed for business automation. People will sue you. Apple can do it to the extent that they target individuals over businesses. And it pisses the gently caress out of people that use Apple products all the time; they're just too locked-in to do anything about it.
|
|
#
?
May 2, 2017 17:42
|
|
|
The first (and best) chance DOS could have had of replacing the magic device names with something less intrusive would have been as soon as DOS 2.0 where a replacement for the CP/M-compatible FCBS API was added. That was also when support for (sub)directories was added. I.e. if your program used the FCBS API you got magic device names, if you used the new file access API you had to access special devices in another way.
|
|
#
?
May 2, 2017 17:58
|
|
|
fishmech posted:Devices would be reserved in every directory in this system too - remember, DOS 1.0 didn't HAVE any real subdirectories! The only way to implement it would be to reserve "devices" as a name you couldn't use anywhere in the file system. It was implied that this would be a change in 2.0 (note that I'm not saying that this'd be good for sales of DOS 2.0, just that it'd be better for us now had it happened and somehow the rest of history hadn't changed at all)
|
|
#
?
May 2, 2017 18:06
|
|
|
The best time to make a breaking change was 20 years ago. The second best time is now.
|
|
#
?
May 2, 2017 18:10
|
|
|
VikingofRock posted:So this might be a naive question, but has anyone ever actually been successfully sued over breaking backwards compatibility? I searched and couldn't find any examples of it, but maybe there's some famous case or something that I just haven't heard of / my googling skills are poor. Gazpacho fucked around with this message at 18:51 on May 2, 2017 |
|
#
?
May 2, 2017 18:44
|
|
|
Dr. Stab posted:Uh, what? Yes, the proposed compatibility breaking change breaks compatibility. It also wouldn't have retroactively gone back and changed what the reserved names were in earlier versions of DOS. It was being specifically proposed to have happened in the early versions of DOS though. Also to actually propose to do that change now would be very stupid because introducing a new reserved folder name now would break a ton of things that aren't broken now... Munkeymon posted:It was implied that this would be a change in 2.0 If we'd actually done that in 2.0, then we would still have the problem of a pointlessly reserved name int he root of the file system. It does nothing to fix the problem (device names shouldn't block reasonable file names) it just makes it slightly less of a pain. But then you'd say, have someone wondering why they have C:\projects with a "devices" directory in there, and they want to copy it to their floppy disk or in modern times a flash drive, and the copy fails because you can't have a devices directory in the root.
|
|
#
?
May 2, 2017 18:45
|
|
|
Incidentally, this is why Microsoft didn't start to fix the Internet Explorer brokenness until the European Commission threatened to clean their clock with fines.
|
|
#
?
May 2, 2017 18:55
|
|
|
Gazpacho posted:A woman was running her travel agency on Windows 7. The forced Windows 10 upgrade hosed her applications and she got a $10,000 judgement in small claims. Microsoft declined to appeal and stopped forcing the upgrade. Another case regarding the Windows 10 upgrade, Watson et al. v. Microsoft, seeks class status and is still pending. That lawsuit specifically alleges failure to ensure compatibility. That's not really the same thing though. The suits aren't focused on the fact that Windows 10 is backwards-incompatible with Windows 7; they are focused on consumers being forced to upgrade to Windows 10. If Microsoft makes a breaking change between windows versions, but then doesn't force anyone to update, then it doesn't seem like it would matter legally.
|
|
#
?
May 2, 2017 18:59
|
|
|
In the Watson case the plaintiffs admit agreeing to the upgrade, so the forcing is not relevant there. And in both cases, what Microsoft neglected to do is as much an issue as what it actively did.
|
|
#
?
May 2, 2017 19:23
|
|
|
fishmech posted:If we'd actually done that in 2.0, then we would still have the problem of a pointlessly reserved name int he root of the file system. It does nothing to fix the problem (device names shouldn't block reasonable file names) it just makes it slightly less of a pain. Hmm, I guess I was assuming Devices would only show up on systemroot, but then you could plug a second bootable drive in and plonk a Devices down on it, so then I guess when booting it the system would either clobber the directory or shadow it, which is also kinda gross... Probably a reserved device root would have worked better. $:\NUL I guess
|
|
#
?
May 2, 2017 19:37
|
|
|
Munkeymon posted:Hmm, I guess I was assuming Devices would only show up on systemroot, but then you could plug a second bootable drive in and plonk a Devices down on it, so then I guess when booting it the system would either clobber the directory or shadow it, which is also kinda gross... Well I mean, the correct way to do it in the limited capabilities of old DOS was probably to require the device names to be otherwise marked. E.g. if they had just always been CON: instead of CON. The colon character was not an allowable disk file character, so there was no chance you'd make a CON: file and ahve issues with conflicting to the system console, and thus none of the names would have been disallowed as files or directories, when directories were added.
|
|
#
?
May 2, 2017 19:45
|
|
|
fishmech posted:Well I mean, the correct way to do it in the limited capabilities of old DOS was probably to require the device names to be otherwise marked. E.g. if they had just always been CON: instead of CON. The colon character was not an allowable disk file character, so there was no chance you'd make a CON: file and ahve issues with conflicting to the system console, and thus none of the names would have been disallowed as files or directories, when directories were added. Thought about that, but I'm guessing their code would have been more hostile to a multi-char device root than a 'fake' one that couldn't be user-assigned or changed.
|
|
#
?
May 2, 2017 19:49
|
|
|
fishmech posted:It was being specifically proposed to have happened in the early versions of DOS though. Also to actually propose to do that change now would be very stupid because introducing a new reserved folder name now would break a ton of things that aren't broken now... This post doesn't really make sense with that reading Simulated posted:The reason DOS didn't create a C:\Devices directory similar to /dev was to preserve compatibility for less than a million people easily, maybe less than a hundred thousand. Now billions are stuck with the bad tradeoff. It's talking about introducing a change back when sub directories were introduced, not doing it differently initially or making the change right now.
|
|
#
?
May 2, 2017 19:57
|
|
|
Dr. Stab posted:This post doesn't really make sense with that reading You don't think literally the second major version of DOS, released in 1983, would be the early versions, or what? Also again: mandating that you couldn't have a "devices" directory in the root of a drive would mean at least blocking it for all the drives on the systems, if not also blocking it in subdirectories. This would be a major problem! The real problem is the fact that any otherwise valid file names and directory names must be locked off because they're reserved. Switching to reserving just one name in a drive root doesn't solve that, it just reduces the number of things that are blocked, and it implicitly blocks the names in other directories because someone might want to copy a file or directory with that name into the root of another drive, which itself might be bootable. fishmech fucked around with this message at 20:04 on May 2, 2017 |
|
#
?
May 2, 2017 20:02
|
|
|
fishmech posted:You don't think literally the second major version of DOS, released in 1983, would be the early versions, or what? If you agree that it meant a change in 2.0, then what the hell did you mean by this: fishmech posted:Devices would be reserved in every directory in this system too - remember, DOS 1.0 didn't HAVE any real subdirectories! The only way to implement it would be to reserve "devices" as a name you couldn't use anywhere in the file system.
|
|
#
?
May 2, 2017 20:06
|
|
|
Dr. Stab posted:If you agree that it meant a change in 2.0, then what the hell did you mean by this: If you were actually making the change in DOS back then, you'd probably increase the version number early to indicate a point where compatibility changed, meaning the new 2.0 is a 1.x with this change. You also still have the problem of needing to reserve the directory name on every drive's root, and soft-reserve it in subdirectories because otherwise people would try to copy them to drive roots and have problems. It's a lovely solution that doesn't fix the problem.
|
|
#
?
May 2, 2017 20:39
|
|
|
|
| # ? Jun 12, 2024 09:29 |
|
|
Fishmech is right, path-based namespaces like /dev only work well on Unix because of the general convention that / is reserved for the system and users should never be touching it. DOS already has a somewhat reasonable namespacing scheme with drive/partition names; that design has both advantages and disadvantages relative to the Unix single-hierarchy scheme, but given that it exists, you might as well use it. There's no reason for device names to interfere with other hierarchies at all when they can be split off as CON: or DEV:CON or whatever.
|
|
#
?
May 2, 2017 21:42
|
|
