Why they should store the system files in Windows folder and System32 folder?

[coolxpguy]

Hi Friends,

I want to know why they store the system files into windows folder as well as system32 folder in XP and other microsoft OS. I want the details of which kind of files will be stored into both folders. Is there any article related to this topic. I search this doubt through many search engine. I cant get answer. If you anybody knows ans for this, Please reply for this.

Thanks

 

[Jon855]

I guess it is because the way they, the MS wants their system files to be stored. You are almost asking in the sense why do we store gasoline in the gas tank? Because it is meant to be and that's what it was created for?

 

[Brazen]

Why DO we store gas in the gas tank?

 

[kamper]

I think it's a valid question, since it's markedly different than the unix standards. *nix has it's system files all over the place (/usr/bin /usr/lib /etc /dev ...) and leaves the user with a smaller, defined space to keep their files, while windows basically gives the whole space to the user with the exception of c:\windows or c:\winnt. I've always actually thought that the windows way was more comfortable, but it doesn't lend itself to restricted access users and multiuser systems as well as *nix.

 

[imported_BikeDude]

Good question.

My guess: Windows NT stored everything under %systemroot%\system32 (and subdirectories). However, older applications expect to find certain files in the %systemroot% directory.

So you'll find notepad.exe both under %systemroot%, as well as %systemroot%\system32. However, explorer.exe is only found under %systemroot%. To me that looks like the exception as (on my system) there are 23 executables under %systemroot%, compared to 400 under %systemroot%\system32 (10 vs 347 on a more recent installation of 64-bit Windows).

Most of the OS stuff thus belongs under system32, but IMO e.g. third-party uninstallers ought to be put in %systemroot%.

%systemroot%\system (sans "32") is obviously for 16-bit stuff, so atleast that one can easily be explained.

Up to NT 4, NT didn't even come with explorer.exe and I'm pretty sure progman.exe resided under system32... So the question becomes: why didn't the Win95 team put explorer.exe in the system32 directory?

 

[firewall]

Standardized locations for easier application development or for providing support? Or perhaps it's the matter of accessability of the folders?

 

[Brentx]

Good question. Like BikeDude said above, %systemroot%\system 32 is for 32 apps, %systemroot%\system is for 16 bit apps. And I know on XP x64 %systemroot%\sysWOW64 is for 64 bit apps and Windows on Windows itself, now I wonder why they even put stuff in the %systemroot% directory. And if Windows XP x64 doesn't have 16bit support like MS says it doesn't, why do they still have the %systemroot%\system directory? Maybe someone can find a KB article on this from Microsoft. Though this goes into the internals of how Windows works, so who knows if anyone knows

EDIT: I just looked in my system directory on WinXP x64, and there are no files in it. So that answers my question there

 

[spyordie007]

Both locations are in the default path so developers dont have to know the location of the executables (if they want to run notepad they only need launch notepad.exe without needing to know the location of the executable.

I think it's a valid question, since it's markedly different than the unix standards. *nix has it's system files all over the place (/usr/bin /usr/lib /etc /dev ...) and leaves the user with a smaller, defined space to keep their files, while windows basically gives the whole space to the user with the exception of c:\windows or c:\winnt. I've always actually thought that the windows way was more comfortable, but it doesn't lend itself to restricted access users and multiuser systems as well as *nix.

Actually there are plenty of OS components in other locations (Recycler, System Volume Information, WUTemp, etc.).

Generally speaking the best "userspace" for storing files should be within the user's profile (think /home); in fact in many deployments it's the only location users can store files. Creating additional folders on the root of your "C" drive to store files is just plain sloppy.

Why DO we store gas in the gas tank?

Because if we used it for storing anything else we wouldnt call it the "gas tank" now would we

 

[bsobel]

Originally posted by: spyordie007
Both locations are in the default path so developers dont have to know the location of the executables (if they want to run notepad they only need launch notepad.exe without needing to know the location of the executable.

Paths are a security risk. A developer should have the full path to all binaries loaded... (my 2 cents)

 

[kamper]

Originally posted by: spyordie007

I think it's a valid question, since it's markedly different than the unix standards. *nix has it's system files all over the place (/usr/bin /usr/lib /etc /dev ...) and leaves the user with a smaller, defined space to keep their files, while windows basically gives the whole space to the user with the exception of c:\windows or c:\winnt. I've always actually thought that the windows way was more comfortable, but it doesn't lend itself to restricted access users and multiuser systems as well as *nix.

Actually there are plenty of OS components in other locations (Recycler, System Volume Information, WUTemp, etc.).

Actually, the correct response to my post would have been to point out that the original question went completely over my head, and that what I said was quite off topic Anyway, you're correct, of course.

 

[bersl2]

Originally posted by: bsobel

Originally posted by: spyordie007
Both locations are in the default path so developers dont have to know the location of the executables (if they want to run notepad they only need launch notepad.exe without needing to know the location of the executable.

Paths are a security risk. A developer should have the full path to all binaries loaded... (my 2 cents)

You know, people like flexibility in their systems.

If you are smart with handling paths, they need not be that much of a security risk.

 

[bsobel]

You know, people like flexibility in their systems.
If you are smart with handling paths, they need not be that much of a security risk.

I'm afraid that is a over simplificiation. There are numerous attacks that involve dropping a binary earlier in the search order than the expected one. If users want to use the path for convenience, fine, but running code which is loading additional binaries should know exactly where those binaries are not let the system guess and find one with the same name 'somewhere'.