Altap Salamander Support Forums

Thanks Jan. Voted as requested.

I've been having a little fish today and it looks like there might be a simple solution available for the short term.

There's a special folder called "sysnative" provides access to the 64 bit system32 folder, even from a 32 bit process. Unfortunately, this folder isn't visible from AS, although it does give an "already exists" error if you try to create it.

To quote:

32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. The Sysnative is just a virtual directory, alias or pseudo-directory that is not visible in Windows Explorer, directory listing, and does not support native 64-bit processes that already been accessing the %windir%\System32 folder. As such, Sysnative can only be used in file system calls, and not in application’s user interface such as dialog box to open or select folder.

Any thoughts?

Similarly, I don't know if this will be of any value?

On x64 systems, ShellExView now always shows the shell extensions for x64 applications, even on the 32-bit version of ShellExView. If you want to get the shell extensions list for 32-bit applications, use ShellExView with /wow64 command-line option.

http://www.nirsoft.net/utils/shexview.html

therube wrote:Similarly, I don't know if ShellExView will be of any value?

ShellExView lists available (32bit and 64bit) shell extensions, but it does not execute them. However, it could be useful for tracking faulty (32bit) shell extensions.

My point (perhaps not made so well) was not to use ShellExView to execute extensions, but that Nir is running into a similar situation as AS.
And so maybe his "solution" may work here too?
(Not that I know anything about this, or even if something like this workable for AS, or even if what I'll say is correct, but) in his case, his "solution" is to use "WoW64" (command line, which obviously wouldn't work here). daern also looks to be thinking along the same lines.


(I was at a MS seminar yesterday <where there wasn't a whole lot of information to be had> but one thing they were reiterating was "API". A manufacturer writes a driver for their device, which communicates with the next higher level. And from that the MS API provides a "unified" view to that device... Doesn't matter if you have a GPU. If not, then <the graphics> will be slower, though same code will work, only it will be performed in software rather then with the GPU's hardware. Bla, bla, bla. <Isn't that like ages old news?>)

WoW64

therube wrote:My point (perhaps not made so well) was not to use ShellExView to execute extensions, but that Nir is running into a similar situation as AS.

I don't think he is. He is not executing the extensions. He is just listing them by reading the registry.

daern wrote:I've been having a little fish today and it looks like there might be a simple solution available for the short term.

There's a special folder called "sysnative" provides access to the 64 bit system32 folder, even from a 32 bit process. Unfortunately, this folder isn't visible from AS, although it does give an "already exists" error if you try to create it.

To quote:

32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. The Sysnative is just a virtual directory, alias or pseudo-directory that is not visible in Windows Explorer, directory listing, and does not support native 64-bit processes that already been accessing the %windir%\System32 folder. As such, Sysnative can only be used in file system calls, and not in application’s user interface such as dialog box to open or select folder.

Any thoughts?

Right, I've done more checking. If I open a 32bit cmd window (from c:\windows\syswow64\cmd.exe), I can manually cd to c:\windows\sysnative. I there I can see the 64bit system files, drivers, native logfiles etc.

If I now use AS to browse to the same folder, I can't. It's not visible and even a manual browse via ctrl-G reports "path specified not found".

Now I want a native x86_64 release as much as anyone, *but* if this was fixed, this would take *loads* of the pressure off for me, as accessing this folder is my primary reason for needing to drop back to Windows Explorer now.

Thoughts?

daern wrote:Right, I've done more checking. If I open a 32bit cmd window (from c:\windows\syswow64\cmd.exe), I can manually cd to c:\windows\sysnative. I there I can see the 64bit system files, drivers, native logfiles etc.

If I now use AS to browse to the same folder, I can't. It's not visible and even a manual browse via ctrl-G reports "path specified not found".

I think Salamander is using some API call to check whether the requested directory exists, but that API doesn't take the existence of Sysnative in regard.

We already have support for %windir%\System32 on our to-do list. We will look into it and let you know.

It would solve another (related) problem: 32-bit Salamander cannot access directories exempted from File System Redirector on x64 Windows.

Certain subdirectories are exempt from redirection. Access to these subdirectories is not redirected to %windir%\SysWOW64:

%windir%\system32\catroot
%windir%\system32\catroot2
%windir%\system32\driversstore
%windir%\system32\drivers\etc
%windir%\system32\logfiles
%windir%\system32\spool

Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP: %windir%\system32\driversstore is redirected.

As a registered user I use Salamader every day for years now. We recently switched to Win64 Ultimate on our main machine to test software and environments for our customers. Although AS runs fine in 64 bit environment, I miss support of certain blocked features (copying to system folders,etc) due to missing UAC support. I also found trouble accessing / copying data from/to folders from inside a virtual PC (MS winXP) to shared drivers in the host system (win64).

Basically all we need is AS is 64 Bit version as soon as possible. Even if some plug-ins would be missing.

Thanks
Markus

markez wrote:I also found trouble accessing / copying data from/to folders from inside a virtual PC (MS winXP) to shared drivers in the host system (win64).

Next version of AS will have better support for accessing local hard drives from Virtual PC machine. With AS 2.52 you can use \\tsclient\c notation, please see another thread: http://forum.altap.cz/viewtopic.php?f=3&t=2781

The version 2.53 beta 1 (release is planned for end of this week) will show following "directories" on 64-bit versions of Vista and Windows 7: C:\Windows\Sysnative, C:\Windows\System32\drivers\etc, C:\Windows\System32\catroot, C:\Windows\System32\catroot2, C:\Windows\System32\DriverStore (only Windows 7), C:\Windows\System32\LogFiles, and C:\Windows\System32\spool. They are displayed with link icon overlay to express they are not real directories.

daern wrote:I thought I'd give this thread a gentle nudge before it gets to its 3rd birthday

We've now migrated virtually every server in our infrastructure to x86_64. About 1/3 of our desktops are now 64bit and the other 2/3 will be rapidly moving away from 32 bit computing. Yet, here we all are, still on a 32 bit file manager...

Any updates at all on this? I love this product, but this is now causing me serious pain and forcing me, for the first time in many, many years, to have to find an alternative for managing certain aspects of our server environment... even (gasp!) Windows Explorer...

Thanks very much for the excellent product.

Daern

What does it matter if you use a 32 bit file manager? You know you won't get more performance out of the 64 bit vers right?

also, I won't use the 64 bit version if WinSCP is not in it. Perhaps it would be possible to have a middle layer that marshalls between 32 bit plugins and 64 bit native portion...

kbirger wrote:

daern wrote:I thought I'd give this thread a gentle nudge before it gets to its 3rd birthday

We've now migrated virtually every server in our infrastructure to x86_64. About 1/3 of our desktops are now 64bit and the other 2/3 will be rapidly moving away from 32 bit computing. Yet, here we all are, still on a 32 bit file manager...

Any updates at all on this? I love this product, but this is now causing me serious pain and forcing me, for the first time in many, many years, to have to find an alternative for managing certain aspects of our server environment... even (gasp!) Windows Explorer...

Thanks very much for the excellent product.

Daern

What does it matter if you use a 32 bit file manager? You know you won't get more performance out of the 64 bit vers right?

also, I won't use the 64 bit version if WinSCP is not in it. Perhaps it would be possible to have a middle layer that marshalls between 32 bit plugins and 64 bit native portion...

Same answer ==> http://forum.altap.cz/viewtopic.php?f=4&t=3866#p20129

I'm running it in x64 right now and have been for over a year. What now? Maybe you could post specific complaints instead of linking uselessly to threads so people can look at your lack of actual information twice.