Okay, let's start a new user to user discussion about startup time of UltraEdit in addition to UltraEdit is getting very slow on startup because of a start time of 1 to 3 seconds is typical for UltraEdit v28.10.

I suggest first opening the file changes.txt in program files folder of UltraEdit and search in this file for the word startup. It is found multiple times. It can be seen that IDM Computer Solutions, Inc. is aware of the fact that the startup time is very important for many user and there is spent time in development on what to change in code of UltraEdit to decrease the startup time. I know that IDM really analyzes frequently which part during startup requires which span of time to finish and look if there can be something done on those requiring most time on startup. But before I go into the details, let me first explain some basics regarding startup time of an application.

The startup time of a Windows application is affected by factors which can be controlled by the programmer of an application and by factors which cannot be controlled by an application programmer.

Factors not controllable by a Windows application programmer:

1. The hardware used by the user which is type and speed of chipset, processor, graphic processor, RAM, hard disk, screen (physical dimensions and resolution), network, etc.
   The software developers of Apple coding applications for macOS have it much better than the software developers for Windows because of Apple controls the hardware production and which hardware should be supported by which software, too.
2. The operating system used by the user. The newer the version of Windows the slower is it and the startup of the applications.
   I have an eight year old notebook with a new fast SSD with natively installed Windows XP, Windows 7 and latest Windows 10 all with all security updates. The time required to start and shutdown Windows XP and applications on Windows XP in comparison to startup and shutdown of Windows 10 and starting the same applications in same version is nearly not believable. Windows XP is approximately 20 times faster on same hardware.
   BTW: I replaced the original installed HDD of the notebook by a fast SSD because Windows 10 is not usable with a HDD.
3. The processes running in background on the user´s machine taking hardware resources all the time and so reduce the resources available for an application during startup. It is of no help for an application using threads like UltraEdit on startup if most cores are already busy to process other processes.
4. Additional applications running in background on the user´s machine like anti-virus applications scanning always all executables and dynamic linked libraries. It makes a really big difference on some anti-virus applications (not on all) if it is running in background on starting an application or is currently turned off.
5. The configuration of Windows as defined by the user and the applications installed by the user. UltraEdit uses several DLLs of Windows which are stored in the Windows system directory or in Windows side-by-side directory. Having %SystemRoot%\System32\system as first directory in system environment variable Path is very helpful for UltraEdit and any other Windows applications to more quickly find the used libraries on startup.
6. The configuration of the application made by the user. UltraEdit is an extremely customizable application. So a user has lots of possibilities to decrease or increase the startup time of UltraEdit with the configuration.

Factors controllable by a Windows application programmer:

1. How the code itself is written used on startup.
2. The outsourcing of features into dynamic linked libraries not loaded on startup.
3. The file size of the main executable and when the main application window is displayed first.
4. The numbers of resources like icons and translatable strings the application offers already in main application window.
5. The usage of threads to do something later in background not immediately used on displaying the main application window first.
6. The structure of the files used to store user configurations and the number of configuration files and when each configuration file is loaded.
7. The outsourcing of main application into an executable started already in background on startup of Windows as a service and the executable started by the user is just a small interface process for the real process already running in background.

How can a programmer best avoid that each new application version does not need more time to startup?

It can be done best by adding new features not to core of the application loaded and initialized on startup, but by storing them in DLLs loaded later in background with threads or when the user first time wants to use the feature. This concept is used for some features of UltraEdit, but most of the features are included directly in the executable as core features even on some users often not making use of all these features ever. The advantage on adding a feature to main executable is its faster execution which is for many users also very important.

Other applications like web browsers have quite often nowadays a quite small executable which is loaded and next executed quickly by Windows and which show quickly the frame of the main application window and so it looks like the application starts quickly. Well, in real those applications load next in the background many of their DLLs and it takes also several seconds before the web browser is really fully started and can be really used by the user. Web browsers have the advantage that the usually do not open files from local hard disk, but have to load files from the World Wide Web and so no user can really see that their real startup time is also several seconds as the users think the loading of the files from the World Wide Web takes some seconds.

The best tool to find out what is really going on in background is Sysinternals (Microsoft) Process Monitor. It has helped me a lot to find out what is going wrong with UltraEdit and lots of other applications and it reveals all the dirty tricks used by software producing companies to deceive the application users about real resource usage and startup time of their applications.

Okay, let's talk about UltraEdit and my personal observations of it.

