VSoft Technologies Blogs

rss

VSoft Technologies Blogs - posts about our products and software development.

Update : Still the same situation with XE8, Rad Studio 10 Seattle, Rad Studio 10.1 Berlin. 

The Windows Path environment variable has a limit of 1023 * 2,048 characters, a stupidly short limit in this day and age, and when this limit is exceeded the path is truncated. Why this limit still exists on windows I have no idea.. for that matter why it ever existed... anyway, we're stuck with it (along with it's best buddy, MAX_PATH). 


Each version of Delphi adds over 200 characters to your system path. Worst still, they add those 200+ characters to the front of the path, not the end. What happens, is that eventually, important entries get truncated off end of the path, and strange things happen. You will find programs will not run, the task bar displays the wrong icons for programs, even getting to the control panel can be problematic. 

If you look at the entries that XE7 added to the start of your path you will see something like this :

C:\Program Files (x86)\Embarcadero\Studio\15.0\bin;
C:\Program Files (x86)\Embarcadero\Studio\15.0\bin64;
C:\Users\Public\Documents\Embarcadero\Studio\15.0\Bpl;
C:\Users\Public\Documents\Embarcadero\Studio\15.0\Bpl\Win64;

Fortunately this can be shortened by the use of junction points. Sadly, this will polute your C: drive with new folders but it's better than the alternative.

The trick is to create links for the most common paths, so on mine I created these
For XE5 and earlier :
mklink /j RS C:\Program Files (x86)\Embarcadero\RAD Studio
mklink /j rspub C:\Users\Public\Documents\RAD Studio

XE6 and above 

mklink /j Studio C:\Program Files (x86)\Embarcadero\Studio
mklink /j spub C:\Users\Public\Documents\Embarcadero\Studio

Once you have those junction points, you can then edit your path and replace the long paths, for example (for XE7) :

C:\Program Files (x86)\Embarcadero\Studio\15.0\bin -> C:\Studio\15.0\bin
C:\Program Files (x86)\Embarcadero\Studio\15.0\bin64 -> C:\Studio\15.0\bin64
C:\Users\Public\Documents\Embarcadero\Studio\15.0\Bpl -> C:\spub\15.0\Bpl
C:\Users\Public\Documents\Embarcadero\Studio\15.0\Bpl\Win64 - > c:\spub\15.0\Bpl\Win64

So for XE7, that cuts it down from 218 to 80 characters, if like me you also have multiple versions of Rad Studio installed, this can be a big saving.

As for Rad Studio, it's extremely rude to add things to the start of the path, the truncation it causes can ruin a machine.. I wasted several hours again today after installing XE7. Embarcadero were told about this issue many times over several releases.. according to the doco, XE7 will popup a message about this.. I didn't see it so not sure when that is supposed to appear, but in any event, if your installer or progam needs to add something to the path environment variable, PLEASE ADD IT TO THE END!! and save us all a bunch of time. 

* Correction, max path length is 2048 - very difficult to find a difinitive source of this information on the microsoft site - the max size of an env variable is 2048, however I have seen the path variable truncated at 1024 many times.

Showing 15 Comments

Avatar
Vincent Parrett 5 years ago

Comments on this post have gotten way off topic. For the record, our products all install their executable files in their own install folder (apart from one com dll shared between finalbuilder and automise). Closing comments now.


Avatar
LDS 5 years ago

