I'm quite sure that it will be a task for 12 to 18 months or even more for the IDM developers to rewrite all code lines for 64-bit. It is not really difficult to code an application nowadays from beginning for compilation as 32-bit and 64-bit application. But making a nearly 20 years old software really working as 64-bit application is a nightmare task for every programmer. Every pointer must be changed in type. That often requires also changing of structures containing pointers or integers holding memory addresses. The change of structures requires often more changes on code, and, and, and ...
I have once converted a very small code never designed for 64-bit from 32-bit to 64-bit. As I started, I thought that I could finish it in 3 days. Than I needed more than 2 weeks. Which programmer has in the past (5 and more years ago) ever take care of type size_t
in C/C++ and used this type instead of simply int
or unsigned int
. Well, the C library used always size_t
, but I must confess that I have never done that for my C/C++ projects. I just started in the last 3 years for new projects to take care of bit width of variables and structure elements, and make sure that the code can be compiled also for other processors or controllers from 8-bit to 64-bit.
The author of my favorite file manager Total Commander worked more than 2 years on this great tool to make it working as 64-bit application in several steps.
Another problem is all the additional open source code included in UltraEdit, or loaded from a DLL, or executed from within UltraEdit. All this third-party source code needs to be x64 compatible, too. Total Commander is again a good example as there are lots of plugins for TC. With the release of Total Commander 8.00 with x64 support internally and also for the plugins, all the plugin authors were quickly forced by the user community to unpack their plugin source files not touched in the last years, get a 64-bit compiler, recode, compile and test their plugins for x64.
I'm quite sure that IDM must grasp the nettle somewhere in the next 3 years and start making UltraEdit compilable (can be quite easily achieved) and working (that's the really time consuming task) as 64-bit application although approximately 99% of all UltraEdit users never really need a 64-bit editor as using it only for editing small text files. For my tasks I don't need a 64-bit UltraEdit / UEStudio.
Okay, after sharing my opinion on the need of a 64-bit UltraEdit, back to task on how to copy large, very large chunks of text from one file into another.
UltraEdit has two functions for this task already included since I'm using UltraEdit which is since UE v8.00:
- File - Save Selection As which can be used instead of Ctrl+C, Ctrl+N, Ctrl+V and F12.
- Insert - File to insert content of another file at current caret position into active file.
BTW: There is View - Views/Lists - Clipboard History
which I never use which could be a reason why UltraEdit fails to allocate RAM for copying a text selection of 750 MB as 2x 750 MB would be needed. It is very probable that there are not two RAM blocks of consecutive 750 MB of free RAM. It could be that UltraEdit does not append such a large block to clipboard history. I have never analyzed the behavior of clipboard history feature as I'm not using it nor do I work with so large files. The largest text file I work with from time to time is an ASCII/ANSI export (Win9x format) of the entire Windows registry and even this file is smaller than 75 MB.
The blog article WOW64: Memory mapping of 32bit apps running on a 64bit Windows
was very interesting to read.