It is a fact that reading/writing settings from/to Windows registry is much faster than reading/writing them from/to a file because of the Windows registry is a set of database files always loaded by Windows in memory. The access of a specific value with known key in Windows registry is much faster than accessing the same value in a file. The dramatic growth of the Windows registry from one version of Windows to next version of Windows taking into account that the user must use a hardware with enough RAM to load the permanently increasing Windows registry into memory and having nevertheless enough free RAM for applications, services and processes and that Microsoft and many other companies store nowadays data in registry which are definitely not configuration data for which the Windows registry was originally designed is a very good proof of that fact.

So a user of UltraEdit could configure to use the registry instead of a file for the configuration settings. However, the usage of an INI file (or two nowadays) for the configuration settings is the default (and makes it possible to synchronize them via the cloud). For that reason I could observe in the past several changes on how UltraEdit reads and writes settings into the INI file(s). While there was initially used by UltraEdit the Windows base library functions GetProfileString and WriteProfileString which are horrible slow on accessing the data in an INI file with hundreds of settings, there have been made changes in code of UltraEdit according to what I could see on looking on the INI file of UltraEdit in the last 15 years to reduce the time required to read the settings on startup and write them on exit. I do not want to get too deep into the details, but UltraEdit for Windows v28.10 writes now into ue.ini only those settings which are different to default and read and write is done very efficient now.

There could be used initially only one syntax highlighting wordfile with only up to 10 languages inside with only up to 8 color groups. Now there can be lots of separate wordfiles in the wordfiles directory each with up to 20 color groups. It should be clear that it takes more time to load on startup more wordfiles with more settings and words than 15 years ago. The user can decrease the time required by UltraEdit to read all the wordfiles and interpret them on startup by removing those wordfiles never used by the user. However, I could see with Process Monitor also that changes were made in code of UltraEdit to load the wordfiles faster and especially apply the syntax highlighting and all the syntax highlighting based features later on the files loaded on startup by using threads Most users of UltraEdit use the document window maximized and so it is enough to syntax highlighting first the active file and process the other files with threads in background on searching for function strings and code folding strings, etc. and that is done now by UltraEdit.

The support for themes has a dramatic effect on startup time and on each drawing of a window. I think the nearly fully customizable themes feature was requested by many users. I think that for many users the look of an application is more important than its feature list and how to use the application efficiently as the vast majority of users use just a very small percent of an application very inefficient. I watched these already 25 years. I am astonished again and again how - sorry, I must use this word - handicapped people are using applications and so wasting tremendous much time instead of taking a short time to get knowledge how to use the application. Does the startup time really matter for me on using UltraEdit and UEStudio all the time during a work day? No! Why not? I start them once and exit them once in case of not having kept them opened over night while computer was turned off by using hibernate mode which is used by me since Windows 98 and still used on Windows 7 and Windows 10 on which hibernate must be extra enabled for making use of it with a simple key press on keyboard. But I am digressing, so back to themes feature.

The standard themes have hundreds (or thousands, never counted them) of settings in an XML file which of course must be loaded by UltraEdit on startup. There is one theme file which is much smaller than the others, the file of Classic theme. The reason is that the Classic theme has a quite pure look on which most elements are not customizable at all. There is no color fading and no shading with Classic theme which makes drawing the elements much faster as just rectangles with just one color inside each rectangle must be drawn.

But the usage of a standard theme installed by default with UltraEdit has one more disadvantage regarding to startup time. It contains also the color settings of all syntax highlighting languages installed by default. So even on deletion of the wordfiles in the wordfiles directory configured by the user respectively the wordfiles directory in application data directory of UltraEdit never used by the user, the write-protected default theme files used by the user still contains the theme settings for not anymore used syntax languages and UltraEdit must parse them too although not needed later. The solution is using a custom theme file stored in the fully writable themes directory in application data directory of UltraEdit on which UltraEdit removes the languages from the theme file for which there is no syntax highlighting wordfile in the wordfiles directory. So the custom theme file contains only settings really needed by the user and no time is wasted anymore with parsing data later not used at all.