The solution to avoid "DLL hell" is exactly to have each application DLLs available to that application only - or use strong named ones in a "global" area - to ensure each application uses only the DLL it is designed for.
"DLL hell" was caused by sharing DLLS and having multiple copies of the same DLL available somehow for each application, and which one was actually used depending on "run time" conditions like the system path variable, and/or the order of installing applications because each installer happily overwrite others.
While MS can install its runtime in the Windows system directory - but it does use strong names too - others can't (and shouldn't) so easily. Thereby or you do install in the same application directory (or below it), or install in *your* "common" directory (under common files, for example) and set the application DLL search order to use that path as well (there's an API for that... or other methods to alter the path see my previous post)
Having executable files (and remember DLL - including BPLs - *are* executable files) in user writeable folders is huge security risk.

Once where disks and memory were small are over, and there's really little need to try to minimize the space used by application files and trying to load the same DLL in memory once - that was the reason to try to share DLLs as much as possible, leading to "DLL Hell" because there were no good rules to perfom it - not that too many developers abide to Windows programming rules and guidelines, many still use those barely valid for Windows 3.0


Avatar
Marjan 5 years ago

Ah, yes of course. Now I understand. And now I understand why it isn't a problem for me. I don't have design time components installed...

Don't do much UI programming and if I do have to change a form unit I can get away with ignoring the dfm related errors as long as I don't have to change the visual layout... :D


Avatar
Vincent Parrett 5 years ago

Marjan, the main issue is the Design time packages, which then in turn reference runtime packages. If those are not on the system path, delphi cannot load them. It's a limitation of the windows loader, not delphi. Anyway, we're straying way off topic here, the main issue is delphi messes with the path in a bad way, with bad side effects.


Avatar
Marjan 5 years ago

Strange. I got an email with your response to my comment, but I don't see it here. Anyway...

"Marjan, I do know a thing or two about working with delphi runtime & component packages.. been doing it for a long time. Of course we build third party libraries and components from source. Do you seriously (on your dev machine) have a copy of everything in the output folder of every project? Having more than one copy of rtl160.bpl etc on your machine is just asking for trouble (dll hell). "

Of course you do, that's why I was surprised...

No, I don't ... because we don't build with packages. However, if we did, yes I probably would.

I like it when I can press a single button, or run a single script and be absolutely for sure that any app I subsequently start is using _only and exactly_ what I just built and so is completely unaffected by whatever else have on my (dev) machine.

Having multiple copies of a single dll is not what is known as "dll hell".

Dll hell is when you put all dll's in a single folder (such as windows\system) and give all versions of a dll the exact same name. That way you can't have multiple applications dependent on the different versions of a dll. Upgrading one of the applications can then break another when it installs a newer version of that dll.

Since Delphi supported versioning in the name of the build target, that problem has gone and you can indeed put all packages in a single folder. But when you do, your application - and/or your dev environment - becomes dependent on the environment's path. And your application can stop working because somebody else (like Embarcadero) was less than civil when amending the path to suit their needs.

I don't much like trouble shooting these kinds of problems and while I probably wouldn't suffer them (or easily solve them) on my own development machine, I prefer to have a development environment that is as close as possible to the "real" installation at one of our customers. In fact our source control is set up to include a folder that exactly mimics our application's folder as it would be after a clean installation on a customer's machine. It helps to avoid a lot of those "it works on my machine" situations.

Also, having everything together for every version / branch on my dev machine gives me the freedom to use a single name or use versioned names for dll's or packages. And I like my freedom <g>.

Oh, and you don't have to change the system path when you install your application (as Embarcadero shouldn't do either). Just put a cmd file along side your application in your application's root folder and put all dll's in a bin sub folder. Start your app through the cmd file and set the path in there before you start your exe. That way you can always have a "clean" path regardless of what the environment's path is. Of course all your application's shortcuts should point to the cmd file instead of the exe.


Avatar
David Taylor 5 years ago

@Vincent - Glad to see the junction trick solved your path problem. Now if someone would only write a nice graphical tool to automate the process ;) That has been on my list for a long time, but I never seem to find the time.

@KM - The path length limit lives on even in the latest versions of Windows. I know because I it has been a thorn in my side for years. Interestingly, installing new software will often push Windows over it's max limit and cause the path to become effectively empty. Still in the registry, just not loaded into the environment when new processes are started. Rebooting the PC usually resolves the issue until the next install. Apparently a longer path can be loaded at boot time for some reason.


Avatar
Vincent Parrett 5 years ago

Marjan, I do know a thing or two about working with delphi runtime & component packages.. been doing it for a long time. Of course we build third party libraries and components from source. Do you seriously (on your dev machine) have a copy of everything in the output folder of every project? Having more than one copy of rtl160.bpl etc on your machine is just asking for trouble (dll hell).

KM, yes I came across that post today whilst searching.


Avatar
KM 5 years ago

