Have you ever seen anything like this:
I'm running TC in Win7.
'c:\Windows\System32\drivers\etc\HOSTS' is my HOSTS file.
My current path is:
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).
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?
No, it's related to this well known issue.MarkFilipak wrote:Is this just another case of Windows 7 magical reality or something more serious?
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.
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.milo1012 wrote:Just try searching 'HOSTS' in: 'c:\Windows\Sysnative\drivers\', and it should work.
Oh, well, at least I now know it's not a virus. Ciao!
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.
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.MarkFilipak wrote:Searching from here: 'c:\Windows\Sysnative\' finds it, but searching from here: 'c:\Windows\' doesn't. I call that magical reality.
Code: Select all
admin> mklink /d C:\Windows\System64 C:\Windows\System32
Instead of complaining about MS you should understand the reasons behind that.MVV wrote: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.
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?
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.
Well, that's your opinion then.MVV wrote:I know their 'reasons' and don't respect them.
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?
If you work on a huge (open source) code base it's sometimes not just a simple S&R.MVV wrote: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.
I've seen a bunch of stuff that'd make you doubt the common sense of some people.
Really?MVV wrote:BTW when they released 32-bit Windows, they've added System32 folder and not used old System one.
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.