It could be watched in the last years mainly driven by the apps development for smart mobile phones that the user interfaces of many applications becomes more and more puritanical. An always visible menu - users don't need that as vast majority use only a very small subset of available commands. So no menu needed which saves a lot of time on startup and on each drawing of application window. The ribbon interface the vast majority of UltraEdit users voted for years ago on a survey is extremely time consuming on loading the data and on drawing it. While in older versions of UltraEdit with no support for a ribbon interface the menus were fully customizable by the users which of course required loading the data from the text files containing the definitions of the menu, the customization of the ribbon interface is very limited. The standard ribbon tabs cannot be customized. There can be only added custom tabs with custom groups and commands. The faster displayed toolbar/menu mode is customizable (via the ribbon interface) only on using contemporary menus. The traditional menus are fixed coded inside UltraEdit. In toolbar/menu mode are mainly used toolbars by users which prefer to use a pointing device in a text editor than the keyboard and for that reason the toolbars are fully customizable. The ribbon interface and the toolbar data are stored now as binary streams in INI file of UltraEdit for faster loading and saving them instead of a text file in text form which could be easily modified with any text editor (including UltraEdit of course).

A really horrible effect on startup time was caused by users using a screen with small physical dimensions, but with a high resolution definitely not suitable for human eyes for that screen. A 13" screen with a resolution of 1920x1200 can be used only by people using the computer just for viewing videos, photos and browsing with a web browser in the World Wide Web. But there were also lots of users of such a hardware using UltraEdit and complaining that the built-in icon set for the several hundred commands of UltraEdit are two small for their eyes in the dimensions 16x16 and 24x24 pixels. Well, those users purchased the wrong hardware for their usage. But IDM take care of their complaints and added icon sets with all icons also in larger dimensions like 32x32, 48x48, ... 112x112. The resource DLL ueres.dll grew dramatically by this change to support high resolution screens with small dimensions. I would have been a good idea using a separate resource DLL for each set of icons and load on startup only the resource DLL currently needed according to user configuration and hardware. That is definitely a point which could result in a small decrease of startup time of UltraEdit as small resource DLLs are always faster loaded than large resource DLLs.

The users requested in the past larger file, find and replace histories and IDM take them into account. The disadvantage with hundreds of history entries in INI file (now ue.vod file) is that hundreds of lines must be read on startup and added to the lists in memory. It is a good idea to clear all histories from time to time.

Okay, let me stop here for today. I can write more about what is going on in background and why UltraEdit becomes larger and larger over the years. I am now interested in your thoughts as up to now you wrote only a general complaint without any suggestions on how startup time of UltraEdit could be improved and why a startup time of 1 to 3 seconds is so bad for your usage of UltraEdit.

Special hint: Users not using the latest feature who just need a good text editor which is better than Windows Notepad with syntax highlighting and many other features not available in Windows Notepad should think about using a several years old version of UltraEdit. UltraEdit 10.10c has an executable file size of just 2 MB and all program files together have only 5 MB. It starts unbelievable fast on modern machines and is often good enough for many users.

PS: I don't know any craftsman who lugs tools around which are never used by the craftsman. But software users do that very often as they think software has no weight and large software does not produce more costs than small software suitable for their limited usage. That is not true. The startup time of UltraEdit does not really matter for me as thousands of seconds are saved by my extremely efficient use of most of the features of UltraEdit and UEStudio. Who really cares about three seconds of startup time if a single key press inside my much customized UltraEdit saves me hundreds of seconds?

My first tip is a general tip. It has no noticeable effect on startup time of UltraEdit and it does not help in the use case described by Hans. However, I want to start nevertheless with this general hint.

UltraEdit uses lots of functions of Windows libraries which are stored in the dynamic-linked libraries (*.dll files) in the Windows system directory because of UltraEdit is a real Windows application using frameworks of Microsoft in comparison to other text editors or IDEs using, for example, Java as framework for easier support of multiple platforms (operating systems).

The Windows system directory is %SystemRoot%\System32 on 32-bit Windows and 64-bit Windows respectively %SystemRoot%\SysWOW64 for 32-bit UltraEdit started on 64-bit Windows.

The directory %SystemRoot%\System32 is by default the first directory in system environment variable PATH to get the DLLs and EXEs in this directory found as fast as possible if an application or a used library searches for other libraries to load or executables to run. The files in %SystemRoot%\SysWOW64 are used automatically by 32-bit applications executed on 64-bit Windows due to the Windows file system redirector.

There are unfortunately installers of applications or application suites which add one or even more folder paths to system PATH left to first folder path instead of appending the folder path(s) at the end of the list of folder paths or being really smart and insert the folder path(s) after the folder paths which Microsoft added by default to system PATH depending on version of Windows.

