Okay, some paragraphs about history, especially about application data files on Windows operating systems for a better understand why that happened what unfortunately happened.
Since v10.20 UltraEdit creates the default uedit32.ini and MOST other and since v14.00 ALL user configurable application related data files in %appdata\%IDMComp\UltraEdit on first start as long as there is an environment variable APPDATA (Windows NT4, Windows 2000, Windows XP, etc., but not Windows 95, Windows 98, ...). But if there is an uedit32.ini, uedit32.kbd, ... from a pre v10.20 release of UltraEdit in one of the directories where UltraEdit finds uedit32.ini automatically, then this INI and its location is used further.
In help of UltraEdit on page
INI File Selection and Advanced Settings it is documented which options a user has to control the location and name of the INI file and the other user configurable application related data files which must be in the same directory as the INI file and in which order UltraEdit searches for the INI file.
For example you can read that UltraEdit searches for uedit32.ini in the directory of UltraEdit too. So I moved long time ago (I think it was v8.20) all UltraEdit related data files into the directory of UltraEdit which has the big advantage for me to be able to easily backup whole UltraEdit - program files with the data files with my settings. I need this because like IDM support from time to time I answer questions for users not using the currently latest version and then it is very practical to simply rename the program directory of UltraEdit and restore from an archive the older version, start it and try to find and an answer for the user with that older version.
Of course handling application data files in the program directory are by default not what Microsoft NOWADAYS allows for security and because that method does not support multiple users on the same computer. The Microsoft standard for Windows 95/98 (single user operating system) was that any program which used the MFC functions for reading from and writing to an INI file strings and numbers have automatically used a file in %windir% named like the applications file name, but with the file extension INI instead of EXE. So a Windows application developer has had nothing to develop for handling the INI file by itself. The MFC functions created the INI file in the directory which Microsoft has intended for application data files, write to it and read from it.
The change of the policy of Microsoft starting with Windows NT4 (a multi user operating system) was now a big problem for all applications used that MFC functions and of course should support Windows 95/98 parallel to NT4. Microsoft itself solved that problem by moving more and more into the registry. A policy I don't like because it is very hard to backup settings of an application stored in the registry. However, IDM offers also to store the settings in the registry instead of an INI file for those users which like the Microsoft philosophy which has surely also some advantages. The affect on saving everything in the registry, even histories, logs, help texts, etc. can be seen when comparing the size of the whole registry. If I export whole registry of my Windows 98 with all programs I needed installed to a text file, the file has about 6 MB. If I do the same on my Windows XP with all my programs installed, the file has already 25 MB (the ASCII version, not the UTF-16 LE version). And the registry export of my new computer with Vista Business and currently only the drivers installed has more than 200 MB. (One of the things that I want to find out on my new Vista computer before really start working with it: Why has it so a large registry?) You need to know that whole registry is loaded into RAM on Windows startup, of course in a more compact format than the text file export has. However, you can see why Vista needs more RAM.
Okay, back to handle settings in files instead of the registry as many shareware and freeware programs do, especially those which exist also for other operatings systems, because there is no registry on Linux or MAC OS. Windows NT4 as well as Windows 2000 was now real problem for the developers of applications using an INI file, because these operating systems supported still the creation, writing and reading of INI files in the Windows directory. Also Windows XP used most of the time, especially in the beginning until 2005 or so, with administrator accounts supported the original INI file handling mechansim of Windows 95/98. So there was no real need for applications with a long Windows history and supporting all operating systems from Win98 to WinXP to change something on how the settings are stored. I think, starting in year 2005, more and more security has become important and especially companies started with using only restricted user accounts. With Vista many "old" applications needed to be reworked on the mechanism how and where to save the user settings of the application. And this process is still not finished for most applications, except the complete new ones which ignore their application history or simple do not have an application history because the application is really new.
I like UltraEdit because it is so highly customizable and that includes also how and where the user settings are stored. It is possible to use the registry for those users which like that. It supports the Microsoft default for the multi-user Windows versions with the user specific application data directory. But UE still supports also the single user philosophy, especially with the data files stored in the program directory. I personally never liked the Microsoft philosophy with the INI files in the Windows directory. So nearly all my programs on Windows 98 have their INI file in the program directory. But also supported is a completely customized data files storage mechanism with environment variable UEINIDIR which is for example good for a single user computer with multiple Windows versions. It is even possible to use just for a project a different INI file and depending on the directory of the INI also a project specific menu, toolbar, key assignments, etc. by starting UltraEdit with the /I="..." command line option which I still use for some of my projects.
So it is completely up to you. Setup whatever you like - see help page
INI File Selection and Advanced Settings and the forum topics
UltraEdit INI file location and
How to transfer configuration settings to a new PC.
Well, it is surely not OK that UltraEdit simply packs all files of the directory with the INI into the backup and restores it if the INI is in the Windows directory. The problem is that
Other is for all
other files created by the user in the application data directory. The dialog lists all the files in this directory - in my case among some of my files also all the UltraEdit program files because the directory of the INI (the application data directory) is the UE program directory. So you have the possibility to select which OTHER files will be included in the backup and which not.
Maybe to avoid the indeed very dangerous and critical situation you have described it would be a good idea that UltraEdit would check if the directory of the INI file is the same as the directory stored in environment variable WINDIR. If this is the case
Other should not be available for backup. Would you suggest that IDM?
