UltraEdit INI file location

bernie · Oct 19, 2006#12006-10-19T04:55+00:00

Info from Mofi: This topic was created by splitting up the posts from SSH/Telnet functionality in 12.20 -- can't find it into this and the linked thread!

Ah, yet another trap for UE being not-sufficiently-XP-aware. I didn't get that menu updated because that is *yet*another* thing that you end up needing to do as administrator. Even after all of these years, I'm surprised at how many otherwise-shaped-up applications *still* believe it is OK to store their configuration information in the install directory [or C:\Windows]...

This answered a bunch of questions [more to the point, since I've now "lost" the "do you want me to update the menus" dialogue box, is there any way to get it back [or at least find out all the OTHER things besides the SSH menu that I"m now missing because I don't run as administrator]? [I, too, thought I was going nuts looking for the SSH functionality. The help files talk about how to configure it, but not a hint [that I could see] about where you were supposed to find it].

Mofi · Oct 19, 2006#22006-10-19T10:32+00:00

bernie wrote:Ah, yet another trap for UE being not-sufficiently-XP-aware. I didn't get that menu updated because that is *yet*another* thing that you end up needing to do as administrator. Even after all of these years, I'm surprised at how many otherwise-shaped-up applications *still* believe it is OK to store their configuration information in the install directory [or C:\Windows]...

Since v10.20 all new installations store all configuration files in the personal user application data directory as suggested by Microsoft. This by default hidden directory is for installations on English Windows 2000/XP:

C:\Documents and Settings\user account name\Application Data\IDMComp\UltraEdit\

or correctly %APPDATA%\IDMComp\UltraEdit\ which is working on all Windows since Windows NT4.

So there is no problem with administrator privileges. For users who updated from a pre v10.20 installation the existing configuration files are used further independent where they are stored to don't lose any user setting after upgrade.

And yes, the configuration files can be anywhere - read in help of UltraEdit the page titled INI File Selection and Advanced Settings. See for example How to transfer configuration settings to a new PC which files you have to move from Windows to the application data directory or any other directory you want, for example with usage of environment variable UEINIDIR.

Manni · Oct 19, 2006#32006-10-19T15:52+00:00

The Windows directory should be off-limits for any application. If you want to share settings among all users, you can use the "All Users" directory under the %APPDATA% directory.
UltraEdit (at least v12.20 and above) do NOT work as advertised in the help file. Just before I encountered this thread, I tried very hard to fix my installation. I, too, am not working as administrator. UltraEdit will work fine until I do become administrator. It will then plant its INI file into the Windows directory although there is an INI file in the administrator's APPDATA directory. Changing back to my normal account, UltraEdit will then use the INI file in the Windows directory, but won't be able to change it, of course. I had to resolve to using the UEINIDIR environment variable to make it work.

Mofi · Oct 19, 2006#42006-10-19T18:54+00:00

Sorry Manni, but

That's what all IDM products do, except when installed on Windows 95/98 because the old Windows versions don't have an APPDATA environment variable although Windows 98 SE (not Windows 98) has also an application data directory. But the application data directory on Windows 95/98, if it really exists, can be only found via a registry entry which can but must not be present. It's easier for new programs which do not support Windows 95/98 or NT4 to be Windows 2000/XP compatible.
In the help it is explained in detail in which order the ProgramName.ini[/color] file is searched: first command line parameter, second the environment variable, third the program directory, fourth %WINDIR% and last %APPDATA%\IDMComp\UltraEdit. The last one is not possible on Windows 95/98 as long as the user does not set APPDATA in AUTOEXEC.BAT. If not found anywhere the last one is used which is APPDATA for NT4/2000/XP/2003 and WINDIR for all other where environment variable APPDATA does not exist. And that's exactly what I can see. Well, I have never tried it with a restricted user mode or using built-in administrator account of Windows XP. But I have several shortcuts with an INI file specified on the command line.

If you only copy your UltraEdit configuration files to the %APPDATA%\IDMComp\UltraEdit directory and not move it, UE will still find it first in the Windows directory and will continue to use it from that location. Please note, the search order is caused by compatibility. UltraEdit is a very old program. It exists since Windows 3.1.

Manni · Oct 19, 2006#52006-10-19T19:01+00:00

Believe me.

I have spent 30 minutes this morning to get UltraEdit working in a multi-user environment on Windows XP. I have a set of ini, uek, and whatnot files in the administrators APPDATA directory. UltraEdit doesn't give a f* and will use the Windows directory although I made sure to delete all UE files from there between runs. The *ONLY* option I was left with (because I didn't want to mess with shortcuts which won't work for double clicks or right clicks from Explorer) was the UEINIDIR environment variable.

I could NOT get UltraEdit to use administrator's APPDATA directory, no matter what the documentation says.

bernie · Oct 19, 2006#62006-10-19T23:34+00:00

