Leaderboard

Well, the FormatFloat implementation has the E15 hardcoded and even documented:

Over the last two years, I've converting Delphi 2007 applications to modern compilers. Not finished yet. Apart from all the other comments made, a couple of my own. Avoid the simple solution of using AnsiString, you will end up with thousands of compiler cast warning and have trouble with functions that use UnicodeString. Use TBytes for non-string data, there are lots of ways of converting TB to other formats Look at file handling carefully, loading a text file into a TStringList will result in Chinese as it assumes it's reading unicode, unless it finds a BOM or is told otherwise, ditto saving files. Angus

My take on this is that you want to start making changes in your Delphi 7 code base that don't change the meaning of the program there, but mean that it will compile and work as expected in both ANSI and Unicode Delphi. In an ideal world you'd be able to do all that work preparing for the switch and reach a point where you can compile with both ANSI and Unicode Delphi, and the program works the same. Then you can cut the chord to Delphi 7 and commit to Unicode Delphi. Then you do the second piece of work which is to get the code working on 64 bit.

Actually for good clean code it's just a matter of rebuild and fix slight API changes. But years back Delphiers used too much hacks/incorrect constructions that will break and most of them come from 2 presumptions that are now invalid: - Char is 1-byte (wrong since D2009 - now it's 2 bytes) - Pointer is the same size as Integer (wrong for x64) Also using generic Delphi types for WinAPI calls instead of those specified in docs (like Cardinal instead of DWORD) was very widespread and also will cause troubles on x64. That said, I'd recommend to read advises regarding porting and do like guys said above: check availability of 3rd party components, then ensure clean code in each unit, then port to x32 app in modern Delphi, then build as x64. You'll likely have to create many test projects that use only a few of units just to test things are OK.

I would (did not think this too much) something like this. Go code trough with D7, make it is modern at it can get. (Few refactoring rounds, get rid of code that is not in active use etc) Update all 3rd party components and libraries. Get rid of those not available for modern delphi versions anymore and not supported Get rid of all visual components that are not absolutely needed. In legacy app there might be visual components form 5 different libraries or something like that. If can get byt, use stock Delphi components as much as you can. Mainly just reduse code base as small as you can, before start using new Delphi. Move to the new delphi and make 32bit app with that. Refactor and further modernice as much as you can. Do 64bit port as last step. -Tee-

You'll be using the command line compiler so you can use any account you like; The compiler is just a regular console application. And as far as I remember you don't even need a license. Just copy the files from an existing installation.

I have no knowledge of any tool for automatic conversion (even partial). There are several contexts you should pay attention to when converting: 1) string: currently the definition is Unicode, in Delphi7 it was synonymous with AnsiString; 2) char: 1 character occupies two bytes. in Delphi7 it occupied 1 byte; 3) several definitions have changed in both core and third-party components; 4) several basic components distributed with Delphi7 are no longer distributed with Delphi 10.3, and obviously there must be third-party 64-bit components if you use them; 5) when converting between 32 and 64 bit you must pay attention to the various types of parameters, especially in third-party DLLs: PChar, PWChar, PAnsiChar.... 6) Integer, cardinal, nativeint, etc.... 7) Floating Extended type is 80 bit long in 32 bit application, but in 64 bit is an alias of double (64 bit long); 8 Pointers in 32 bit platforms are 4 bytes length, in 64 bit platforms they are 8 bytes length. 9) In 64 bit platforms you cannot mix assembler and pascal in the same method. 10) more other stuff Look here for more info: https://docwiki.embarcadero.com/RADStudio/Rio/en/Converting_32-bit_Delphi_Applications_to_64-bit_Windows Good luck and good work

It depends on the actual sources. I have had projects that just needed a compile with the new version and target, while others lasted several months.

First of all, keeping the default names for the buttons has never been best practice. While suggesting to have descriptive names for the buttons, this nevertheless is another way to iterate over any group of buttons: for var btn in [Button1, Button2, Button3, Button4, Button5] do btn.Enabled := True; And, no, you can't write [Button1..Button5] here.

Yet, you didn't mention how the import happen, here an imaginary scenario that will generate that behavior (more or less), if your application grabbing these imported data from internet and using event based network, then the data will come as message and will interfere with other messages, causing a growing delay, this will accumulate till the message queue is full or just the delay getting greater for the OS to detect it right away but after a while the respond from the application the OS decide it is frozen. as a solution in all cases switch to background operation, and don't use Application.ProcessMessage, it will save you great headache later and most likely should be removee it eventually.