31

Program Files is typically C:\Program Files; however it is not always; famously on German installs it was C:\Programme, the installation drive was not guaranteed to be C, and other things would make hardcoding "Program Files" fraught with peril.

The modern suggestion is SHGetFolderPath which didn't exist on Windows 95. A little spelunking revealed SHGetSpecialFolderLocation but that doesn't actually work.

 SHGetSpecialFolderLocation(NULL, CSIDL_PROGRAM_FILES, &pidprogramfiles))

Yields an error. A trace bit of documentation left around on MSDN says CSIDL_PROGRAM_FILES started existing with Version 5 (Windows 2000). So how the hey were installers supposed to find it?

I can make this work by reading HKLM Software\Microsoft\Windows\CurrentVersion ProgramFilesDir ; however this reading the registry for this stuff is something Raymond Chen has been rather famously yelling about.

Leo B.
  • 19,082
  • 5
  • 49
  • 141
Joshua
  • 1,829
  • 14
  • 22
  • Not an answer, but from memory, if you used an installer such as InstallShield, then there was some installer syntax for all of the usual installation target directories. That might just be passing the buck: how does InstallShield know? My experience was mostly NT, but I think the installler mechanisms were similar. – dave Mar 16 '22 at 02:27
  • 3
    There's always %ProgramFiles% (etc) in modern Windows; I forget when that might have shown up. – dave Mar 16 '22 at 02:35
  • 2
    @another-dave: Not Windows 95 (it had to keep its environment small because DOS is still active). %ProgramFiles% is from the NT branch. – Joshua Mar 16 '22 at 02:56
  • Also not an answer, but installing Internet Explorer 5 on Windows 95 should update the shell DLLs to version 5 (with support for CSIDL_PROGRAM_FILES). – Stephen Kitt Mar 16 '22 at 06:22
  • 4
    "Raymond Chen has been famously yelling about" - What he says, is "you should use SHGetFolderPath()". But when that isn't reliably present (because no one bothered to install IE5.0), it's pretty hard to follow that advice.... – tofro Mar 16 '22 at 10:54
  • Note that MSDN (sorry, Microsoft Documentation) does not keep track of when a function actually first appeared, but what the minimum supported version of Windows is when the documentation page was last updated. That said, you're right, further testing shows CSIDL_PROGRAM_FILES isn't there on a base VC++6 install. – Dranon Mar 17 '22 at 03:27
  • @StephenKitt: I think this DLL update started Internet Explorer 4, which had Windows Desktop Update as an optional component when installing on Windows 95. – Jonathan Mar 17 '22 at 10:36

3 Answers3

36

According to Microsoft KB Q178625, for Windows 95

developers should refer to the system registry to identify the location of the Program Files directory.

It goes on to suggest that

However, to ensure that your application can run on any platform, it can check the registry value for the location of a directory. This approach eliminates the need to hard code the directory path. Refer to the value for the ProgramFilesDir key at [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion] to find the localized name of the Program Files directory.

Mark Williams
  • 4,062
  • 1
  • 23
  • 50
35

Some (quite a lot) simply didn't. A clear indication of this: Typical fresh Spanish or German installations started with a "C:\Programme" or "C:\Archivos de Programmas" folder, and after installing some programs, ended up having a "C:\Program Files" folder as well (i.e. the installation path was hard-coded into the installer of some programs.)

For early Windows 95 installations, I believe there is no simple way other than reading the

  $HKLM Software\Microsoft\Windows\CurrentVersion ProgramFilesDir

registry key.

