Windows 7 magical reality or something more serious?

[MarkFilipak]

Hey All,

Have you ever seen anything like this:
I'm running TC in Win7.
Here:
'c:\Windows\System32\drivers\etc\HOSTS' is my HOSTS file.
My current path is:
'c:\Windows\System32\drivers\'.
When I search for 'HOSTS', I get nothing.

When I look at the list window I can see the 'etc' directory, but is has no date and no attributes. If I browse into the 'etc' directory, I can see the 'HOSTS' file (and a search finds it).

To repeat,
from here: 'c:\Windows\System32\drivers\', 'HOSTS' can't be found. But
from here: 'c:\Windows\System32\drivers\etc\', HOSTS can be found.

In fact, from here: 'c:\Windows\System32\drivers\', the 'etc' directory itself can't be found.

Is this just another case of Windows 7 magical reality or something more serious?

[milo1012]

Is this just another case of Windows 7 magical reality or something more serious?

No, it's related to this well known issue.

In short: when using 32-bit TC on x64 OS you will have a 'sysnative' dir in the 'Windows' dir, in order to access native x64 Windows files.
(a 32bit program will see some kind of layer)

Just try searching 'HOSTS' in: 'c:\Windows\Sysnative\drivers\', and it should work.

[MarkFilipak]

Thanks Milo. I see I came to the right place.

Just try searching 'HOSTS' in: 'c:\Windows\Sysnative\drivers\', and it should work.

Searching from here: 'c:\Windows\Sysnative\' finds it, but searching from here: 'c:\Windows\' doesn't. I call that magical reality. I hate it when an operating system has magic directories or magic attributes -- such ugly hacks.

Oh, well, at least I now know it's not a virus. Ciao!

[MVV]

All that redirection is an ugly hack, you're right. C:\Windows\System32 to C:\SysWOW64 redirection, HKLM\Software to HKLM\Software\Wow6432Node redirection (e.g. you can't export REG file in 64-bit Regedit and import in 32-bit one and vice versa), and in 32-bit programs only, these things confuse very much.

C:\Windows\Sysnative is invisible, you can't find it, you only can see files through it, and it is also inacccessible for 64-bit applications. But TC shows it as a real folder for easier access.

I think it would be nice to see them as links.

[Dalai]

Searching from here: 'c:\Windows\Sysnative\' finds it, but searching from here: 'c:\Windows\' doesn't. I call that magical reality.

Yes, this bothered me, too, and some time ago I wanted to open a bug report, although I'm not sure it is a bug. There is a "workaround" for this: mark all files/directories in C:\Windows and TC will search in the redirected directories as well.

Regards
Dalai

[MVV]

There is a simpler workaraund: create junction Sysnative (or System64 as I do) pointing to System32, and TCx32 will be able to search within it and show 64-bit contents of System32 folder (because redirection is not applied to junctions).

Code: Select all

admin> mklink /d C:\Windows\System64 C:\Windows\System32

It is quite logical to have System64 folder with always 64-bit contents (in both 32-bit an 64-bit programs). It's a pity that MS didn't do so in the early beginning and we have System32 folder with 64-bit contents and strangely named SysWOW64 folder with 32-bit contents.

[milo1012]

It is quite logical to have System64 folder with always 64-bit contents (in both 32-bit an 64-bit programs). It's a pity that MS didn't do so in the early beginning and we have System32 folder with 64-bit contents and strangely named SysWOW64 folder with 32-bit contents.

Instead of complaining about MS you should understand the reasons behind that.
In short: there are programs out there who expect to find "their" DLLs in System32,
and so a simple recompile for x64, without changing a single line of code, is enough in most cases.

So it would have required quite a share of code refactoring for some programs if MS had introduced System64.
I'd say it's a good thing in terms of backward compatibility.
How often do you need to do things manually in System32 anyway, even for admin tasks?

[MVV]

I know their 'reasons' and don't respect them.

Since code must be recompiled anyway, it is not a problem to find and replace System32 with System64 in files, or add a macro that will be expanded to one or another depending on build mode. It is stupid to introduce such a huge mess (redirection system, logic error etc) just because someone is too lazy to do mass replace in order to support completely new architecture.

BTW when they released 32-bit Windows, they've added System32 folder and not used old System one.

[milo1012]

I know their 'reasons' and don't respect them.

Well, that's your opinion then.
I wouldn't rant about it on a public forum.
There are other things about the WinAPI that bother me too, but I learned to live with them.
To repeat myself: how often do you REALLY need to do things in System32?

Since code must be recompiled anyway, it is not a problem to find and replace System32 with System64 in files, or add a macro that will be expanded to one or another depending on build mode.

If you work on a huge (open source) code base it's sometimes not just a simple S&R.
I've seen a bunch of stuff that'd make you doubt the common sense of some people.

BTW when they released 32-bit Windows, they've added System32 folder and not used old System one.

Really?
I'd say the main reason is that the so-called "Win64" API is nothing else than a recompiled Win32 API, with some some legacy stuff removed.
That's why we have LLP64 instead of LP64 (Unix), and things are still called kernel32.dll et. al.