Total Commander

Egh wrote:And considerably cheaper than 2010 Delphi I suspect )

I started with TurboPascal 1.0 'way back in the day and have been using Delphi 5 since... well, seems like forever. It looks like the latest version of Delphi would be a good product to switch to, but for the cost. My goodness! "In the beginning", the Borland products were priced so that the common man could afford them and make useful stuff. Now... looks like they specifically don't want the "common man" as a customer.

I've looked at Lazarus, but the conversion effort from v5 appears substantial, esp. since I use a lot of 3rd party VCL.

Mr. Ghisler, I'm curious why you are putting effort into a Lazarus TC.

Would you kindly list the benefits you saw that justified the conversion?

2Lefteous
I'm of course searching the forum for information, but so far I didn't have to ask a question. The only thing I wonder right now is how to recompile the system unit. Due to a small parameter problem (WC_NO_BEST_FIT_CHARS doesn't exit in 95), Lazarus programs will not run properly on Windows 95.

I'm curious why you are putting effort into a Lazarus TC.

The only reason why I'm doing this is 64-bit. Lazarus can create 64-bit programs, Delphi can't. It has been announced for many years, but nothing has happened, so I could no longer wait. Already 46% of all new computers are sold with 64-bit Windows, according to Heise.de (German link).

ghisler(Author) wrote: The only reason why I'm doing this is 64-bit. Lazarus can create 64-bit programs, Delphi can't. It has been announced for many years, but nothing has happened, so I could no longer wait. Already 46% of all new computers are sold with 64-bit Windows, according to Heise.de (German link).

One word, or actually number -- 2011

also, I reckon a demo (cmd only) of x64 compiler has been made available already. This should be included in the next 2011.

The good point about delphi is that it supports .NET *alternatives*. So next Delphi will hopefully run (with Mono or whatever that is called) on MacOS as well.

x64 windows has only real point only for home use btw -- more than 4gb of RAM. Me, as a proud owner of 8gb machine for nearly 2 years, certainly appreciates that aspect

Of course, there're some things like Exchange 2007 or related 2008 SBS which force to use x64, but for home use x86 still is more than just enough.

I know that, but it's like with foto cameras - people think that 64bit is better than 32bit just as they think that a 14Megapixel camera makes better fotos than a 10Megapixel, which is unfortunately not true. Actually 64-bit Windows runs 32-bit programs equally well as 64-bit programs. But people aren't thinking rational, so it has to be a 64-bit version.

I reckon a demo (cmd only) of x64 compiler has been made available already.

Unfortunately a command line compiler isn't much worth without a class library.

This should be included in the next 2011.

Well, first it was 2009, then 2010, now 2010. I only believe it when I see it, and maybe I will return to it when it's better then Lazarus.

The good point about delphi is that it supports .NET *alternatives*.

I'm not a fan of .net, sorry.

Isn't it more so about native access to 64bit context menu.dll's and non-rerouted system folder views?

It might also be worthwhile for TC to be able to handle the Win7+ "User Libraries".

Balderstrom wrote:Isn't it more so about native access to 64bit context menu.dll's and non-rerouted system folder views?

However native access to x64 shell menus (and other items btw) will stop direct access to x86 menus

If you run "properties" on file from x86 you get x86 property sheet handlers only, and if you run from x64 you get x64 only. That's how it works I.e. in terms of x64 TC you will have same problem just in reverse

Very few applications actually have a need to serve both x86 and x64. Windows Explorer has two exe to serve that (and you can run them simultaneously with /separate switch). Some programs like I believe TC use a small x64 wrapper in a separate file to get access to x64 stuff. This is a normal way, in fact process explorer from the almighty Russinovich uses pretty much same scheme. If it runs on x64 system it spawns a separate x64 for that.

Still my point stands. x64 OS? By all means! x64 user applications, inclusive of games, video players, codecs etc? no much point really. Video encoding is one of the few real reasons to use x264-x64 for instance, but that is a very marginal use imo.

2ghisler(Author)

What are current issues of 32bit TC on 64bit OS?

What about plugin compatibility?

Do 32bit plugins work correct with 32bit TC on 64bit OS?
Will they work with 64bit TC on 64bit OS?

@VSB: as a rule of thumb, all the current plugins will die on x64 TC

importing functions to a different platform application is impossible by design. I.e. you cannot load x86 dll into x64 application and vice versa. Same goes to COM etc.

So you can only use piping, memory files etc to exchange data between x86 and x64

I guess the same approach would be required as in explorer, power shell, sevenzip, mpc-hc, virtualdub etc etc. Basically all problem solved by providing both x86 and x64 versions of the application (i.e. both are installed if the system is detected as x64).

However, different from Firefox, TC doesnt' really require loads of plugins So I'd switch into x64 quite easily (I just upgraded to x64 W7 btw)

Egh wrote:However, different from Firefox, TC doesnt' really require loads of plugins

Right! And that is why there are only 500 of them

@fenix

I just reinstalled my windoze to x64 W7. TC installed pretty much first thing of course. Since then, several days passed, not a single plugin added.

In fact, I still do implore our beloved developer to consider implementing at least read access to both 7z and ISO containers natively. Long overdue I reckon :hides:

And if, if I'm allowed to fantasize about it, TC finally implements all the NTFS bonanza, well, do we need ANY plugins whatsoever? I'm struggling to name any ))

I have at least a handful or 2 of plugins in use. Though I don't need to "install" them again. My WinCmd.ini references most Paths with an Environment variable. When I reinstall Windows/or TC, the Env Vars are updated on their own (for the most part).

Man, I couldn't live now without the wdx plugins. I don't care about the wcx's that much and could survive without the wfx's for the most part. There are alternative work methods for the wlx's, so I could leave those behind, too...

...but I really depend on the custom columns, esp. DirSizeCalc.

2Egh
80 plugins set and about half of them are used very, very often by me. I could bare without WFX or maybe WCX but using TC without the rest? Impossible!

I plan to call 32-bit plugins via a hidden 32-bit program (tcmdx32.exe), the same way as I currently call 64-bit Explorer extensions from 32-bit TC (x64 submenu in right click menu).

Of course this would be slower than calling it directly, and plugins which try to manipulate the TC window directly will fall on their digital nose. But it would certainly be better than no plugins at all...

@ghisler:

just out of curiousity, how do you communicate now between x86 and x64 ? Do you use messages / memory files only?