What’s the difference between the Windows directory and the System directory?

(Windows was released on November 20, 1985, twenty-five years ago tomorrow. Happy birthday!)

You have GetWindowsDirectory and you have GetSystemDirectory. Why do we need both? They're both read-only directories. They are both searched by LoadLibrary. They seem to be redundant. (There are other directories like GetWindowsSystemDirectory which are not relevant to the discussion.)

Back in the old days, the distinction was important. The Windows directory was read-write, and it's where user configuration settings were kept. See for example, GetProfileInt, which reads from WIN.INI in the Windows directory, and GetPrivateProfileInt, which defaults to the Windows directory if you don't give a full path to the configuration file. This was in the days before user profiles; the Windows directory acted as your de facto user profile directory.

Meanwhile, the bulk of the Windows files go into the System directory. Windows was designed so that it never wrote to the System directory (at least not during normal operation, outside of application install/uninstall or other system maintenance).

This separation of duties (Windows directory: writeable, users store their stuff there; System directory: read-only) permitted a number of configurations.

Each computer had a Windows directory and a System directory on a local drive (either a floppy disk, or if you were rich, a hard drive), and the System directory was a subdirectory of the Windows directory. This was how most people ran Windows. Even though the System directory was physically read-write on the local drive, Windows itself never wrote to it.


Each computer had a Windows directory on a local drive, but the System directory was on a ROM-drive. As you might guess, a ROM-drive is like a RAM-drive, except it's in ROM. In the parlance of kids today, "Think of it as a permanently write-protected SSD." That's right, Windows was using SSDs over 25 years ago. ("You kids think you invented everything.") Once you burned the System directory into a ROM-drive, you didn't have to waste valuable floppy disk or hard drive space for all those files that never changed anyway.


Each computer came with just a Windows directory, but it also had network drivers (wow, fancy, a computer that could communicate with other computers), and the AUTOEXEC.BAT file mapped a drive letter to a network share maintained by your company's IT department. That network share might be set up like this:

M:\SYSTEM System directory files
M:\WINWORD Word for Windows installed here
M:\123 Lotus 1-2-3 installed here
... etc

All directories on that network share were read-only. Everybody in the company connected to the same share, so every computer in the company was using the same physical files for their System directory as well as their applications. If the IT department wanted to upgrade or install software, they could just kick everybody off the server (or, if they were nice, wait until everybody logged off), mount the M: volume read-write, upgrade or install the software, and then set M: back to read-only. When everybody logged back on, bingo, the new software was installed and ready to use.

Fully network-based

The computer boots off a ROM, a floppy disk, the local hard drive, or off the network. A drive letter is mapped to a network server, which contains both the Windows directory (a different one for each user) and the System directory. Windows then runs completely over the network. User files are stored in the Windows directory (on the server); system files are retrieved from the System directory (also on the server). This was commonly known as a diskless workstation because local drives are not used once Windows has booted. Even paging took place over the network.

Given all the possible arrangements, you can see that there was no requirement that the System directory be a subdirectory of the Windows directory, nor was there a requirement that either the Windows or the System directory be on your boot drive.

I suspect many (most?) of these configurations are no longer supported by Windows, but at least that's the history behind the separation of the Windows and System directories.

