Windows Vista ProgramFiles

[Guest]

Hello IT-Fans,

I have installed Windows Vista on my Testpc. I installed Language Packs too.

For what is the ProgramData Folder standing for? (only viewable if you
activate "Show all Files and Folders")

bye david

 

[Andrew McLaren]

I have installed Windows Vista on my Testpc. I installed Language Packs
too.

For what is the ProgramData Folder standing for? (only viewable if you
activate "Show all Files and Folders")

ProgramData is similar to the old C:\Documents and Settings\All
Users\Application Data" directory on XP. It's the place where applications
can install data which is shared by all users. Don't delete or mess with
this directory! It is essential for the correct functioning of Vista.

Why, you might ask, can't apps just write their data to somewhere under
C:\Program Files"? Well, the Program Files directory tree has a special,
restricted set of permissions, suitable to protect executable files, and
prevent them from being over-written by a virus, etc. This means that apps
cannot conveniently write volatile data to this part of the tree.
ProgramData has a different set of default permissions, more suitable for
variable data.

Hope this explains it. There are some docs somewhere in MSDN which describe
the new file layout in detail, I just can't find the link right now (sorry).

 

[Guest]

Thank you very much,

If you find the links - please post it.

bye david

 

[Andrew McLaren]

If you find the links - please post it.

Right. The Chicago-style Windows shells (Windows 95, Windows 2000, Windows
XP) have the concept of "Known Folders" - files aren't just scattered around
the place; some folders are specially known to the Operating System. They
can be located by a call to SHGetFolderPath(), and are identified by a
CSIDL. So for example, there was CSIDL_COMMON_APPDATA, typically
"C:\Documents and Settings\All Users\Application Data". An appplication
could determine the actual pathname of the APPDATA on any machine at
runtime, by calling SHGetFolderPath, in case the actual path was different
due to language localisation, or different installation habits etc.

These folders are described here:
http://msdn2.microsoft.com/en-us/library/ms649274.aspx

The shell in Vista has a very similar concept, however it has been expanded
somewhat. The CSIDL has been replace with a more flexible GUID identifier,
the "Folder ID". And there is a new API, SHGetKnownFolderPath. An
application can locate a known folder on any system, by calling this API.
That way, application programmers don't have to hard-code human strings into
their apps, such as "C:\Program Files". On a German vesion of Windows, this
path is actually "C:\Programme" - but a call to SHGetKnownFolderPath() will
return teh right path, no matter what language the OS.

The list of known foldes in Vista is here:
http://msdn2.microsoft.com/en-us/library/bb407328.aspx

Besides being "known", several of these folders have special sets of
permissions, tailored to the folders' intended purpose. So for example,
users cannot write to folders under the "Program Files" directory, to
prevent viruses hijacking legitimate EXE files.

Hope it helps,
Andrew

 

[Christopher R. Lee]

Right. The Chicago-style Windows shells (Windows 95, Windows 2000, Windows
XP) have the concept of "Known Folders" - files aren't just scattered
around the place; some folders are specially known to the Operating
System. They can be located by a call to SHGetFolderPath(), and are
identified by a CSIDL. So for example, there was CSIDL_COMMON_APPDATA,
typically "C:\Documents and Settings\All Users\Application Data". An
appplication could determine the actual pathname of the APPDATA on any
machine at runtime, by calling SHGetFolderPath, in case the actual path
was different due to language localisation, or different installation
habits etc.

These folders are described here:
http://msdn2.microsoft.com/en-us/library/ms649274.aspx

The shell in Vista has a very similar concept, however it has been
expanded somewhat. The CSIDL has been replace with a more flexible GUID
identifier, the "Folder ID". And there is a new API, SHGetKnownFolderPath.
An application can locate a known folder on any system, by calling this
API. That way, application programmers don't have to hard-code human
strings into their apps, such as "C:\Program Files". On a German vesion of
Windows, this path is actually "C:\Programme"

Why the hell did they do that? It just adds more confusion to a confused and
confusing OS.

When you install a program, it proposes "C:\Program Files", whatever your
language. When you want to know what the installer has done, you have to
know to look in "C:\Programmes" (in French). I thought aliases were for
Unix geeks.

Regards

- but a call to SHGetKnownFolderPath() will

 

[Andrew McLaren]

Why the hell did they do that? It just adds more confusion to a confused
and confusing OS.
When you install a program, it proposes "C:\Program Files", whatever your
language. When you want to know what the installer has done, you have to
know to look in "C:\Programmes" (in French). I thought aliases were for
Unix geeks.

If the program installer is written correctly, it will query for
CSIDL_PROGRAM_FILES and display "C:\Programmes" on a French Windows, instead
of "C:\Program Files". If an Installer displayed "C:\Program Files" as the
default installation path on French Windows, then it is a bug in the
Installer.

But, I take your point about path names and aliases. I kind of agree.

Ideally, the literal file system name of the directory would fairly
arbitrary, not necessarily meaningful to humans (eg, "C:\bin"). Let the
Shell (Explorer) take care of translating literal directory names into
human-readable strings ("Programmes" or "Program Files")

CMD is tied to legacy path names; but Powershell can navigate multiple
hierarches (flesystem , registry etc). So Powershell could be tweaked to
navigate a User-oriented namespace ("cd Program Files" would change
directory to c:\bin); and leave the filesystem behind.

I think Microsoft was stuck between the two extremities ... for a long time,
they've *tried* to replace literal directories with logical place names,
such as CSIDLs. That is a good thing. But they couldn't let go of filesystem
directory names as some kind of meaningful string, in their own right.
Partly for backwards-compatibility reasons. It also seems the marketing guys
at Microsoft have even colonised the filesystem - Microsoft products always
want to install into directories caled "C:\Program Files\Microsoft Great Big
Product 2007 Enterprise Edition v1.1". If Microsoft followed their own
Windows developer guidelines, they'd have ONE directory off
CSIDL_PROGRAM_FILES called "Microsoft" and then all their products would
install under there (eg C:\Program Files\Microsoft\SQL Server" instead of
C:\Program Files\Microsoft SQL Server"). This would result in a shorter,
tidier tree. But it seems the marketing guys just can't resist trying to get
the string "Microsoft" into our faces an extra twenty times. I hate it. We
should say to the marketing guys "No, no, no - this is a file system path;
it is an operating system internal data structure, not free advertising
space. Go pollute the Shell, instead". After all, we say "dwProcessID" not
"Microsoft_dwProcessID" ... and so on.

Oh well. All widely-used operating systems have a tonne of compromises. If
Synchronicity takes over from Windows, maybe they'll get it more right, this
time round