tofro
  • 34,832
  • 4
  • 89
  • 170
  • 5
    ...and I can confirm that said registry key is visible in a screenshot on page 1029 of the Windows 95 Resource Kit... so it should be there from the earliest releases. – ssokolow Mar 16 '22 at 10:28
  • 3
    I've also seen German software install into C:\Programme on English Windows (repeatedly, and as late as XP), and even something with a typo hardcoded - C:\Programm Files I think. The latter was something minor but the former was commercial – Chris H Mar 16 '22 at 11:43
  • 7
    There was no simple way except for this very simple way.....love it. – Dean MacGregor Mar 16 '22 at 12:37
  • 10
    Even in the days of Windows XP, when I accidentally ended up installing the entire OS in D:\ (yes, D:\Windows, D:\Program Files, the whole thing), there would still be programs which kept creating the directory in C:...' – grawity Mar 16 '22 at 17:21
  • If I recall correctly, this is related to a fairly well known issue on Swedish Windows 9x systems. In Swedish, the correct path is C:\Program. But some applications still installed in C:\Program Files. When these tried to start automatically on logon, they tried to invoke C:\Program Files\Contoso\superapp.exe without quotation marks. On an English system this worked, since C:\Program was not a valid entry in the file system so Windows understood the intention. However, on a Swedish system, C:\Program was a folder, so these users always had this folder shown when they logged in. – Andreas Rejbrand Mar 16 '22 at 20:28
  • @user1686 - Windows NT has always been divorced from the idea that the OS is installed on C. As you note, that's not saying the same thing about applications, which are often written by 16-bit programmers who rely on coincidence. – dave Mar 16 '22 at 21:59
  • 1
    @DeanMacGregor That's not very simple in 1995... No StackOverflow, not even Google. – user3067860 Mar 16 '22 at 22:02
  • 1
    IIRC, some programs didn't even bother with the concept and just created a root-level folder like C:\program_name or C:\publisher_name\program_name. DOS had a path length limit of something like 80 characters, so the trend at the time was to keep the directory tree as flat as possible. – bta Mar 16 '22 at 23:53
  • 9
    Yes it was pretty common for programs to ignore the convention and not install in \Program Files for quite some time after Win 95 was released. In fact even around 2007 I still remember many of the "enterprise" applications we used installed off the root by default - often it seemed because they didn't properly handle long file/folder names and/or folders with spaces in them properly). – David Waterworth Mar 17 '22 at 01:09
  • 1
    @DavidWaterworth some still do (or at least did on Win7 - I don;t use windows much any more) – Chris H Mar 17 '22 at 10:28
  • 1
    @ChrisH e.g. Oracle SQL Developer... – user11153 Mar 17 '22 at 12:12
  • 1
    @user11153 I'm thinking of C:\Autodesk – Chris H Mar 17 '22 at 12:13
  • @ChrisH @bta as well as Autodesk, I've also observed Nvidia and AMD to decompress/install graphics drivers in their own folder structure on the root C: drive. – Joshua Voskamp Mar 17 '22 at 15:44
  • Fortunately, that seems to be just the unpacked installer, not the actual driver. – grawity Mar 17 '22 at 18:08
  • @user1686 I had a lot of small problems with the lack of drive C as well recently (win 8+). All software has worked and installed fine, but many still tried to access drive C for some reason (which either didn't exist or some removable drive was assigned this letter) which pestered me with annoying errors like "please insert drive C" which I had to click through for sw to work. I ended up assigning some spare SSD I had a letter C to solve this issue ;P I guess lots of SW still has "try drive C, and if it doesn't work, do the right thing" type of code. – Dan M. Mar 18 '22 at 12:20
  • @bta I think Oracle still does this. At least with express edition. I haven't installed the full on Enterprise version of it, but it's a bit funny when you see it and remember the days playing at a DOS machine... – Haakon Løtveit Mar 18 '22 at 12:22
5

At this time, it was common to be forced to implement a cascade of tests to check some system elements, from the "best one" to the "worst one", and we were often forced to even add a "random guess shot" when everything failed! Obviously, the first answer causes a flow break and you'll return the best possible reply each time.

For history purpose, check how you determine which kind of executable a .EXE is (DOS, DOS/Extended, Win16, Win32, ...), and you'll see exactly which kind of tricky analysis is required for these old system "functionalities".

For your particular need, you'll need to check, in this order:

  1. ShellAPI: reliable when present, but it was dependent on IE to be there.
  2. Registry: Near reliable, at least on Win95.
  3. Hard drive scan: you'll search things known as installed to see where they are (for example, CommonFiles stuff...).
  4. Known file names: get the operating system language, use a LUT/map to get the associated name of Program Files.
  5. Ask the user OR use a hardcoded value (get system drive, append \Program Files and hope that it will suits).
Wisblade
  • 185
  • 8