Why can’t I move the Program Files directory via the unattend file?


We saw last time that the unattend file lets you change some Windows configuration settings that cannot be changed after Setup is complete. But one of the things you can't change is the location of the Program Files directory. Many people wish they could relocate their Program Files directory to another drive in order to relieve disk space pressure on the system partition. Why won't Windows let them do this?

Now that NTFS is mandatory for the system volume (it took only 13 years to get there!), Windows itself can start taking advantage of NTFS features.

For example, Windows Update can take advantage of transactions: When updates are applied, they are done as part of a transaction. That way, if something horrific happens in the middle of an update, the entire transaction becomes abandoned and you don't get stuck with some Frankenstein configuration.

Windows Setup takes advantage of hard links. A large percentage of the files installed by Windows are hard-linked to copies in the C:\Windows\WinSxS directory for reasons I do not understand, but the phrase "component store" may be part of it. (This is why asking Explorer for the size of the C:\Windows directory gives a misleading view of the actual amount of disk space occupied by Windows, because Explorer uses a naive algorithm which counts each hard link as a separate file.) Oh, and in Windows 7, the two copies of Notepad are now hard links to each other.

Ah, but one of the limitations of hard links is that they cannot span volumes. Some of the hard links out of the WinSxS directory point into places like C:\Program Files\Windows NT\Accessories\wordpad.exe, and this in turn requires that the Program Files directory be on the same volume as your Windows directory.

Sorry for the inconvenience.