Mofi wrote:Since v10.20 all new installations store all configuration files in the personal user application data directory as suggested by Microsoft.
...
So there is no problem with administrator privileges. For users who updated from a pre v10.20 installation the existing configuration files are used further independent where they are stored to don't lose any user setting after upgrade.

I don't think that UE asked me anything about my configuration setup when I installed the update [hard to remember now]. I believe that the only choice I was given was "what directory" and I selected the same directory I'd previously had UE installed into. It did ask me for a few "do you want me to overwrite the words file"-type dialogs, but if it warned me about the config files I'm afraid I missed it.

Mofi wrote:And yes, the configuration files can be anywhere - read in help of UltraEdit the page titled INI File Selection and Advanced Settings.

I see what you're saying, only I doubt seriously that the help file page on "INI file Selection and location" would be even on my top-ten list of "where to look to find SSH". And as I mentioned, I was a bit confused by the update: I fire up UE from my limited acct [from which I've used UE for a *long* time now] and I get a mysterious dialog [about updating the menu bar or some such] and then it says "failed". Other than that, UE was fine [oh, except: that I couldn't configure the SSH machinery until I had found and changed the ACLs for the UE config files in C:\Windows.

I see from your comment [and that I'm not the only one confused by the ACL/config problems with the upgrade] that moving from the awful world of the Windows 95/98 platforms to XP isn't such an easy thing to do (either for the application programmer or the user :)). I guess my inclination would be that when the program starts-on-XP and sees that it has Windows 95/98 config files, it might consider copying them into the XP-appropriate place for the current-user, rather than just using them from where they were. Perhaps something to think about as Vista looms and it will be even MORE picky about permissions and access than XP is.

Mofi · Oct 20, 2006#72006-10-20T11:52+00:00

To Bernie:

UE will not ask a user to move its configuration files to a new location. I have never seen a program that does that. Every program I have ever used continues to use the existing configuration files even when a new version would create it on a completely new installation in a different directory because of requirements of new operating systems. Well, Windows XP is not new ANYMORE, but it was in 2002 as Windows 2000 was in 2000.

All the configuration files are created or updated by the application itself and not by the installer. Only the program really knows what it needs. Also the program must completely handle the configuration file itself or multi-user environments (more than 1 user on 1 computer) will never be supported when only the user who installs the program get updated configuration files. So not the installer updates the INI, the key mapping configuration file, the menus and toolbars, UltraEdit does it on first start after upgrade for every user if every user has it's own INI (and for every INI if a user like I have more than 1 INI with also multiple *.mfg, *.tfg, *.pfg, ...). Because UE handles the configuration files, they are also never uninstalled by the installer. The installer does not know where the configuration files are stored. The uninstaller Total Commander is a little bit better because it asks the user if he wants to uninstall only the program files or also the 2 configuration (INI) files of TC. But even the uninstaller of TC does not uninstall personal menu/toolbar configuration files and INIs of TC not stored in one of the default locations. That's the job of the advanced user, who created these extra files.

For installation of upgrades (version number increases by at least 0.10 = major version increases or minor version increases by 10) always an administrator account should be used because the new version could need access to HKLM to register new features like the SSH/Telnet OLE control.

To Manni and Bernie:

If with a restricted account UE v10.20 or higher really does not use the uedit32.ini in the correct user specific application data directory although

the APPDATA environment variable of the restricted user account points to the correct directory and
the directory is not write-protected and
also really no other configuration files exist in the program directory of UE or the Windows directory and
UE is surely also started without /i= command line parameter and
no UEINIDIR is set

then please report this to IDM so the developers look into it and fix it. You can use Filemon and Regmon with Include filter set to uedit32 from SysInternals (Microsoft) to see what's going on at start of UE v10.20+ with a restricted user account.

Dec 01, 2006#82006-12-01T16:03+00:00

Readme.txt of v12.20a (later renamed to changes.txt ) contains following interesting line about the issue discussed above:

v12.20a 2006-10-26

Fixed issue with INI file using windows directory when Admin user

The problem existed only for the default built-in administrator account of Windows XP, not for any other account with local administrator privileges as I use since I have Windows XP. Microsoft strongly recommends not using built-in administrator account as standard account for work. The built-in administrator account should be used only for recovering tasks or for application installs and uninstalls on using by default a restricted user account.

JamesR404 · Mar 30, 2009#92009-03-30T08:50+00:00

Dears, thank you for this interesting thread.

I had the same problem where UltraEdit would start using the Windows directory to store it's ini file when my account was temporarily granted administrator privileges (to resolve another unrelated issue), and then I couldn't change my settings anymore :S

Well, will now use the environment variable and expect that'll solve my issue. Thanks for the tip! :)

LordLiverpool · Apr 23, 2009#102009-04-23T14:48+00:00

Sorry to labour the point, but what is the situation as of version 14.20.1.1008? Do you still need the environment variable?

I've tried the above version and it still appears to ignore Documents and Settings\<user>\Application Data\IDMComp\UltraEdit. If you remove the INI file from Windows, it merely resorts to default settings.

Will this be fixed?

Mofi · Apr 24, 2009#112009-04-24T07:33+00:00

Since v12.20a of UltraEdit the default location for the INI is always %APPDATA%\IDMComp\UltraEdit except when one of the following conditions is true (order is important):

UltraEdit is started with the command line parameter /i="Name of INI file with full path".
There is an environment variable UEINIDIR with full path to an existing directory where the INI of UltraEdit should be stored.
There is already a file named Name of UltraEdit executable.ini in the directory of the UltraEdit executable just started.
There is already a file named Name of UltraEdit executable.ini in the directory associated to environment variable WINDIR or SystemRoot.
Environment variable APPDATA does not exist (default for Windows 95, Windows 98, Windows 98 SE) resulting in using directory of environment variable WINDIR.

For Windows NT4, Windows 2000, Windows XP, etc. the environment variable APPDATA is created and set to correct path by default automatically by Windows. However, it is possible to open a command shell window, enter the command set APPDATA= to delete the environment variable for this command process and then start UltraEdit. That will also result in using the Windows directory for the INI on any Windows.

Well, I have not tested yet if UE v14.20.1.1008 has again a problem with the default built-in administrator account. On my Windows XP and also my Vista computer I have full administrator privileges and therefore never need the built-in administrator account. On Vista that was not easy, but I finally have had success to get the same rights as the by default disabled built-in Vista administrator account on my Vista computer (= no security problems anymore, but also no protection anymore against malicious applications).

sklad2 · Jun 16, 2009#122009-06-16T16:41+00:00

Since UltraEdit v12.20 the location and name of the INI file UE is working with can be found under Advanced - Configuration - Application Layout - Advanced.

Mofi · May 26, 2018#132018-05-26T17:53+00:00

UltraEdit is a full Unicode aware application since UltraEdit for Windows v24.00. UEStudio is a full Unicode aware application since v17.00.

The change from an application supporting editing Unicode files to a full Unicode aware application made it necessary to store the settings in INI file UTF-16 Little Endian (two bytes per character) instead of ANSI encoded (one byte per character) to support not only Unicode find/replace history entries (saved UTF-8 encoded up to UE v23.20 and UES v16.20), but also Unicode file/folder names.

For that reason is used by default:

uedit32u.ini instead of uedit32.ini by uedit32.exe;
uedit64u.ini instead of uedit64.ini (or uedit32.ini on upgrade from 32-bit to 64-bit) by uedit64.exe;
uestudiou.ini instead of uestudio.ini by uestudio.exe. There is no difference in file names between 32-bit and 64-bit UEStudio.

Full Unicode aware 32-bit and 64-bit UltraEdit and UEStudio still search first for the INI files without u in file name in the application's program files directory, in Windows directory and last in application data directory if started without command line option /I= and with no environment variable UEINIDIR set. If an INI file with that name is indeed found and the directory of found INI file contains also already the Unicode version with u in file name before file extension, the Unicode version of the INI file is loaded and the ANSI version in same directory is completely ignored. A found ANSI encoded INI file with no Unicode encoded INI file in same directory is loaded, upgraded and saved as Unicode encoded INI file finally.

The ANSI encoded configuration files are not automatically deleted by UltraEdit/UEStudio after first start and exit after upgrading UE/UES in case of a user decides later to uninstall the newer (not licensed) version and reinstall the older (licensed) version supporting only ANSI encoded configuration.

The ANSI encoded uedit32.*, uedit64.* and uestudio.* files are in real no longer needed after an upgrade to UE v24.00 or UES v17.00 or any later version and the decision has been taken by the user finally for working in future with full Unicode aware version of UE/UES. Therefore a user can delete them to save some storage space and speed up start time of UE/UES a little bit although not really noticeable.

The Windows directory should not be used anymore as storage location for the UE/UES configuration files with full Unicode aware UE/UES versions not running anymore on Windows versions prior Windows 7.

But it can still make sense to use a not write-protected UltraEdit/UEStudio program files directory as storage location for the configuration files, for example on often using multiple user accounts on same machine or on often switching between various versions of UE/UES like I do often to answer forum questions not related to currently latest version of UE/UES.

One fact must be taken into account on having the configuration files located in folder containing also uedit32.exe or uedit64.exe or uestudio.exe (x64 or x86 version): executable file nameu.ini is not recognized in directory of the executable if there is additionally no executable file name.ini, too.

Conclusion: It is best to define environment variable UEINIDIR respectively UESINIDIR with path of UltraEdit/UEStudio program files folder as value either as user or as system environment variable to still have (most) configuration files in program files folder of UE/UES after deletion of ANSI encoded uedit32.*, uedit64.* and uestudio.* files.