I tested with 32-bit UC Professional v15.20.0.11 a text comparison of 2 ASCII/ANSI files by using uc -t -ne C:\Temp\Test.bat C:\Temp\Test2.bat and uc.com started uc.exe and halted execution until UltraCompare GUI application was exited by me. GUI UC displayed correct just the differences between the two batch files (additional lines and differences within some lines). My default is displaying all. So parameter -ne was recognized correct although being specified on an uncommon position on the command line.

Starting GUI version with using uc.exe -ne -t C:\Temp\Test.bat C:\Temp\Test2.bat (directly start GUI version and -ne at common position on the command line) worked also perfect on Windows 7 x64.

I must add that I started uc (.com as used by Windows command interpreter according to environment variable PATHEXT and found first and .exe as explicitly specified by me) with full path from command line as I have removed UltraCompare program files folder from system environment variable PATH because I don't like it having directory paths defined in PATH not really needed by me on working within a command prompt window.

I suggest to check your PATH variable if there are multiple UltraCompare directories defined.

I suggest also to open in UltraCompare View - Themes - Manage Themes, select tab Compare and check the colors defined for displaying text differences in the UltraCompare theme used by you.

I don't have the 64-bit version installed on Windows 7 x64 to test if the 64-bit version produces also the expected result like the 32-bit version.

To mqg999,
I have tested with UC 15.20.0.11 x64@Windows 7 SP1 x64 with command line "uc -t -ne myfile.1 myfile.2" and for me working fine here ... Only differences were shown ...

"Not enough memory", or a bad_alloc exception as named in C++, can have many reasons:

• There is an error in code of the application (bug) - must be examined by a responsible software developer to fix it.
• RAM is heavily fragmented and therefore there is much available memory, but not much in a continuous block - reboot of machine helps.
• RAM is defect, a single bit failure (stuck 0 or stuck 1) causes abnormal code execution from time to time in various applications - executing the RAM test of the computer's manufacturer could be used to check that.
• Hard disk is defect and therefore the code of the application is not loaded into RAM as it was originally stored on hard disk - executing full hard disk check could be used to check that.
• An application is not written well and takes more and more GDI objects until limit of 65536 (default) is reached which is often not bad for already running applications, but for newly started applications - reboot of machine often helps and of course not using the application using more and more GDI objects.
• An application is not written well and takes more and more user objects which is usually a problem for the not well coded application only - restart of application often helps.
• An electromagnetic interference caused temporarily a memory corruption resulting in abnormal code execution. This reason is not possible to detect without special measurement equipment and can be detected at all only when abnormal code execution happens frequently caused by electromagnetic interferences.
• Others ...

The number of GDI and user objects used by a running process can be viewed on processes tab of Windows task manager or in Sysinternals Process Explorer after adding the appropriate columns.

Conclusion: Abnormal program execution is interesting for further examination only when it occurs several times within a certain period of time. The time period depends on device and importance of the application running on the device. A mobile phone for usage by people is completely different to a power plant control or protection device in regard to failures within a period of time.