full Win 64bit support to come?

[stigmaster]

I bought Total Commander when I ran Windows XP. Now I'm running Windows XP Pro 64 bit and sometimes TC is behaving very strangely....Like when I open the program sometimes I get a strange error message, it amongst others ask if I want to open the program anyway and if i do, the text is being shown in "nonsense" charaters.......Then again, TC works great sometimes as well...

I really hope the developer will make a 64 bit version of this awesome program.....

[icfu]

It makes no sense to compile a 64-Bit version of TC because TC does no tasks that would benefit from that, it would only blow up the file size for nothing. You can find lots of information if you do a forum search for "64-Bit".

Tell your operating system that it's completely ok to start TC, where that is you have to find out yourself or maybe someone else with 64-Bit XP knows the message and where to disable it.
You can upload a screenshot of the error message here, maybe this will help to solve the problem:
http://imageshack.us/

Icfu

[Aquineas]

It won't happen until Borland decides to include 64 Bit capability in Delphi. As of now, they have not indicated when they'd do this. The next release of Delphi will be bug fixes and include integrating C++ Builder into the product.

[ghisler(Author)]

Even if they provided a 64-bit version, it wouldn't make much sense, because all plugins are 32-bit DLLs. They would all stop working, except if the plugin writers would write a 64-bit version too.

[Darth_Vader]

PMFJI, but the most annoying and inconvenient cos of TC doesn't support x64 is a number of such problems like opening 32-bit CMD.EXE when executing some shell scripts intended to run in 64-bit CMD; I'm unable to see the real \System32 directory and work with the 64-bit files located there. I have to use damned Explorer to fix all that, and to make some sorcery like adding "command prompt" to Explorer context menus. Too bad. I've been loyal to TC many years, and now I'm losing all the previlences it used to give me I mean access and control on the files wherever I need, isn't it what a file manager is supposed to do? If it doesn't do that, or just can't run a file or a script as it should be run, what good is such a file manager, at all?

[ghisler(Author)]

That's because Microsoft were so "brilliant" to put the 64bit files in \System32 instead of creating a \System64 directory.

[Darth_Vader]

I perfectly agree, but I'm afraid we have now to deal with what we've got

[lindquist]

I would like to add "no support for 64bit windows shell extensions" to this list.

I guess there is not much to do about this except a native 64 bit build (am I wrong?), but it's a shame tortoise svn will no longer integrate with total commander

[gigaman]

PMFJI, but the most annoying and inconvenient cos of TC doesn't support x64 is a number of such problems like opening 32-bit CMD.EXE when executing some shell scripts intended to run in 64-bit CMD

It wouldn't be a problem for TC to start 64bit CMD.EXE (I mean, it can be easily implemented by the author) - but the question is: how should it know that 64bit CMD.EXE should be opened? In Windows x64, everything is twice... and it's not clear what version to run. If it starts 64bit CMD.EXE for all scripts, some of them suddenly stop working because they actually need 32bit version of CMD.EXE...

I'm unable to see the real \System32 directory and work with the 64-bit files located there.

That can be implemented as well, it's not so hard. If you wish, you can create a hardlink (e.g. called \System64), pointing to the real \System32 folder - and you will be able to see it even in current version of TC.

I would like to add "no support for 64bit windows shell extensions" to this list.

I guess there is not much to do about this except a native 64 bit build (am I wrong?), but it's a shame tortoise svn will no longer integrate with total commander

Similar problem to the first point. It might be possible to show 64bit shell extensions in 32bit TC as well (though it might be a little harder implementation-vise... maybe using some 64bit helpers)... but the question is if you really want it. 64bit Explorer shows 64bit extensions only, 32 bit Explorer (or 32 bit TC) shows 32bit extensions only. So, if an Windows x64-aware application wants to show in both of them, it has to install two versions of its shell extension - 32bit and 64 bit one. So, if TC combined both views... some of the extensions would appear twice.
A native 64bit build of TC doesn't really solve the problem - you'll have the same troubles, only "reversed" (you will see 64bit extensions, but not 32bit ones).

[levicki]

That's because Microsoft were so "brilliant" to put the 64bit files in \System32 instead of creating a \System64 directory.

I agree that it is not too logical but there is a reason behind it. They had SYSTEM32 string hard-coded in too many places to be able to change it without breaking things. For example, all driver INF files put drivers in SYSTEM32\DRIVERS. Registry keys for drivers and system services also reference files in SYSTEM32.

Moreover, they really wanted to push people to recompile the applications. I mean what is the benefit of having 64-bit pointers and integer arithmetic when you still use 32-bit code?

Many incorrectly believe that the code will get exactly two times bigger by porting to x64. That is just a myth. Because compilers get better it can even get smaller. You need less instructions for 64-bit addition and multiplication for example than you needed in 32-bit code.

Anyway, back on topic, I already sent you an email few days ago regarding this.

As I said in that email, solution is here:
http://windowssdk.msdn.microsoft.com/en-us/library/ms688145.aspx

And here:
http://windowssdk.msdn.microsoft.com/en-us/library/ms684139.aspx

So the steps are as follows:

1. Call GetProcAddress() to check whether kernel32.dll exports IsWow64Process()
2. If it doesn't then you are surely not running on 64-bit Windows
3. If it does then call IsWow64Process() (note that you can't assume 64-bit Windows here, you have to call the function)
4. If it returns FALSE or doesn't set variable to TRUE again no 64 bits
5. If it returns TRUE then check .INI setting (say you call it x64DisableRedirection)
6. If x64DisableRedirection=0 do nothing
7. If x64DisableRedirection=1 call Wow64DisableWow64FsRedirection()

That won't take you more than 15 minutes to implement and save all those people using latest hardware and OS a lot of trouble.

Oh, and if you release a new version I urge you to include latest rarext.dll. You are using the old one for quite some time now.
Regards,
Igor

[gigaman]

That's because Microsoft were so "brilliant" to put the 64bit files in \System32 instead of creating a \System64 directory.

I agree that it is not too logical but there is a reason behind it. They had SYSTEM32 string hard-coded in too many places to be able to change it without breaking things. For example, all driver INF files put drivers in SYSTEM32\DRIVERS. Registry keys for drivers and system services also reference files in SYSTEM32.

I'd say it's not the reason - if the path is hardcoded in existing (i.e. 32bit drivers), they wouldn't work anyway.

As I said in that email, solution is here:
http://windowssdk.msdn.microsoft.com/en-us/library/ms688145.aspx

And here:
http://windowssdk.msdn.microsoft.com/en-us/library/ms684139.aspx

So the steps are as follows:

1. Call GetProcAddress() to check whether kernel32.dll exports IsWow64Process()
2. If it doesn't then you are surely not running on 64-bit Windows
3. If it does then call IsWow64Process() (note that you can't assume 64-bit Windows here, you have to call the function)
4. If it returns FALSE or doesn't set variable to TRUE again no 64 bits
5. If it returns TRUE then check .INI setting (say you call it x64DisableRedirection)
6. If x64DisableRedirection=0 do nothing
7. If x64DisableRedirection=1 call Wow64DisableWow64FsRedirection()

That won't take you more than 15 minutes to implement and save all those people using latest hardware and OS a lot of trouble.

15 minutes? You wish - it's not that easy. The thing is that you have to call Wow64DisableWow64FsRedirection() to disable the redirection before any API function that works with files (i.e. which might be affected), and then call it again right afterwards, to re-enable it - otherwise you'll be in big troubles.
So, implementing this feature means changing a lot of places in the source code. But yes, it's doable, and I think it should be done.

However, as I was trying to explain in my previous post - this certainly helps, but doesn't solve all the problems.

[levicki]

I'd say it's not the reason - if the path is hardcoded in existing (i.e. 32bit drivers), they wouldn't work anyway.

It is hard-coded in many ported 32-bit drivers which makes it hard-coded in new 64-bit drivers too. And don't forget registry references and .INF files. And Win PE for OEMs, etc, etc. Good place to find why Microsoft does something in certain way is to read Raymond Chen's blog and perhaps even suggest a future topic if you want. So let's not go off-topic here because if the escalator goes down it is pointless trying to walk upwards wasting energy.

15 minutes? You wish - it's not that easy. The thing is that you have to call Wow64DisableWow64FsRedirection() to disable the redirection before any API function that works with files (i.e. which might be affected), and then call it again right afterwards, to re-enable it - otherwise you'll be in big troubles.

Why would you want to re-enable it anyway?!?
That redirection is only for SYSTEM32 folder anyway. It doesn't affect other file and folder operations.

So, implementing this feature means changing a lot of places in the source code. But yes, it's doable, and I think it should be done.

Actually it doesn't. It is a one time switch. Throw it off once at the program start and thats it. You can then remember that you are running under 64-bit Windows and you can explicitly start 32-bit CMD.EXE or NOTEPAD.EXE from WINDOWS\SYSWOW64 folder if you want.

this certainly helps, but doesn't solve all the problems.

And what would be the other problems?

In the meantime here is how I would handle this:

Code: Select all

typedef BOOL		(WINAPI *IsWow64Process_t)		(HANDLE, PBOOL);

BOOL IsWow64(void)
{
	IsWow64Process_t	IsWow64Process = (IsWow64Process_t)GetProcAddress(GetModuleHandle("kernel32.dll"), "IsWow64Process");
	BOOL			bIsWow64 = FALSE;

	if (IsWow64Process != NULL) {
		IsWow64Process(GetCurrentProcess(), &bIsWow64);
	}

	return bIsWow64;
}

WinMain()
{
	g_x64 = IsWow64();

	if (g_x64 && g_NoRedir) {
		PVOID OldValue;
		Wow64DisableWow64FsRedirection(&OldValue);
	}
	...
	if (g_x64 && g_UseCMD32) {
		path = "%SystemRoot%\SysWow64\cmd.exe";
	} else {
		path = "%SystemRoot%\System32\cmd.exe";
	}
}

[gigaman]

You have to reenable the redirection after the API call - check what MSDN says. If you don't do that, future calls like LoadLibrary() will fail - because you'd be trying to load the imported libraries (possibly the ones futher in the dependency chain) from the wrong (64bit) system folder - which would fail, of course. That's why you have to enable it - the SYSTEM32 folder, which is the "only one" affected, it rather important here

I wrote about the possible problems in the previous post, as I said. Some scripts / batch file may actually require 32 bit CMD - so it's not clear which one to start. Similarly, the explorer extensions are both in 32bit and 64bit version - so if you decide to load one version (64bit for example), you'll miss the others.

[levicki]

You have to reenable the redirection after the API call - check what MSDN says. If you don't do that, future calls like LoadLibrary() will fail - because you'd be trying to load the imported libraries (possibly the ones futher in the dependency chain) from the wrong (64bit) system folder - which would fail, of course. That's why you have to enable it - the SYSTEM32 folder, which is the "only one" affected, it rather important here

Nowhere does it say explicitly that LoadLibrary() API gets borked by this. Where did you read that?
I just wrote a test 32-bit application, turned the redirection off and tried LoadLibrary() on 32-bit DLL and guess what? It worked. Your assumption was incorrect.

[gigaman]

Yes, it doesn't say specifically, but it says that you have to reenable the redirection as soon as you have the file handle.

Anyway, I can assure you that some things really don't work correctly if you leave the redirection on - I've coded a few things about it a few months ago. I don't remember exactly the situation, but there's a reason.