Also, read http://blogs.msdn.com/b/oldnewthing/archive/2010/02/03/9957320.aspx, Raymond Chen is always useful...


Avatar
Marjan 5 years ago

"Scott, if you use runtime packages you do need those entries on the path (for third party packages)."

??? Why ???

Your application shouldn't be dependent on the environment path of the machine on which it is running.

Any run time packages and other resources (dll's, images, the whole she-bang) your application needs should be in the same folder as the application itself.

Yes, that means building everything to the same location.

Should not be a problem as you should be building your libraries (both your own and third party ones) from source anyway.

So add the packages you need to your project group, set their output location to be the same as that of your application and just build (all).


Avatar
LDS 5 years ago

There are several better ways, IMHO:
1) Remove all nasty program specific entries, and use specific .cmd files to setup the environment for specific applications. It's also very useful if you use different versions, you are sure to work in an environment setup up for a specific version and not calling something of a previous/later version, depending on what app was installed last. Delphi already offers a "RAD Studio command prompt" - that's what you should use to invoke command line tools.
2) Use the App Paths subkeys in the registry (http://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx)
3) Applications should set their pown DLL search paths if DLLs/BPLs are not in the same folder, and don't rely too much on environments paths that may be altered and make them load the wrong DLL.
4) Set needed environment variables used while working in the IDE into the IDE settings

Otherwise it all comes down to lazy and outdate programming habits...


Avatar
Marius 5 years ago

All those paths are really nonsense because you can just extend the path from within Delphi itself via options - environment variables (like Scott said). Only runtime packages are a spoiler if you try to run outside Delphi or need to compile from the command line.


Avatar
Vincent Parrett 5 years ago

Scott, if you use runtime packages you do need those entries on the path (for third party packages).

Taz, I used to do that, but the length limit applies to the expanded value so it doesn't work.

KM, I tried that, on my windows 7 x64 machine, if I open a cmd window, and type set, the path shows as truncated. I also had all sorts of problems with my machine because of the path truncation. I could not find a difinitive answer on the microsoft site, some pages say env variable can be 2047 chars, some say 1024. I've had this problem several times over the last few years, each time after installing a new version of rad studio.


Avatar
Scott 5 years ago

I'm not sure why they add them to the system path anyway.
I Rip them out.
In the IDE go to tools / options / environment variables.
Add a new user variable called "Path"
Add all the BDS paths followed by ";{PATH}"

This method works especially well with multiple versions installed.


Avatar
Taz Higgins 5 years ago

How about useing Enviroment Variables setup BEFORE the path entry and refer to those in the path entry
RSPROG=C:\Program Files\Embarcadero\RAD Studio\
RSDOCS=C:\Documents and Settings\All Users\Documents\RAD Studio
then in path
C:\Program Files\Embarcadero\RAD Studio\12.0\bin becomes %RSPROG%\12.0\bin
C:\Program Files\Embarcadero\RAD Studio\12.0\bin64 becomes %RSPROG%\12.0\bin64
C:\Documents and Settings\All Users\Documents\RAD Studio\12.0\Bpl becomes %RSDOCS%\12.0\Bpl
C:\Documents and Settings\All Users\Documents\RAD Studio\12.0\Bpl\Win64 becomes %RSDOCS%\12.0\Bpl\Win64

modify the rsprog and rsdoc strings to suit your system - this is from my WindowsXP VM


Avatar
KM 5 years ago

It is not true that the maximum path size is 1023 characters. Actually, the limit is 32k. In pre-Vista/2008 OS, the whole enviroment block is limited to 32k - thereby not allowing large environment variables, but that limit is now lifted (unless you're so stubborn to keep on using outdated and unsupported OSes...). Some tools and application may not allow more than 1023 characters in the path variable, but that's just a tool/application limitation (due to an old, no longer valid limit), not one of the system. You can edit directly the system path in the registry and use a far longer one, but beware some older, bad written application may break.
About the Delphi bad behaviour, I'm not sure it that code is in Delphi or InstallAware.

References:
http://support.microsoft.com/kb/906469/en-us
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682653(v=vs.85).aspx



Comments are closed.