install two igor versions (igor 6 and igor 7) on a computer (window system)

Yes you can install two versions of Igor Pro on a computer.

What is the compile error on IP8? The required code fixes are usually pretty straight forward.

Oh, good! If I have pxt files with igor 6 and igor 8, respectively, each version is identified ideally? I will retry installing with two versions first.

Note that on Windows, the last version of Igor that you installed will be used by the OS to open Igor files (eg. experiment and procedure files) when you double click on them. But you can always start the version of Igor you want to use and then open the file from within Igor or drag the file onto Igor to use a specific version.

Also, if you need to activate any XOPs or need any procedure files to be opened when Igor starts, you'll need to set up those things for each version of Igor you install.

Bump!

I want to run IP8 or IP9 as needed for different use cases. I am on macOS. I want to keep my Igor Procedures and User Procedures folders common to both versions. I thought that I could simply make symlinks or aliases to the Igor Procedures and User Procedures folders from Documents/WaveMetrics/Igor Pro 8 User Files folder and put them in the corresponding .../Igor Pro 9 User Files folder. This approach does not however resolve itself properly with #include pragmas.

What is the recommended approach on macOS and Windows when a user wants to run IP8 or IP9 while keeping common Igor and User Procedure folders? 

What is your problem, how does it manifest?

I have both IP8 and IP9 on macOS and I have links to my SVN folders with the code itself. All works transparently with #include. I am confused what the issue would be here. It works for Igor Procedures, User Procedures, and XOPs as well. 

I used this on Windows when I used them as main system and it worked as well, but that is years (and IP versions) ago.  

I have both IP8 and IP9 installed on Windows 10. My experience is consistent with the comments of aclight. I also would like to see responses to jjweimer's query.

First, my apologies that I bumped an old thread. I should have started my own.

Here is my setup. The highlighted is a symlink. IP8 does not recognize the files in it. I've tried also with an alias rather than a symlink. I've looked in my System Preferences to see whether I should set something in Security & Privacy (e.g. disk or folder access).

I would suggest that you keep a regular folder "Igor Procedures" for both installations. Put the alias to your other Igor Procedures inside the regular folder. Or perhaps make a third folder somewhere else (in Documents or something) and put an alias to it in both Igor Procedures folders.

When Igor starts up, it looks for the standard folders; I don't know if it follows links at that time. I would have to look at our source, and that's not an area I'm super familiar with.

OK. Thanks. For those who need to know, this folder organization works. The aliases to the IP8 folders are inside their respective main folders for IP9.

If you are using the project updater for installing and updating IgorExchange user projects, the setup that you describe will have some implications. I haven't tested such a setup, so take this with a pinch of salt, but here is how I think it will work:

The two Igor versions can share the same updater.ipf procedure file, just like any other procedure.

Each Igor version will have independent configurable options, because each Igor version has its own preferences storage area. This will be true for any package that saves preferences using the SavePackagePreferences method. It should not cause a problem.

Updater saves an install log and a cache file in a subfolder of local user procedures, so these will also be unique to the Igor version you are using, even though the ipf file is shared between Igor versions.

If you install a package that contains a procedure file, the installer forces you to choose an install path within the Igor Pro User Files folder of the version you are using. I'm pretty sure that shortcuts/aliases are not resolved when the path is checked. This means that packages should be installed using the version that hosts the procedure files.

Depending on the options you have selected, version checking may follow folder aliases. So an update could be discovered and installed using either version. That should work, but...

The install log may get out of sync if updates are installed on the 'other' system. If this happens, right-click the version number in the user interface and select the option to sync the install log with the version number in the installed file.

So, as far as I can see, it should all work.

Tony -- Thanks for the details. I might be able to test this over the coming holidays and report back.