Detecting Windows 7

[esposito]

Does Win7 contain the C:\Users\Public folder as Vista does?

[si_the_geek]

As will all versions of Windows for the last 10+ years, it will have a folder for that - just detect the location/name in the normal manner (such as KnownFolderID's or CSIDL's, or the method shown in the FAQ article Where should I store the files that my program uses/creates?).

[esposito]

As will all versions of Windows for the last 10+ years, it will have a folder for that - just detect the location/name in the normal manner (such as KnownFolderID's or CSIDL's, or the method shown in the FAQ article Where should I store the files that my program uses/creates?).

I use Inno to create a setup procedure for my applications. Right now I use a function to detect if the final user has Vista and, if he does, I install my app in C:\Users\Public.

Do you know how I should modify the Inno code below to detect Windows 7 as well?

var s: Integer;

function GetAppFolder(Param: String): String;
begin
  s := InstallOnThisVersion('0,6', '0,0');
  if s =  0 then
    Result := 'C:\Users\Public'
  else
    Result := ExpandConstant('{pf}');
end;

[si_the_geek]

That is the wrong place to install your program - because that folder is for data.

You should install your program within %ProgramFiles%, and your data in %CommonAppData% (for all users) or %AppData% (for just the current user).


In addition to that, the name (and location) of the folder is also not decided by just by the version of Windows, it also depends on the language, and what modifications the user has made (you can easily move and/or rename the special folders).

Rather than hard-coding paths, you should ask Windows where they are, using the API's etc provided. Most installers are already designed to do that, you just need to tell the installer.

I don't know what options Inno provides, but it seems that you could do it all with ExpandConstant as you did in that snippet.

[RhinoBull]

@esposito:

sorry but you are dragging this thread away from its original question.

[esposito]

...the name (and location) of the folder is also not decided by just by the version of Windows, it also depends on the language, and what modifications the user has made (you can easily move and/or rename the special folders).

To RhinoBull: I know I am going off topic. I should have started a new thread but, at this point, only a moderator could split my posts from the others.

To si_the_geek: No, the path C:\Users\Public is used on all versions of Windows Vista, independently of the language.

The translation into a language other than English shown in the Windows Explorer is only a virtual path that points at C:\Users\Public.

I have the Italian version of Vista installed on one of my PCs and it works that way. The code snippet I posted works perfectly when you install my applications on Italian machines.

I am obliged to install all of my application (executable + data) in the Public folder simply because my software must work on pendrives as well. Although it may not look professional, the only way I can do it is by putting the database files in the application folder.

Now, I need to know whether my snippet needs modifications in order to detect Windows 7 or the code used to detect Vista is also valid for Windows 7. Unfortunately, as I still don't have Windows 7, I can't test it myself.

I know I may be asking too much, but I would really appreciate it if someone using Windows 7 could try to install one of my apps and see if the installation folder proposed by the setup procedure is C:\Users\Public. If you want to help me, you could download a small app of mine from this page:

http://www.espositosoftware.it/videodb.htm

Thanks in advance.

[si_the_geek]

Off-topic posts moved from this thread.


Even if you hadn't ignored important facts (the user can easily move and/or rename the special folders), there is no valid reason for you to ever hard-code a path to a special folder (in full or part); the issue at hand (automatically accounting for different versions of Windows) is just one of the reasons. In terms of your installation, you can almost certainly get Inno to detect it for you, and it should take you less than 5 minutes to change that.

The rest of the information you need is back in post #2 of the original thread.


I must say that you have again surprised me by pretending that you are somehow 'obliged' to do something that is completely unprofessional, when the real issue is that you simply can't be bothered to do things properly (there are much more sensible ways to deal with pendrives etc - I'm sure a search would find suitable scripts for Inno).

[esposito]

Off-topic posts moved from this thread.
I must say that you have again surprised me by pretending that you are somehow 'obliged' to do something that is completely unprofessional, when the real issue is that you simply can't be bothered to do things properly (there are much more sensible ways to deal with pendrives etc - I'm sure a search would find suitable scripts for Inno).

Let me sum up what my problem is. My application must run on a pendrive, so I need to place the data in the same folder as the exe. As my application must be "transportable", the only solution I can see is placing the database files in the same folder where the executable is located.

Vista makes a mess when you try to save the data in the Programs folder. That's why I feel "obliged" to target the Public folder for my installation.

If I save the data in the default data folder used by Windows, how could I remove the pendrive from one computer, plug it into another PC and find the data? If I am missing something, please tell me. What are the "much more sensible ways to deal with pendrives" that you talk about?

[si_the_geek]

If the application is designed to run on a pendrive, why is everything on the hard drive? Surely at a minimum, the data should be on the pendrive?

If the application is installed on multiple computers that the pendrive could be moved to, simply store the path to the pendrive in the HKCU section of the Registry (or a file in a data folder). To get the initial value, you can either get the user to specify the location, or auto-detect the drive types and search them, or maybe even get the installer to store it for you.

If you want to store template files etc, you can put them (but not the application) in a data directory.

Vista makes a mess when you try to save the data in the Programs folder.

Yes.. and so do Windows 2000 and XP (in a bigger way than Vista does) for users with lesser rights.

If in doubt, check the Windows 2000 developer guidelines (via the FAQ link above), which I'm sure I have pointed you to before - and you should always follow.

That's why I feel "obliged" to target the Public folder for my installation.

No matter how you justify it to yourself, that is just an excuse for being lazy and unprofessional about the issue.

[esposito]

If the application is designed to run on a pendrive, why is everything on the hard drive? Surely at a minimum, the data should be on the pendrive?

The answer to your remark is contained in a paragraph that I include in the help file of all of my applications:

Questo programma funziona anche su chiavetta USB. Il software dispone di una funzione di installazione guidata affinché l'utente possa creare automaticamente le icone per l'avvio del programma e per la sua disinstallazione. Una volta installato il software, è comunque possibile copiare su pen-drive la cartella del programma presente sul disco fisso e ciò consentirà di utilizzare il software senza installazione, semplicemente lanciando l'eseguibile (file XYZ.exe).

Translation into English:

This program can also work on a pendrive. The software is provided with a guided installation procedure to allow the user to automatically create the icons to launch the program or uninstall it. Nevertheless, once the software has been installed, the user can just copy the program folder from the hard disk to a pendrive and this will allow him or her to use the software without installation, by simply launching the executable (file XYZ.exe).

Now, the user should be able to use the software on any computer and for this reason I can't "store the path to the pendrive in the HKCU section of the Registry (or a file in a data folder)".

Targeting the Public folder has been the best solution to the problem so far, no matter how unprofessional it may be. Since Vista was released, I have sold hundreds of licenses and nobody has ever complained about failures in saving or retrieving data. (By the way, the executables I produce with Delphi are standalone, and so are my SQLite databases).

As I am afraid that Windows 7 makes use of virtualization as Vista does, all I need to know is how to detect Windows 7 in order to target the Public folder. That's why I asked my original question.

[esposito]

No matter how you justify it to yourself, that is just an excuse for being lazy and unprofessional about the issue.

If it looks unprofessional but works... it isn't unprofessional!

(Murphy's Law)

[si_the_geek]

The further information you provided changes things slightly, but it is still easily solved without resorting to bad methods.

Rather than making the user copy the program/data to the pen drive themselves, add a feature to the program to do it - then it doesn't matter what the source folders are (as long as your program knows, which it clearly will), and is easier for the user too.

Even if you don't do that, it isn't exactly hard to tell the user to copy 2 folders.

Targeting the Public folder has been the best solution to the problem so far,

It may be the best that you have managed to think of, but it certainly isn't the best.

and nobody has ever complained about failures in saving or retrieving data.

Ah yes, that means everything about the process is perfectly acceptable then.

As I am afraid that Windows 7 makes use of virtualization as Vista does, all I need to know is how to detect Windows 7 in order to target the Public folder. That's why I asked my original question.

Erm... that has been answered (the version table in the old thread, and ExpandConstant in this one).

If it looks unprofessional but works... it isn't unprofessional!

(Murphy's Law)

It never ceases to amaze me how deluded you are.

Your method doesn't just look unprofessional, it violates the rules for programs on Windows.

It isn't hard to do things properly, but you have decided not to bother, and be a bad programmer instead.

I've had enough of your foolishness, I'm out of here.

[esposito]

It never ceases to amaze me how deluded you are.

Your method doesn't just look unprofessional, it violates the rules for programs on Windows.

It isn't hard to do things properly, but you have decided not to bother, and be a bad programmer instead.

I've had enough of your foolishness, I'm out of here.

This language is unprofessional, which is serious if you consider that a moderator should set a good example.

[dilettante]

My "portable enabled" applications deal with this another way.

When they start one of the first actions is to set up global strings containing data paths.

The first step compares App.Path against the [CSIDL_PROGRAM_FILES] value. If they match up through the end of [CSIDL_PROGRAM_FILES] the program knows it is fully installed in per-machine mode.

If not, App.Path is matched against [CSIDL_LOCAL_APPDATA]\Programs. If they match up I know I am installed in per-user mode (according to the new conventions in Windows 7, but applicable to Vista and XP). I suspect Windows 7 will have a new CSIDL for this soon, or at least a new KNOWNFOLDERID value but for now we have to use "Programs" literally (for any language/locale).

Otherwise I am installed in "ad hoc" mode - normally not recommended but required for portable applications.


In per-computer mode I set an "internal common data path" string to a folder created under [CSIDL_COMMON_APPDATA] that my installer sets permissions on after creating it. I also set an "internal user data path" to a folder created under [CSIDL_LOCAL_APPDATA].

In per-user mode I set both data paths to the created folder under [CSIDL_LOCAL_APPDATA]. This is because a per-user install can be run without admin rights, so there is no real choice. But it follows all of the standards outlined in the pre-release Windows Installer 5.0 documentation. All executable code files and read-only data are set read only.

In ad hoc mode a single data folder is created under App.Path and made hidden as part of installation. Code and read only data files are set read only. Both data path strings are set to this folder. This is compatible with the needs of portable applications which are usually resident with their data on removable media. The program always recreates this folder if not present! Note that "ad hoc" is also the typical state during development, and the data files are thus kept within the project folder during development with no need to change anything in order to package the compiled application.


Write this "private virtualization" logic ONCE, then thoroughly debug it, and then use it blindly in future projects. It will save you lots of time.


After such a program initializes the strings based on environment detection no further conditional logic is required. To avoid inadvertant Windows filesystem virtualization the program declares itself Vista aware by having an application manifest containing a trustInfo section.

Whenever possible I use reg-free COM to avoid COM component registration. Registration can be a snakepit for ad hoc and per-user installations, because many components require both per-machine and per-user registration since Windows 2000. VB6 has a hack to get around this but it can have negative consequences: on first-run by every user it calls the self-reg entrypoint of each COM library to establish per-user registration at that time. An application properly installed per-computer using Windows Installer doesn't have this headache, because the Installer service will detect the new use and set up proper per-user registration at that point. This little glitch can cause problems in a Terminal Services scenario.

Reg-free COM is also required for per-user installation by standard users. VB6 auto-registration is always hazardous.