I looked with Process Monitor how the Windows system libraries are loaded on starting 32-bit UltraEdit v11.20b (released February 2006), UltraEdit v22.20.0.49 (last version available for Windows XP released December 2015) and 32-bit UltraEdit v28.10.0.26 (currently latest version released May 2021) on 32-bit Windows XP and 64-bit Windows 7 with system PATH being redefined first to have as first directory a different and of course existing directory than %SystemRoot%\System32. UltraEdit loads the system libraries first directly from the Windows system directory for faster startup and also for security. The folders as defined by the local environment variable PATH (concatenation of system and user PATH as done by Windows Explorer instance running as Windows shell) are used only if a system DLL cannot be found in the Windows system directory like shcore.dll on Windows 7.

Therefore it does not really matter for UltraEdit which folder paths are in which order in local environment variable PATH on starting UltraEdit.

However, it is in general advisable to take care of system and user environment variable PATH by

1. opening the Windows Control Panel (available also on currently latest Windows 10 21H1),
2. clicking on System and Security (on Windows Vista and newer Windows versions with View by: Category configured,
3. clicking on System (Windows XP and newer Windows versions)
4. clicking on the link Advanced system settings on left side (Windows Vista and newer Windows versions) or selecting tab Advanced (Windows XP) and
5. clicking on button Environment Variables.

There should be made sure that the folder paths in system PATH (the lower pane since Windows XP) are:

1. %SystemRoot%\System32
2. %SystemRoot%
3. %SystemRoot%\System32\wbem
4. %SystemRoot%\System32\WindowsPowerShell\v1.0\ (on Windows XP only if PowerShell is installed at all)
5. %SystemRoot%\System32\OpenSSH\ (only on Windows 10 1809 or a newer version of Windows 10)

Other folder paths of system PATH should be after/below these folder paths. These three to five folder paths should be really defined with %SystemRoot% and not with C:\WINDOWS. An installer made something wrong on system PATH is defined with these three to five folder paths with C:\WINDOWS (or on whatever drive Windows is installed) at the beginning instead of %SystemRoot%. C:\WINDOWS can be kept in this case, but better would be to restore these three to five folder paths to their original definitions as listed above with the environment variable reference.

Other folder paths should be right/below these three to five folder paths. There should be no folder path more than once in system PATH and of course all folder paths should still exist. So remove duplicate folder paths and paths of folders not existing anymore.

The user environment variable PATH does not exist by default at all. So user PATH is always a custom environment variable although it is often not customized by the user of an account, but by applications installed by the user. The user PATH should not contain folder paths which are already in system PATH and should not contain duplicates or paths of non-existing folders.

It is of course completely wrong to have in system or user PATH a file name with full path. Full qualified file names should be always removed from PATH.

The installers of UltraCompare, UltraEdit and UEStudio append the path of the installation directory of UC/UE/UES on every install/upgrade/update also to system (install for all users) or user (install for current user only) PATH on not being already in related PATH. That is done for users which use uc.com, uc.exe, uedit32.com, uedit32.exe, uedit64.com, uedit64.exe, uestudio.com, uestudio.exe manually from within a command prompt window, PowerShell console, Windows Terminal, or a script file like a batch file, VBScript, PowerShell script, etc. without using the file name of the executable with full path and file extension. uc.com is a Windows console application for usage in scripts like a batch file which runs uc.exe and outputs the results to standard output stream or in case of an error to standard error stream and exits with an appropriate exit value. uedit32.com and uedit64.com were introduced with UltraEdit v27.00 for users who want to use UltraEdit in scripts to calculate a hash value for a file depending on the used arguments. uestudio.com was introduced with UEStudio v20.00 for the same reason. The console version of UltraEdit and UEStudio with file extension .com starts the executable with file extension .exe on being started without the option to calculate the MD5, CRC, SHA1 or SHA256 value of a file with passing the arguments to the Windows GUI executable and then terminating itself.

The program files folder path of UC/UE/UES should be removed after any kind of installation of UC/UE/UES on starting never manually UltraCompare, UltraEdit, UEStudio from within any kind of console window or any kind of script without using the full qualified file name because of there is in this case no need for the UC/UE/UES program files path in PATH. The uninstaller of UC/UE/UES removes the added folder path also from PATH which can result in user PATH being defined as environment variable with no value at all after uninstall in which case it would be good to delete user PATH completely. I have written for myself a small batch file to remove the folder paths of UC/UE/UES and an empty user PATH which I execute manually after install/uninstall of UC/UE/UES. The batch file is not designed for general usage, just for usage on my Windows computers. So I cannot share that batch file with other users of UC/UE/UES.