Total Commander

TC is written in Delphi, sorry.

TC is written using Delphi 2.0.

Anyway, changing language from one to another requires a lot of hard work.

And, it is a bad idea for file manager to use C# or any other managed code.

MVV wrote: And, it is a bad idea for file manager to use C# or any other managed code.

Why?

VSB wrote:Why?

Because efficiency and performance are not among primary concerns in these languages.

MVV wrote:TC is written using Delphi 2.0.

That's a lie NOT 2.0, as Unicode support was added MUCH-MUCH later.

I reckon 7.0 was compiled with something like 2009 minimum. Otherwise it wouldn't use VCL with unicode.

2Egh
Maybe you're wrong. TC uses handmade unicode.

theosdikaios wrote:2Egh
Maybe you're wrong. TC uses handmade unicode.

Oh shiiiiiii ))) that looks like trouble then

As for D2 it is still insane though. You may have no need in VCL unicode support natively and stuff, however the golden standard of Delphi before 2009 (i.e. Embarcadero era) was Delphi7, not Delphi2. I started my career of a professional coder on Delphi5 and it was waaaaaaai back in the past

Still I would recommend to use Delphi2010, it is pretty stable with all the updates, and majorly compatible with pre-unicode releases, actually.

Have a look at here and here.

And here.

Yes, I've been using Delphi 2 with handmade Unicode support, but I'm currently porting to Lazarus/Free Pascal which has Unicode controls based on UTF-8. I have already ported all my Unicode controls to Lazarus, it was quite easy. Now I'm changing OLE2 code to Lazarus (Delphi 2 works quite differently here).

It is interesting to know size of TOTALCMD.exe in Lazarus where empty form takes 1.4 MB...

Lazarus_Faq#Why_are_the_generated_binaries_so_big.3F

It's also important to note that the hello world lazarus software already includes a huge amount of features. It includes:

• XML handling library
• Image handling library for png, xpm, bmp and ico files
• Almost all widgets from the Lazarus Component Library
• All of the Free Pascal Runtime Library

So it's very big, but it already includes almost everything a real world non-trivial app will need.

Well, let's hope its size really won't grow if additional components are added.

BTW I prefer clever linkers that remove unused stuff from output executable, especially if such thing can reduce file size from 1.4 MB to 0.4 MB...

I really don't understand how hello world application can use XML, image libraries and all untouched functions from runtime library. Also we don't need unused wigets and their methods since forms are not in resource section so can't be modified by resource editor in contrast to Delphi where we can easilly add controls to forms and call their unused methods (just 'cause that are included into executable code by linker even when unused in original executable).

Just found an interesting graph under specified link... They say that code generated by C++ compiler is larger than code generated by their compiler for complex projects... Yes, their hello world app's size grows only when code and resources are added while normal C++ application's code grows when new methods and functions are used too. But C++ executable starts with much smaller size, and good C++ compiler will never include same method twice, so for complex projects it will include a lot of functions almost like Lazarus app (BTW less than Lazarus anyway since it is almost impossible to use all methods of all components) so C++ executable will have smaller size anyway. Also good C++ compilers have great optimizators that reduces size significantly.

However, 1.4MB is not much of the concern here. In fact, 2010 unicode Delphi applications are typically around 1mb in size. My latest program about 800-900 lines of code (and only default linked units) was 1mb in size.

UTF8 in my opinion is not a good choice for components etc. Much better solution is two-byte everywhere, pretty much what Embarcadero uses since 2009. There "string" may be both normal ANSI and Unicode, depending on the switch, and that makes conversion almost transparent.