I have 2010 to Seattle all installed side by side. They work fine. I have always installed them in order, by the way - not sure if that makes a difference or not.
Since it's bragging time: I have all Delphi versions from 6 to 10 installed on Windows 8.1. I upgraded to Windows 10 for about a week. All versions continued to work fine. Note that I didn't install to "program files" though. After a week I got tired of bloody Windows 10 and restored a backup. I have no idea whether installing would work on Windows 10. There seem to be some issues with installers.
Yes. In one VM I have Delphi 6 up to Delphi 10 Seattle installed. ALL versions, except Delphi 8 and 2005... let me see: 6, 7, 2006, 2007, 2009, 2010, XE, XE2, XE3, XE4, XE5, XE6, XE7, XE8 and 10 Seattle. 15 beautiful Delphi versions living side by side in harmony! And they ALL work! Eat this Microsoft! :-)
Alexandre Machado Same here. Delphi 6 to Seattle and Finalbuilder side by side in a VM. Works great, just the installer needs and leaves dozens of GB of unnecessary temp files on the hard drive (probably needed for uninstall which really shows the demand for a new/better installer).
There should be no problem. But the recommendation to install in sequence still holds. There are a few shared files installed in system folders, and having the latest version is better (think of midas.dll, for example).
Marco Cantù Having the latest version is better? Hardly. No use whatsoever if you want to test. How then can you test what happens when running with the old version? This is DLL hell. How can we still be subjected to it?
It's 2015. I cannot believe that Embarcadero are still putting files in to the system directories. That was wrong 20 years ago, and it's wrong now.
Does Emabarcadero have any intention of changing this behaviour and following the platform guidelines?
FWIW, I don't really buy the in order advice. I install in arbitrary order without problems. But then again, I don't rely on files installed into the system folder because that's plain wrong.
The most important thing is to remove all traces of Delphi from the PATH environment variable. That way you can isolate each version more easily.
Not my area, but "following the platform guidelines"... which for a file that is needed by multiple applications means? Does Microsoft do things differently with the Visual C++ runtime library? We install very little in system folders, AFAICT.
+Marco The MSVC runtime is a system component now, so the rules are different. Considering your midas.dll example, its name is not versioned. So the only sane way to deploy it is alongside the executable. Otherwise you are trapped in DLL hell.
It's true that you don't put much in the system directories. No .bpl files IIRC. But really, nothing should go there. I see no reason for Emba to lead developers into placing files in the system folders.
Further, your installer really should stop screwing with the PATH.
David Heffernan, Marco Cantù The system path is a big problem - path size is limited. With 2010-XE7 installed, it was fine, and then I installed Visual Studio and the path ended up corrupted. I now have a series of symlinks with much shorter names ("c:\PFES" to "c:\Program Files\Embarcadero\Studio" for example.) Much better would be for the installer to not use the path, or set up symlinks - anything. QP here: https://quality.embarcadero.com/browse/RSP-10321
Piotr Antoniak, I should have remembered that and put it in my comment. Watch out for the path length.
David Heffernan Isn't it used for finding the BPLs, for programs that dynamically link? If so, they would need to be placed in a system folder instead of a Program Files folder.
+David M They should never go in system folders. The best place for them is the same directory as executable. If you pollute the system path then you can't easily isolate command line tools like dcc32. Path is never advised for DLL resolution as per MS docs. It's too flaky. System path is machine wide. Very few programs should modify it.
David Heffernan I agree in the same folder as the EXE is best - but when you're developing any number of programs, copying the required BPLs into the build output folder would result in a bast number of duplicates. I can see why they are kept in a single location. How would you suggest handling that, if not either in the path or in a system folder (ie, one already in the path?)
+David M Under the IDE, the IDE could arrange that the new process is able to find the packages. Or the IDE could place the packages in the exe directory. It knows which ones you linked to. Would need some IDE tooling.
It seems that the tail is wagging the dog. Runtime packages are surely a minority usage. Why should it get to dictate to the mainstream? Runtime packages are not even very useful. Mostly they just complicate your life.
/sub
ReplyDelete/sub
ReplyDeleteI have Seattle , xe7 and xe in same win7 .. I suppose win10 isnt different
ReplyDeleteI have 2010 to Seattle all installed side by side. They work fine. I have always installed them in order, by the way - not sure if that makes a difference or not.
ReplyDeleteSince it's bragging time: I have all Delphi versions from 6 to 10 installed on Windows 8.1. I upgraded to Windows 10 for about a week. All versions continued to work fine. Note that I didn't install to "program files" though. After a week I got tired of bloody Windows 10 and restored a backup.
ReplyDeleteI have no idea whether installing would work on Windows 10. There seem to be some issues with installers.
Thomas Mueller I have installed Delphi XE on Windows 10 without any problem.
ReplyDeleteYes. In one VM I have Delphi 6 up to Delphi 10 Seattle installed. ALL versions, except Delphi 8 and 2005... let me see: 6, 7, 2006, 2007, 2009, 2010, XE, XE2, XE3, XE4, XE5, XE6, XE7, XE8 and 10 Seattle. 15 beautiful Delphi versions living side by side in harmony! And they ALL work! Eat this Microsoft! :-)
ReplyDeleteAlexandre Machado
ReplyDeleteSame here. Delphi 6 to Seattle and Finalbuilder side by side in a VM. Works great, just the installer needs and leaves dozens of GB of unnecessary temp files on the hard drive (probably needed for uninstall which really shows the demand for a new/better installer).
There should be no problem. But the recommendation to install in sequence still holds. There are a few shared files installed in system folders, and having the latest version is better (think of midas.dll, for example).
ReplyDeleteOne Delphi version, one vm. No troubles.
ReplyDeleteMarco Cantù Having the latest version is better? Hardly. No use whatsoever if you want to test. How then can you test what happens when running with the old version? This is DLL hell. How can we still be subjected to it?
ReplyDeleteIt's 2015. I cannot believe that Embarcadero are still putting files in to the system directories. That was wrong 20 years ago, and it's wrong now.
Does Emabarcadero have any intention of changing this behaviour and following the platform guidelines?
FWIW, I don't really buy the in order advice. I install in arbitrary order without problems. But then again, I don't rely on files installed into the system folder because that's plain wrong.
ReplyDeleteThe most important thing is to remove all traces of Delphi from the PATH environment variable. That way you can isolate each version more easily.
Not my area, but "following the platform guidelines"... which for a file that is needed by multiple applications means? Does Microsoft do things differently with the Visual C++ runtime library? We install very little in system folders, AFAICT.
ReplyDelete+Marco The MSVC runtime is a system component now, so the rules are different. Considering your midas.dll example, its name is not versioned. So the only sane way to deploy it is alongside the executable. Otherwise you are trapped in DLL hell.
ReplyDeleteIt's true that you don't put much in the system directories. No .bpl files IIRC. But really, nothing should go there. I see no reason for Emba to lead developers into placing files in the system folders.
Further, your installer really should stop screwing with the PATH.
David Heffernan, Marco Cantù The system path is a big problem - path size is limited. With 2010-XE7 installed, it was fine, and then I installed Visual Studio and the path ended up corrupted. I now have a series of symlinks with much shorter names ("c:\PFES" to "c:\Program Files\Embarcadero\Studio" for example.) Much better would be for the installer to not use the path, or set up symlinks - anything. QP here: https://quality.embarcadero.com/browse/RSP-10321
ReplyDeletePiotr Antoniak, I should have remembered that and put it in my comment. Watch out for the path length.
David Millington You don't need anything in the path related to Delphi. No need for any symlinks. Just remove all entries relating to Delphi.
ReplyDeleteDavid Heffernan Isn't it used for finding the BPLs, for programs that dynamically link? If so, they would need to be placed in a system folder instead of a Program Files folder.
ReplyDelete+David M They should never go in system folders. The best place for them is the same directory as executable. If you pollute the system path then you can't easily isolate command line tools like dcc32. Path is never advised for DLL resolution as per MS docs. It's too flaky. System path is machine wide. Very few programs should modify it.
ReplyDeleteDavid Heffernan I agree in the same folder as the EXE is best - but when you're developing any number of programs, copying the required BPLs into the build output folder would result in a bast number of duplicates. I can see why they are kept in a single location. How would you suggest handling that, if not either in the path or in a system folder (ie, one already in the path?)
ReplyDelete+David M Under the IDE, the IDE could arrange that the new process is able to find the packages. Or the IDE could place the packages in the exe directory. It knows which ones you linked to. Would need some IDE tooling.
ReplyDeleteIt seems that the tail is wagging the dog. Runtime packages are surely a minority usage. Why should it get to dictate to the mainstream? Runtime packages are not even very useful. Mostly they just complicate your life.