Comments (53)
  1. Anonymous says:

    So, uhmm… I might be the naive guy here, but what's wrong with soft links?

  2. Anonymous says:

    @Vilx: soft links don't act the same as hard links (which are essentially normal files anyway, what we call a "file" is a disk area with one hard link pointing to it), and might confuse programs that expect normal files.

  3. Anonymous says:

    Couldn't "D:Program FilesWindows NT" be a reparse point to "C:Program FilesWindows NT" (or perhaps "C:WindowsProgram FilesWindows NT" to make things the same when not redirected)? Then only the MS Windows part of Program Files would go to C: (with hardlinks and transactions and all that stuff), and the rest (which is what I believe people want to move Program Files for) could go to D:.

    [The Windows NT directory was an example, not a comprehensive list. And some affected directories are not created by a default install. And I don't think you can create a hard link through a soft link, anyway. -Raymond]
  4. Anonymous says:

    @Raymond: Oh well, it would not work then. But I still think that the problem is that "Program Files" mixes Windows components and third-party components, and that what people want to redirect is third-party components (including things MS Office and the compiler/SDK as "third-party" here).

    [I suspect that Office and Visual Studio require you to install into the system volume for the same reason. -Raymond]
  5. Anonymous says:

    @Vilx:

    Deleting the original file when you have a soft link causes the soft link to stop working as the file is gone.  Deleting the original file when you have a hard link doesn't make a difference, as it's just one of two or more pointers to the file's contents.

  6. Anonymous says:

    One of the things I like about the UN*X world is that you can mount filesystems in virtually any folder.  In some cases files in the mountee folder are hidden completely by the root of the mounting file system but in other cases it is not.  The latter is effectively a "unioned" filesystem.  Some VM Appliances like SLAX take advantage of "unioned filesystems" to serve as a software packaging and installation solution.  The package comes as an ISO-like image that is mounted via the loopback device and then overlayed onto the root filesystem.  This makes software package installation and de-installation a no-brainer!

    Is such a capability available in Windows?  If so, you could store the packages for software applications on other volumes and just union-mount them into the C:Program Files folder.

    [I guess you could mount a VHD into a junction. But this assumes everything the package needs is in a single directory. So good-bye C runtime library! (Since that goes into C:WindowsWinSXS.) -Raymond]
  7. Anonymous says:

    [I suspect that Office and Visual Studio require you to install into the system volume for the same reason. -Raymond]

    It turns out they do not.

    Anyway, it turns out to be a low risk operation to change the location of Program Files via regedit after install. The few components directly affected by Windows servicing are already installed to the system volume. Any program that assumes all programs are in Program Files is already broken.

    What breaks is UAC's folder redirection, which I believe only redirects the original program files. Since any time you're doing something fancy you have to turn UAC off anyway, I just can't care about it.

  8. @ipowerscsi:

    reparse point.

  9. kinokijuf says:

    So why can't you rename it elsewhere on the system volume?

    ["Hey, let's add a feature that nobody will care about!" -Raymond]
  10. Anonymous says:

    ["Hey, let's add a feature that nobody will care about!" -Raymond]

    I'd care. I have had to have two copies of XP on the same volume before (see the old MSDN article How and When to do a Parallel Install of NT). Maybe I'll have to do that on some version of Windows again.

    [Yay, two different OS's both trying to manage the System Volume Information directory! What could possibly go wrong? -Raymond]
  11. kinokijuf says:

    Can you rename the Windows directory?

  12. Anonymous says:

    You seem to be into doing some risky business with Windows for no other reason than 'the heck of it'. We once had a guy like you working in our IS Department, he didn't last too long. I've always wondered what happened to him, probably landed a job at a smaller company who didn't know any better; what fun they will have when someone who isn't as risky takes a look at their setup!

  13. Anonymous says:

    I'll just have to remember that doesn't work anymore. It probably didn't really work on XP and my second install didn't live long enough to find out.

  14. Anonymous says:

    ah, "frankenstein configuration" brings back memories from when language pack installation failed on my winxp, so the system was partially english and partially slovak :-D

  15. Anonymous says:

    @Raymond: Thanks for the tip!  I didn't know what a VHD was (Virtual Hard Disk) and in my search I stumbled across the Microsoft Support page support.microsoft.com that explained Mountvol.exe.  It appears that using that tool you could mount a volume on top of another folder without having to give the volume a drive letter first.  New toys to play with!  I'm going to try it out in my VM.

  16. Anonymous says:

    Gee… Thanks.  Now I'll spend the rest of the afternoon playing Pinball.

  17. Anonymous says:

    Don't know if it has been asked before but why was the longer name "Program Files" chosen? Why not 8.3 compatible "Programs"? Was it because the Start Menu had to include a program group called "Programs" and people would get confused between the two?

    Offtopic but because it's covered in this post briefly: Although in theory Windows Update in designed to take advantage of transactions, most often on NT 6.x systems that I have serviced, if sommething does go wrong while updates are being installed like a hang, crash or BSOD, most systems (especially Vista systems) will get stuck in an unusable state as "Please wait while Windows configures updates…stage x of 3). With Windows 7, the situation seems to have improved slightly and I see less such issues (but not zero) and I can use DISM to revert pending servicing operations.

    ["Programs" are not "Program Files". MSOHEV.DLL is a program file. It is not a program. -Raymond]
  18. Anonymous says:

    Oh and I forgot to mention, the servicing stack in NT6 is a disaster IMHO and leaves much to be desired. But that is for a different day when it would be the topic.

  19. J. Edward Sanchez says:

    Raymond wrote:

    "Programs" are not "Program Files".

    And "Documents" are not "Document Files", "Settings" are not "Settings Files", and "Users" are not "User Files". Yet we used to have "Documents and Settings" instead of "Document and Settings Files", and these days we have "Users" instead of "User Files".

    It helps to just not think about too much.

    FWIW, I think putting "Files" in any folder name is redundant, since from the user's point of view, all folders contain nothing but files (and possibly subfolders). But my best guess on why "Program Files" was named so was to force developers to support long filenames everywhere — including installers.

  20. Anonymous says:

    @xpclient:

    "if sommething does go wrong while updates are being installed like a hang, crash or BSOD"

    Uninstall third party antiviruses. Seriously.

  21. Anonymous says:

    "I still think that the problem is that "Program Files" mixes Windows components and third-party components -Cesar"

    "[I suspect that Office and Visual Studio require you to install into the system volume for the same reason. -Raymond]"

    Then the solution is to build a culture of keeping OS components separate from application components.  We live in an age of 30GB system SSDs with 2TB secondary storage.  Requiring a 10GB Visual Studio install to go on the OS drive is not a good thing.  (Yes, Visual Studio lets you choose an install directory, but most of the components ignore that.  Check the space needed on system vs install drive.)

    As a benefit, all the work needed to support servicing of "Microsoft components which are not part of the OS" installed on a secondary drive could easily enable WIM-based servicing of third-party applications.

  22. Anonymous says:

    Yet again, we see that Windows is years and years behind any modern Unix system. No self-respecting Unix OS would force programs to be installed on the "system volume". Raymond's apologetics notwithstanding, Windows has become increasingly brittle over the years.

  23. Anonymous says:

    Let's separate this discussion into parts.

    Microsoft needs to service Windows and any parts of Windows.  Sharing what seem like "common files" between various Windows installations was a non-starter since then these files could change out of band (certainly at a reboot boundary where the user booted to an alternate OS but also since the brighter folks out there may want to point things to network drives or perhaps a separate volume where you revert to a snapshot, not coordinated with the patch level of the OS).  Software installation was lengthy and fragile and authoring updates like patches was also error prone since the patch had to account for all the possible ways that the software was (legally; not in the legal sense) configured on the target.  It often involved custom code written just for the patch which therefore didn't get broad testing.

    For Vista we decided that this had to be fixed and so we moved to a system where we maintain a model of how the system is supposed to look and then compute the actual changes by evaluating changes to the model.

    At this point in the conversation, the only real requirement imposed is that the Windows owned files are on the boot volume.  Unfortunately since all the namespace references traverse through Program Files, we were kind of stuck with mandating that Program Files stay on the boot volume.  (Actually it's a little weaker, we only require that the Program Files is unique to the Windows instance.)

    Next was that with this spiffy new faster more reliable servicing engine, we wanted to avoid reinventing the wheel w.r.t. rollback and error handling so we took the dependency on the transactional filesystem feature.  This mandates NTFS over FAT.

    For Vista SP1 (a/k/a Server 2008), we addressed deficiencies associated with the user profiles being on a different (but still dedicated) volume.  This required for terminal server scalability scenarios.

    That's the end of that part of the discussion.  The technology is almost there.

    But now we're at Raymond's classic "every feature starts with -100 points" point.  Someone would have to code relocating the program files directories (two of them on amd64) during setup and/or later and people would have to test it.  Disk space usage would increase unless we had a file repository on both the boot drive as well as the program files drive.

    Shockingly, the end result is that because there are limited resources and limited amount of risk that a given Windows release can absorb and this feature hasn't made the bar thus far.

    Raymond's points are correct and are advantages of the system but aren't necessarily the justification for it.  (Apologies to the community for not reviewing this blog entry before it was posted but I don't think there's anything far off center here…)  Really this feature didn't happen because of the -100 point rule.  (since it would have expanded the test matrix for Vista, it started at more like -1,000 or -1,000,000 points.)

    w.r.t. winsxs, application containment:

    Well actually the intention is for applications to carry the components with them and the winsxs mechanism is only intended to be used for either (a) components which must be installed system-wide due to configuration beyond the set of files contained within the component or (b) security patches for shared components where rogue applications are forcibly brought up to minimal version conformance if trying to launch with a privately carried buggy version of some shared components.  In the end, there was a certain level of distrust that the versioning / binding system was trustworthy to deploy security patches and thus instead a policy of keeping files in well known locations where they could be centrally updated was adopted.  You can see this in how CLR assemblies are updated without changing their assembly versions.  We managed to defend against this for the versioning platform in Windows but it doesn't help that the vast majority of Windows components require configuration beyond their files and so at least we were able to use the same binding and versioning concepts to build a versioning model for components in Windows.  so there's no technical reason that the CRT has/had to be in the WinSxS directory but too many people were nervous about what it meant to have copies laying around in application directories if in fact there was a security fix.  People may recall the firedrill around another component which was distributed in the application directory and where the original version had a security defect.

    w.r.t. patch reliability:

    I'm not saying that things are perfect but they are literally orders of magnitude better than they were in the past (XP and prior) and for the first time, uninstall (of other than the most recently installed patch) works.  Really, uninstall hasn't worked in most installation systems previously.  Now it works reliably enough that uninstall can be part of the manufacturing process.

    Mike

  24. Anonymous says:

    @Michael Grier:  Thanks for that comprehensive explanation.  It's useful to hear the reasoning behind things like this.  Raymond does a lot of that too, and it's useful to hear another voice.  Thanks.

  25. Anonymous says:

    Maybe you meant %SystemDrive%:Program Files ? Because I can very well have C: drive as something and install Windows to D: drive, in which case the program files folder resides on D: drive. Or I am missing something?

    [Welcome to the Nitpicker's Corner. Population: You. -Raymond]
  26. A large percentage of the files installed by Windows are hard-linked to

    copies in the C:WindowsWinSxS directory for reasons I do not understand

    I am often astonished by the number of technologies Raymond has his head around.  It's a relief to know that understanding SxS does not come naturally to him either; I don't feel quite so stupid having to read up on it every 12 months when it comes knocking!

  27. @Danny:

    Yes. Unless it's an upgrade of an existing install, Vista+ will make whatever disk you install on, C:.

  28. Anonymous says:

    @Ben Voight: I'd say we currently live in an age of 100+ (and rising) GB system SSD:s, so this problem will go away on on its own very soon.

  29. Anonymous says:

    [Yay, two different OS's both trying to manage the System Volume Information directory! What could possibly go wrong? -Raymond]

    Presumably when you're installing OS's on multiple partitions they avoid conflicting with each other's System Volume Information directories, although you might want to be able to share them in some cases, such as volume shadow copies.

  30. Anonymous says:

    @NB: not necessarily upgrade – as long as you start the installer from existing Windows installation (even if it's not an upgrade), the drive letter assignments will be kept (thus my Vista install is on V: and Windows 7 is on W: – and neither was an upgrade).

  31. Anonymous says:

    [I guess you could mount a VHD into a junction. But this assumes everything the package needs is in a single directory. So good-bye C runtime library! (Since that goes into C:WindowsWinSXS.) -Raymond]

    No, this assumption doesn't hold: a package needs the OS and the system DLLs. Other packages like the CRT should never be incorporated/included in a package (so: good-bye MSM, and good-bye outdated and unfixed "local" DLLs), but instead a dependency declared/defined. NT6.x is already broken down into many independent packages which all reside in %SystemRoot%WinSxS. The missing piece is but a package manager.

  32. Anonymous says:

    RE Windows setup always installing on the C: drive. This is another changable setting in the Windows unattended setup. So a fresh install with no other Windows installs and not starting Windows setup from another install can be installed on any drive letter (probably not including A: or B: for compatability reasons).

    In testing this out I did naturally end up with Windows on M: and since it was a VM with no other virtual hard disks, that was the only lettered hard drive partition.

    Stefan Kanthak:

    And what happens if a situation which has arisen in the past actually strikes an application on the system. An updated version of the CRT gets released and all of a sudden, an application which once worked no longer works. Doing what you say will not give a chance for this application to be fixed easily, it would end up having to be tested for the bugs, patched and then a new version of the executable distributed again, but this could be a program that the source is no longer available, or the developer doesn't care about anymore. So focing the CRT to be global would thus force either Windows never to update the CRT or just break the application. Allowing the CRT to be local means that all you have to do is copy the appropriate msvcrx.dll file to the application's directory and that fixes it.

    I think the biggest thing to remember is that the CRT on Windows is not treated specially, it isn't really counted as a system DLL. The only reason why msvcrt.dll exists as it does is because it is what the Windows applications themselves use and so it is protected just for Windows stability. If your view of how the CRT should be comes from the lunix side, then you should just forget about it. Windows' compilation environment just treats them as dependencies.

  33. Anonymous says:

    Re the "linked into" comment:

    The image-layout technology during setup (WIM, imagex) is responsible for extracting blocks of bytes to names and linking them as necessary. The names and links were discovered during WIM creation time then modified during manufacturing, re-capture, and many other steps between build-creation and hitting your physical disk. The entry saying "these 50kb are c:pffoo.dll and c:windowswinsxsfoo.dll" is identical to "these 50kb are c:windowsfoo.dll and c:pffoo.dll", so no effort is put into keeping it always windows => pf.  You're /likely/ to get pf => windows in images, just based on the order the original image was traversed.

    During updates, however, the order is often "place new-version file into c:windowswinsxs, then link from there to where it's going." So once a file has gone through an update cycle GFIBHEx is more likely to return "c:windowswinsxsfoo.dll" as the "primary" name than "c:pffoo.dll". (Note the number of weasel-words; don't take a dependency on that.)

    Curiously, we ran across some parts of the system using GetFileInformationByHandleEx and FileNameInfo to do things like "where are related files for this file?" GFIBHEx uses filesystem data to retrieve that information, not the name used to open the handle you passed it. (That's long gone.) There was nonzero effort requried to keep those technologies working.

    You can always use FindFirstFileName (msdn.microsoft.com/…/aa364421(VS.85).aspx) to iterate through the alternate names for a file path.

  34. Anonymous says:

    | An updated version of the CRT gets released and all of a sudden, an application which

    | once worked no longer works. Doing what you say will not give a chance for this

    | application to be fixed easily, …

    Wrong!

    All supported versions of the CRT are installed side-by-side in WinSxS.

    1. If an application needs a certain version of the CRT, then tell Windows about it in the applications .MANIFEST
    2. If this certain version of the CRT is but updated or replaced due to vulnerability fixes: do you REALLY want to use this application any longer? ITS INSECURE!

    3. If an application has no .MANIFEST then it was buggy from it's creation and NEVER should have passed QA.

    4. If an administrator but still wants to support such buggy or even insecure applications he can still place DLLs "applocal" and create the necessary *.exe.local.

    In short: an application MUST NOT be distributed with any foreign components/packages, but reference them (from WinSxS, …), because these foreign, "applocal" installed components/packages need (security) updates too. BETTER BE SAFE THAN SORRY.

    JFTR: How many developers/companies ship updated versions of their products when a vulnerability is found in a static linked or "applocal" installed component? And how long does it take if they do? How long do they put us, their customers at risk? Knowingly!

    navigare necesse est^W^W^Wit's REALLY time for serious software engineering!

  35. Anonymous says:

    @Stefan Kanthak

    Not all supported versions of the CRT are installed in WinSxS. They reverted back to the old method in VC2010, so the latest version is just in System32, as you would guess, it is also no longer refered to in the application manifest either. So go ahead and apply what you said to that.

    Also if there is a vulnerability in a critical business application and you can no longer fix it because the developer is either no longer in business or the business lost the source. Are you seriously saying that you would just stop using the critical business application?

    Unfortunately, what you are saying sounds good on paper and in a controlled environment, but this is the real world, there exists things known as idiots. Unfortunately, these entities known as idiots have managed to produce software that entire businesses rely on. The last place I worked relied on a web application which was a clusterf… of badness. In the time I worked there, I reported seventeen vulnerabilities and well over a hundred bugs, and non of them were fixed, in fact, they introduced more, and they still kept using it. So instead of preaching what must be done here, because really, none of us would disagree, start preaching to the managers and the businesses who supply the money. Who want things done last week even if it means skipping all sorts of tests and are, erm, idiots.

  36. Anonymous says:

    Stefan: "That software doesn't have a manifest. It's buggy and you should stop using it."

    Other Guy: "But we rely on it for our business to function. And it was written ten years ago… manifests didn't even exist back then."

    Stefan: "But it's INSECURE! Either get an updated version, or find a better program."

    Other Guy: "The software cost us $40,000. I can't justify that to the powers that be when the current software performs every function we want it to. Heck, I'm not even sure the company that wrote it is still updating it."

    Stefan: "Well it's outdated and insecure. You should stop using it immediately and switch to something that is secure."

    Other Guy: "We know the other products in this market – none of them fit our needs as well as the existing product. Besides, we've got 200 users that use this software daily, we've got internal manuals we've written about the software, we have custom-written software that interfaces between it and our finance package etc etc. It would cost $40,000 to replace, would require updated servers to run it, would need hundreds of man-hours rewriting the finance link software, tens of hours rewriting manuals, hundreds of hours plus aggravation retraining staff, it's a critical system so we'd need to plan months in advance, then pay the IT guys double-time to install it out of hours. Then we'd spend the next few months dealing with teething issues and working around whatever problems we find. Hopefully none of them put our data at risk, or create customer-facing problems."

    Stefan: ???

  37. Anonymous says:

    @Crescens2k: Sounds like some articles at TDWTF…

  38. Anonymous says:

    @Stefan Kanthak: "If this certain version of the CRT is but updated or replaced due to vulnerability fixes: do you REALLY want to use this application any longer? ITS INSECURE!"

    What if the vulnerability was in a function in the CRT that application does not use? The CRT has hundreds of functions, no application will use all of them.

  39. Anonymous says:

    @alegr1

    For how much money we talk about?

  40. Anonymous says:

    | Other Guy: "But we rely on it for our business to function.

    If your business relies on it, then you sure have a service contract with the manufacturer/programmer!

    And it was written ten years ago… manifests didn't even exist back then."

    1. Wrong. Windows XP was released ten years ago and introduced manifests.
    2. The MSCRT (for example) that installed into WinSxS and needed manifests was released in 2004/2005 and 2007/2008.

    Yoou should have done your homework!

    | Other Guy: "The software cost us $40,000. I can't justify that to the powers that be when the current software performs every function we want it to. Heck, I'm not even sure the company that wrote it is still updating it."

    That's why you resp. the powers that be made a contract with that company to ensure maintenance and updates! You spent $40,000 but forgot the service contract?

    | Other Guy: … It would cost $40,000 to … (and more weaseling around …)

    It might cost you WELL more than just $40,000 if someone exploits this insecure software and gets access to your crown jewels (or even destroys them) or just sabotages its function. Then you have a REAL problem. If you process personal data you'll have to inform the authorities after a breach. And might be faced with legal action. You KNEW that your software was insecure. It was your task to ensure safe and secure operation. But you did nothing to fix that insecurity.

  41. Anonymous says:

    | What if the vulnerability was in a function in the CRT that application does not use?

    | The CRT has hundreds of functions, no application will use all of them.

    If only ONE of the installed applications uses the vulnerable function you'll have to act: either update/remove the vulnerable CRT OR remove that (vulnerable) application.

    If not (but how do you know? Do you have the source?), you can carry on. But don't forget: every time you install or update one of your applications you'll have to check again.

  42. Anonymous says:

    | They reverted back to the old method in VC2010.

    Right, I forgot about that.

    But since you know that: you evaluated that business critical software you use which relies on VC2010 and made service contracts with both its vendor and the vendor of the components it uses (Microsoft)?

    | Are you seriously saying that you would just stop using the critical business application?

    If I can no longer operate that business critical application in a safe and secure way I'll shut it down. Remember: its business critical, so it has to be safe and secure!

    [You're not even talking about a security vulnerability that can be proved to exist. You're shutting down the company based on a triple hypothetical! "Maybe this program uses a function that has a vulnerability, and maybe this vulnerability is exploitable, and maybe the exploit can be triggered from outside the company." I hope all the employees you just fired will understand that this was the only safe option. -Raymond]
  43. Anonymous says:

    "But since you know that: you evaluated that business critical software you use which relies on VC2010 and made service contracts with both its vendor and the vendor of the components it uses (Microsoft)?"

    Alas, this is another place where idiots come in. You can never put it past some people to use the managers nephew to write the business critical software. Or use an employee to do the writing and they go and move jobs, 10 years later the critical business application suddenly starts showing interesting issues, but nobody knows where the person who wrote the application is anymore and they either took the source with them or it is so bad nobody can understand it.

    This is real life, you don't always have support contracts or means to do proper bug testing. If you go to The Daily WTF you will read all sorts of stories about this. Just to emphasise, THIS IS REAL LIFE.

    As for shutting down the business critical application, you really are talking like you have never worked in a real world environment with idiots. Do you think a manager would be happy you shut down the business critical application just because it is insecure? You are more likely to get a warning or get fired. If you are a manager yourself, then you will have to explain to all of your employees why they now have to do everything the hard way, or even why they can no longer do some things. You have to explain to your customers why you can no longer provide the services, and watch them go elsewhere and then you start losing lots of money. Or if you are a not for profit organisation, then you can watch as your funding gets taken away as someone else who is much more capable at doing the service which you are no longer capable of doing comes along. Remember: it is business critical, so a good part of your operations depends on it, so by shutting it down, you are effectively crippling your business.

    Would you be happy as a customer if you went to a supermarket and they refused your service after spending lots of time getting your shopping because they shut down all of their servers because of an issue? My supermarket doesn't do that, there is still one major issue with the self service checkouts that if you really know what you are doing you can easily get free items, and this is one issue in a series of other major issues which the supermarket never stopped using the self service checkouts for. Also, another store near me recently was forced to shut for half a day recently due to major problems (the stock control server died pretty badly), when I passed it that day, you could hear a few people being really annoyed, some even were throwing around a few insults. So it annoyed the customers, how much in profits did that store also lose in the afternoon? Quite a bit I'd imagine, so now what would be the stock holders reaction to the loss in profit if you shut down the entire chain because there was a security vulnerability found in the systems and you decided to shut them all down? I would think you would see some rather annoyed people.

    So unfortunately, what you say really does make a lot of sense, but applying it to real life doesn't work. Operating a money making business means you just can't stop because there is a vulnerability in something since you will lose money, lose too much and you go under. Operating a business which provides a service to people also can't just stop because there is a vulnerability because people rely on you and they will go elsewhere, meaning you go under. Also just shutting down the software because of a vulnerabulity doesn't mean that you can get it back any time soon, in your scenario, it would have to be triaged, tested, fixed, QAd and then deployed. How long would this take? From what I can tell, it takes Microsoft months to go through this process for Windows vulnerabilities, so would you shut down the business for months because of a vulnerability? If not then would you rush it? If you rush it what steps would you skip?

    I'm not entirely sure, but isn't one of the most important parts of running a business actually staying in business? If you shut down your entire business because the critical software developed issues, then you are just asking for your company to go under.

  44. Anonymous says:

    [You're not even talking about a security vulnerability that can be proved to exist. You're shutting down the company based on a triple hypothetical! "Maybe this program uses a function that has a vulnerability, and maybe this vulnerability is exploitable, and maybe the exploit can be triggered from outside the company." I hope all the employees you just fired will understand that this was the only safe option. -Raymond]

    Of course I do!

    "If I can no longer operate that business critical application safe and secure" means:

    – it's definitely vulnerable

    – it's definitely exploitable

    – there is a non-neglectable risk that some bad guy (which may come from outside, but can already be with the company) can run the exploit.

    Cf. diginotar.nl: they WERE shut down!

    ["Safe and secure" is rarely an absolute. You seem to treat it as a boolean. -Raymond]
  45. Anonymous says:

    "Operating a money making business means you just can't stop because there is a vulnerability in something since you will lose money, lose too much and you go under. Operating a business which provides a service to people also can't just stop because there is a vulnerability because people rely on you and they will go elsewhere, meaning you go under. Also just shutting down the software because of a vulnerabulity doesn't mean that you can get it back any time soon, in your scenario, it would have to be triaged, tested, fixed, QAd and then deployed. How long would this take?"

    Welcome to real life!

    Or as Charles Darwin put it: "survival of the fittest".

    You'll lose money (your money, or your customers money?) when you stop your business, and you'll lose money (your money, or your customers money?) if you continue your business and someone exploits the vulnerability. You'll have to evaluate both the risk and the possible loss(es).

    And yes, creating reliable, safe and secure software takes quite some time: until it's done, properly done.

    That's what software engineering is all about!

  46. Anonymous says:

    "Or as Charles Darwin put it: "survival of the fittest"."

    And that alone means that unless it is a vulnerability which is easy to trigger with 100% success, you don't shut down the business critical software. Customers are selfish, they will go elsewhere because of the slightest things. If this kind of vulnerability is found, but only a handful of trustworthy people find it, then you keep going regardless with the vulnerability still present, because customers are much more important to survival. If the vulnerability is externally exploitable, then you usually do your best to minimise the damage and carry on, rushing fixes and then dealing with the fallout later.

    "And yes, creating reliable, safe and secure software takes quite some time: until it's done, properly done."

    The software is written by humans, so is it really reliable, safe and secure? As Raymond rightly said ""Safe and secure" is rarely an absolute". Just because you haven't found any problems in the software, doesn't mean that no problems exist. It is the problems that you don't know exists which will always be the biggest issues, someone else could find it and start exploiting it and it will take you some time to figure it out. So this means that just running software is enough to introduce the uncertenty of bugs into the environment, and would you just not run the business critical software because of the potential of bugs? But at the same time, assuming that a piece of software with no known bugs is safe and secure is also extremely foolish. The only applications that you can guarantee is safe and secure are the trivial ones, like hello world, even if you mathematically prove the safety and security of the algorithms used, you can't prove the implementations are bug free, and no matter how much you test you will always miss corner cases which could be where the bug is residing. So is any complex software really safe and secure?

  47. Anonymous says:

    ["Safe and secure" is rarely an absolute. You seem to treat it as a boolean. -Raymond]

    I dont, even if it seems so.

    One of the very simple metrics is: if an attack gains more than it costs the attacked system is insecure.

    Now you'll have to evaluate gains and costs…

    OTOH: your company fixes vulnerabilities even if there are no known exploits yet. The fixes but can be analyzed then and exploits built. What is your advice for a customer whose business critical software needs this fix, but breaks if the fix is installed?

    [Customers already know what to do: Complain to Microsoft that the security fix broke a program, and ask for a revised fix that preserves compatibility. -Raymond]
  48. Anonymous says:

    | And that alone means that unless it is a vulnerability which is easy to trigger with 100% success, you don't shut down the business critical software.

    How do you measure 100% success? Just like 100% security?

    | That's what software engineering is all about!

    Please inform yourself about software engineering. Or engineering.

    This is about "how to build (complex) systems which meet their specs". And about "how to write specs" to define your goals/requirements, like reliability, safety, security, integrity. And the test cases.

    If properly done, even complex software meets their specs and is then "safe, secure, …" according to the requirements.

  49. Anonymous says:

    | would you just not run the business critical software because of the potential of bugs?

    That was NOT the prerequisite!

    You came up with "An updated version of the CRT gets released and all of a sudden, an application which once worked no longer works."

    My assumptions are:

    1. this update fixes a vulnerability (which almost all updates of the CRT do);
    2. the business critical software uses the vulnerable subroutines of the CRT.

    So you have an ACTUAL vulnerability here, not just a potential one.

    JFTR: there are some thousand potential (really silly, therefore easy to fix) bugs/vulnerabilities in the Windows registry alone (from 2000 to 7).

    If you want to have some real vulnerabilities of this kind just install .NET Framework 2.0, then uninstall it.

  50. Anonymous says:

    I wish I lived in the same world that Stefan does, instead of having to maintain customer networks that still run business-critical programs written in Clipper (then again, maybe I don't – I'd probably have less work to do).

  51. Anonymous says:

    @Butch: And like GetProfilesDirectory(), %ProgramFiles% cannot refer to multiple directories and whould break if you try to adress programs in different directories, thus all batchfiles which use this variable to refer to programs would break.

    Then use %ProgramFiles(x86)%

  52. Anonymous says:

    | Customers are selfish, they will go elsewhere because of the slightest things.

    Right. If customers come to know sloppy a company works with their personal data, how bad their personal data is protected there or how vulnerable their IT systems are, they'll most probably run.

  53. Anonymous says:

    @Kanthak:

    Where do they run?

    Please explain the success of:

    • Apples IPad (Did store where you (and it) was)
    • Facebook/StudiVZ/… (Default: everything shared, and always adding new ways to expose your data you have to disable, and won't ever delete your profile)

    • What about SWIFT / PNRs and other personal information submitted by the EU to the USA where it is stored forever and available to any official willing to peek)

    • What about all the security laws trying to protect you against your personal freedom and freedom against government harassment (Applebaum anyone?)

    (This is a small non-representative sample, which could be expanded for many pages.)

    BTW: That's all going a bit far afield…

Comments are closed.