"Errors in DNA" or how wrong design can lead to million losses
I was prompted to write this note by another article with a “cry of the soul”: why did Windows once again require a reboot when changing something (usually installing / removing programs, but there are other cases)? Why are the developers of Windows applications such fuckers, and the developers of Linux programs (where there are no such messages when installing “ordinary programs”) are such good fellows?
This phenomenon has long been known to everyone - but did you think about where his “legs grow” and why in other operating systems (Linux, MacOS X, etc.) such windows are something exceptional, and in Windows - permanent?
No, it is not only the Krivorukov Software Writers that are to blame - the main fault lies with Microsoft. All of these endless queries are a combination of an error in the design of MS DOS, more than 20 years ago, and the theory of broken windows . It was a hot time for Microsoft - she wasn’t then a monster like today, she couldn’t make mistakes and develop something for years that would turn everyone around, and then release the next version of the OS that would correct the errors of the previous one (Windows98 => Windows98SE, Windows Vista => Windows 7, etc). Therefore, when it was necessary to do something with the support of local networks and to oppose the then leader (it was Novell with its Netware network operating system) at least something sensible, there was no need to think about design for a long time - it was done what was easiest to do and that would almost certainly work without errors and complaints. In MS-DOS, the SHARE.EXE utility appeared, allowing you to use several programs at the same time (at first — only on different computers, since MS DOS remained single-tasked, later — on one, after Windows became common) and the same an error, the consequences of which we are still clearing up. And no one noticed all the horror of the mistake made then, for nothing terrible, at first glance, was in it.
What was the mistake? He said that Microsoft didn’t say B. When Microsoft copied from Unix their main chip - a hierarchical file system (can you believe that the first version of MS DOS didn’t even contain this feature?) For simplicity, he didn’t copy one important idea: separation of the concept of "file" and "file name". In Unix, these concepts are separated. There is a file (or rather, an inode ) and there is its name (entry in the directory). The inode access rights and the file name access rights are generally not related to each other (in fact, then they had to introduce a couple of restrictions, but this is another story). The main thing: if the program opened the file and even if it did it in an exclusive mode, it does not apply to access rights to entries in the directory. What does it mean? This means, in particular, that you can “delete” any file (in fact, if this file is used — for example, a paging file — then it will not be deleted until it is used) and create a new one in its place. (in fact, a new file will most likely be created in a different place - but here an entry in the directory will be placed in the same place). In MS DOS, the program SHARE.EXE (and all its descendants including kernels such as Windows Vista and Windows 7) do not work this way. If access to the file is blocked, then access to its name is blocked! In MS-DOS (with the FAT file system, which allowed each file to have only one name), it looked logical; in NTFS, it already looks strange (you can give the file a new name, but you cannot delete the old one), but you can’t do anything since many programs rely on this (the decision was made, I recall, more than 20 years ago).
')
What are the consequences of this error? The consequences are the most serious. Many files in Windows cannot be modified at all in all of its work (since they are used by the system) and therefore several mechanisms have been suggested that allow us to get around this problem. You can specify the file name (say drivers) in the registry and create a new file / directory during the update — and delete the old one, say, when rebooting (or at another “convenient time”) - this approach is used, in particular, in .NET. You can simply replace the files after the reboot - but this is not all just because you need a special “patch” in the OS that allows you to do this (and it is in Windows), but the main thing is the “updated” file waiting for its turn is not visible in its usual place and it is unclear how it will be - and therefore many installation programs having discovered that the queue of “orders for changing configuration after reboot” of non-empty simply force it to reboot. In general, a lot of things can be done and done, but with all this, the installation of any program may require a reboot (if the developers have foreseen this), or (which is worse than IMNSHO), the reboot installation will not require, but the program will not work either. The funniest thing happens when the installed program works before the reboot, and then it breaks. This happens when one program ordered a change “after reboot”, the installer of another program installed the second program without taking into account these changes (he doesn’t see them - they are in the queue! And the second program did not dare to force the reboot so as not to irritate the user!) and after rebooting, the system broke down. Well, the final point is put by the “broken window theory”: if the solution to a part of the problems is only a reboot of the system and nothing else, then why not require it to restart and in other cases when it simply simplifies the life of developers?
On Unix (and, respectively, on Linux and / or MacOS), the situation is quite different: you can always replace any file with an “improved version” (if you have enough rights to do so), so you will never need to reload when you install most programs — of course it makes developers try to avoid it in other cases ...
Unfortunately, recently, Linux has begun to “lower the bar”: try to switch from KDE 3.x to KDE 4.x without stopping the system or at least without rebooting the X's! This is not so easy and requires a lot of crutches ... But in any case, such situations occur in Linux / MacOS / etc much less than in Windows. Because Windows has an “error in DNA”, inherited from its progenitor - MS DOS.
What does this story teach us? The fact that design mistakes are different: some can be easily fixed later, and some - you will be haunted for decades ... It remains only to learn to distinguish between them ...
This phenomenon has long been known to everyone - but did you think about where his “legs grow” and why in other operating systems (Linux, MacOS X, etc.) such windows are something exceptional, and in Windows - permanent?
No, it is not only the Krivorukov Software Writers that are to blame - the main fault lies with Microsoft. All of these endless queries are a combination of an error in the design of MS DOS, more than 20 years ago, and the theory of broken windows . It was a hot time for Microsoft - she wasn’t then a monster like today, she couldn’t make mistakes and develop something for years that would turn everyone around, and then release the next version of the OS that would correct the errors of the previous one (Windows98 => Windows98SE, Windows Vista => Windows 7, etc). Therefore, when it was necessary to do something with the support of local networks and to oppose the then leader (it was Novell with its Netware network operating system) at least something sensible, there was no need to think about design for a long time - it was done what was easiest to do and that would almost certainly work without errors and complaints. In MS-DOS, the SHARE.EXE utility appeared, allowing you to use several programs at the same time (at first — only on different computers, since MS DOS remained single-tasked, later — on one, after Windows became common) and the same an error, the consequences of which we are still clearing up. And no one noticed all the horror of the mistake made then, for nothing terrible, at first glance, was in it.
What was the mistake? He said that Microsoft didn’t say B. When Microsoft copied from Unix their main chip - a hierarchical file system (can you believe that the first version of MS DOS didn’t even contain this feature?) For simplicity, he didn’t copy one important idea: separation of the concept of "file" and "file name". In Unix, these concepts are separated. There is a file (or rather, an inode ) and there is its name (entry in the directory). The inode access rights and the file name access rights are generally not related to each other (in fact, then they had to introduce a couple of restrictions, but this is another story). The main thing: if the program opened the file and even if it did it in an exclusive mode, it does not apply to access rights to entries in the directory. What does it mean? This means, in particular, that you can “delete” any file (in fact, if this file is used — for example, a paging file — then it will not be deleted until it is used) and create a new one in its place. (in fact, a new file will most likely be created in a different place - but here an entry in the directory will be placed in the same place). In MS DOS, the program SHARE.EXE (and all its descendants including kernels such as Windows Vista and Windows 7) do not work this way. If access to the file is blocked, then access to its name is blocked! In MS-DOS (with the FAT file system, which allowed each file to have only one name), it looked logical; in NTFS, it already looks strange (you can give the file a new name, but you cannot delete the old one), but you can’t do anything since many programs rely on this (the decision was made, I recall, more than 20 years ago).
')
What are the consequences of this error? The consequences are the most serious. Many files in Windows cannot be modified at all in all of its work (since they are used by the system) and therefore several mechanisms have been suggested that allow us to get around this problem. You can specify the file name (say drivers) in the registry and create a new file / directory during the update — and delete the old one, say, when rebooting (or at another “convenient time”) - this approach is used, in particular, in .NET. You can simply replace the files after the reboot - but this is not all just because you need a special “patch” in the OS that allows you to do this (and it is in Windows), but the main thing is the “updated” file waiting for its turn is not visible in its usual place and it is unclear how it will be - and therefore many installation programs having discovered that the queue of “orders for changing configuration after reboot” of non-empty simply force it to reboot. In general, a lot of things can be done and done, but with all this, the installation of any program may require a reboot (if the developers have foreseen this), or (which is worse than IMNSHO), the reboot installation will not require, but the program will not work either. The funniest thing happens when the installed program works before the reboot, and then it breaks. This happens when one program ordered a change “after reboot”, the installer of another program installed the second program without taking into account these changes (he doesn’t see them - they are in the queue! And the second program did not dare to force the reboot so as not to irritate the user!) and after rebooting, the system broke down. Well, the final point is put by the “broken window theory”: if the solution to a part of the problems is only a reboot of the system and nothing else, then why not require it to restart and in other cases when it simply simplifies the life of developers?
On Unix (and, respectively, on Linux and / or MacOS), the situation is quite different: you can always replace any file with an “improved version” (if you have enough rights to do so), so you will never need to reload when you install most programs — of course it makes developers try to avoid it in other cases ...
Unfortunately, recently, Linux has begun to “lower the bar”: try to switch from KDE 3.x to KDE 4.x without stopping the system or at least without rebooting the X's! This is not so easy and requires a lot of crutches ... But in any case, such situations occur in Linux / MacOS / etc much less than in Windows. Because Windows has an “error in DNA”, inherited from its progenitor - MS DOS.
What does this story teach us? The fact that design mistakes are different: some can be easily fixed later, and some - you will be haunted for decades ... It remains only to learn to distinguish between them ...
Source: https://habr.com/ru/post/53048/
All Articles