Comments (30)
  1. db2 says:

    "Even paging took place over the network."

    I wish I could post a horrified reaction image on here.

  2. Brian G. says:

    Happy Birthday, Windows!  Thanks for the info, Raymond.  I love little historical bits.  As a sorta-related aside, I wanted to let you know that perusing your archives, you essentially single-handedly turned me from mildly anti-MS to an apologist for your folks' software and practices.  Thanks for fighting the good fight, seeing the historical reasons for things always helps put matters in perspective.

  3. John says:

    @Brian: I think most people take issue with the business practices, not the technological ones.  You can still dislike the former while appreciating the latter.

  4. Michael Kjörling says:

    So why were, at least in Windows 3.x, lots of if not all bundled applications, including the Program Manager, File Manager and the almighty WIN.COM, placed in the Windows directory? Given this reasoning, wouldn't it have made a lot more sense to put all of that in the System directory, and perhaps a tiny Windows loader stub only (that in effect was little more than a short batch file, responsible for nothing more than passing execution on to the next loader stage) in the Windows directory, simply to make it easier to find? The disk space cost of such a tiny executable would have been minimal, even in the light of the hardware of the day; I imagine that it could have been done within a few hundred bytes.

    Looking at old Windows 1 screenshots, it appears that lots of drivers, executables and fonts were put in the Windows directory even back then, and although it seems to have been cleaned up in the interim, at least some applications resided in the Windows directory also in Windows 2. That goes rather contrary to the "the Windows directory is a user profile directory, the System directory contains the system binaries" sentiment expressed in this post, as well as GetPrivateProfile*() et al. I'm curious what your comments on that are.

    [Everything other than the "traditional" configuration was sufficiently fringe-y that most developers were simply unaware of them and mistakes just like the ones you enumerated. -Raymond]
  5. LocalH says:

    @db2: I'm going to go ahead and guess that it wasn't that bad – smaller swap files combined with smaller applications results in less overall swap access, and back in those days I'd guess it didn't impact performance as much as it would nowadays.

  6. Joshua Ganes says:

    I also enjoy your articles that look back on the way things once were, and explain some of the technical decisions in context. 25 years is an awfully long time in computer time. I'm curious to know the most significant historical design decision that you would change today if you could.

  7. Gabe says:

    db2: I remember back in high school, the computer teacher suggested that we could run Windows on our pre-Ethernet network of 20 dual-floppy (360k) 8086-based PCs with monochrome VGA monitors. The idea, of course, was to house all the files on the file server's 40MB HD and do all of the paging to that. You can imagine my horrified reaction at the time. Fortunately I was able to talk him out of such nonsense.

    I thought I had successfully repressed that memory, but it all came back while reading today's post.

  8. David Jones says:

    db2: "Even paging took place over the network."

    Not in my experience. I remember doing an experiment: remove the HDD from the computer, and prepare a floppy with DOS, autoexec.bat and the network drivers. Boot from that, then start Windows 3.0 from the network server.

    In my particular combination, paging took place…

    …to the floppy!

    I'll take network paging any day.

  9. Rick C says:

    @David Jones:  that's OK, you could just page to this: http://mac-guild.org/raid.html

  10. Roger says:

    Since you brought up the topic of Windows 1, I need to report a bug in it.  When you ran paint and went to save the file you got a dialog with a single editable text field to type the name into.  This teenager at the time decided to hold down the 'a' key to see how many it would let me enter.  Eventually getting bored after hundreds and perhaps thousands of them I pressed enter.  The screen froze and hard disk light would come on briefly every few seconds.  Eventually I reset the machine to find out that most of the contents of the root directory had been deleted.  Thankfully those were the days when you could just change the first byte of a name in order to undelete it, and my dad never found out.

    TLDR: Windows 1 has a buffer overflow on the file save dialog.

  11. configurator says:

    @db2: Don't forget in those days networks were a bit different. You could have a network with 10 computers where the only access was for these directories – no other communication was yet possible. Combine that with very small files, and even a slower network of those times is not contented. Having to buy only one hard drive for the entire office is definitely a plus in that case, even if it's a bigger one.

  12. John Topley says:

    @LocalH: I remember using a copy of Windows 3.1 that was running over a Novell Netware network and I can assure you that it was pretty painful!

  13. Joshua says:

    All those programs were in the Windows directory by default. They could be moved safely.

  14. Michael Kohne says:

    I suspect that even when these configurations were properly supported, half of them ended up not working very well anyway – because of laziness on the part of third-party developers. I still don't dare change software install directories or make the primary drive something other than C – Windows doesn't care, but boy howdy does a lot of software break!

  15. ERock says:

    Can anyone suggest any additional reading for ROM drives? I've inherited a stack of EPROMs and I'd love love love to give that a shot for one of my 2011 hardware projects.

  16. DWalker says:

    I still get annoyed when certain software insists that it needs to be installed into a short folder name in the root of the C drive.  Some software breaks if there are any spaces in the program's path name.  Spaces have been in path names for, what, 15 years now at least.

  17. Marquess says:

    Happy Birthday, Windows! (except in Nebraska)

    Am I correct in assuming that this writable Windows/non-writable System distinction died already with Windows NT? Because there's this directory named “config“ in there which probably wouldn't take to kindly to being read-only …

  18. Joshua says:

    @DWalker59: You may see a bit more of that behavior as some software vendors have had to take semi-drastic steps to run under UAC.

    Our own used to install to C:Program Files<Application Name>, now it is C:Programs<Application Name>. Installing to program files with UAC on is still a good way to get our software to blow up rather spectacularly a few months or years later due to a bug in folder redirection we were never able to fully qualify.

    Cygwin is another. The default is C:Cygwin. Spaces are fine. Running with UAC on is fine. Installing to Program Files with UAC on is not.

    The general point here has nothing particular to do with UAC, but rather that when Microsoft changes some fundamental attribute of Windows, some applications basically don't tolerate it and the makers will take the simplest path to getting it working again.

    @Marquess: GetWindowsDirectory() when called from an NT windows returns a directory within your profile.

  19. laonianren says:

    Joshua wrote "GetWindowsDirectory() when called from an NT windows returns a directory within your profile".

    It should have done but it doesn't.  At least, not on client NT systems through Windows XP.  Maybe terminal services, Vista or Windows 7 do something different.

  20. Gabe says:

    Am I the only one who gets the http://www.microsoft.com/…/keyevents.doc link redirected to http://www.microsoft.com/…/default.aspx Does anybody have a corrected link?

    [Link fixed. Ah, permalinks that aren't. -Raymond]
  21. Neil says:

    "Even paging took place over the network."


    I wish I could post a horrified reaction image on here.

    Network disks were faster than local disks. Yes, really. After all, you spent $$$ on a decent SCSI setup, rather than crummy MFM. In theory the Win9x series still supported diskless workstations, but by then hard disks had got fast enough to make it unnecessary.

    @laonianren: Terminal services definitely changes it. So getting the "real" directory of Explorer.exe is harder than you would think. (And no, we can't just launch "Explorer.exe" since that exposes you to current-directory-based attacks.)

  22. configurator says:

    @Neil: I found that the easiest way to launch explorer, assuming you want to open a folder, is to simply launch that folder.

  23. Daniel Colascione says:

    Nifty. Unix machines were designed around a similar idea: /usr could be read-only and shared between machines of the same architecture (and /usr/share between machines of different architectures). It's interesting that the Windows designers were thinking along similar lines.


    Yet another reason for removing the implicit "." from %PATH%

  24. Dave says:

    @Gabe: The idea, of course, was to house all the files on the file server's 40MB HD and do all of the paging to that.

    When I was at high school, we had C64s, with six (or eight, too long ago) of them sharing a single 1541 through a multiplexer.  Sometimes everyone in a row of C64s could actually get their program loaded by the time the one-hour class was up.

  25. Dave says:

    @Neil: Network disks were faster than local disks.

    Unless it's a 1541 through a VIC Switch.

  26. Pi says:

    Brian G.

    "As a sorta-related aside, I wanted to let you know that perusing your archives, you essentially single-handedly turned me from mildly anti-MS to an apologist for your folks' software and practices."


  27. NB says:

    Hey, I share my birthday with Windows!


  28. Miral says:

    If I recall correctly, at high school the approach taken was to use a shared read-only System folder on a network drive, and a local read/write copy of the Windows folder — but this was destroyed and replaced each time Windows was started up.  Because students couldn't be trusted not to totally mess up their environments.  (Mind you, to be fair, most students didn't have individual logins at that point; instead everyone logged in with which room they were in.  I was one of the few exceptions, and I altered my copy of the start-windows script so it kept my personal settings intact.)

  29. Neil says:

    @Dave: C64s had local disks? The few I saw only used tape.

    @configurator: sorry, but I need to select a file in the folder too.

  30. Miral says:

    @Neil: Yes.  I have two disk drives for my C64.

Comments are closed.

Skip to main content