Windows 7 magical reality or something more serious?

English support forum

Moderators: sheep, Hacker, Stefan2, white

Post Reply
User avatar
MarkFilipak
Member
Member
Posts: 106
Joined: 2008-09-28, 01:00 UTC
Location: Mansfield, Ohio

Windows 7 magical reality or something more serious?

Post by *MarkFilipak » 2015-06-26, 00:35 UTC

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?
Hi Christian! Delighted customer since 1999. License #37627

User avatar
milo1012
Power Member
Power Member
Posts: 1110
Joined: 2012-02-02, 19:23 UTC

Re: Windows 7 magical reality or something more serious?

Post by *milo1012 » 2015-06-26, 00:57 UTC

MarkFilipak wrote: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.
TC plugins: PCREsearch and RegXtract

User avatar
MarkFilipak
Member
Member
Posts: 106
Joined: 2008-09-28, 01:00 UTC
Location: Mansfield, Ohio

Re: Windows 7 magical reality or something more serious?

Post by *MarkFilipak » 2015-06-26, 04:09 UTC

Thanks Milo. I see I came to the right place.
milo1012 wrote: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!
Hi Christian! Delighted customer since 1999. License #37627

User avatar
MVV
Power Member
Power Member
Posts: 8412
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2015-06-26, 07:10 UTC

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.

User avatar
Dalai
Power Member
Power Member
Posts: 6782
Joined: 2005-01-28, 22:17 UTC
Location: Meiningen (Südthüringen)

Re: Windows 7 magical reality or something more serious?

Post by *Dalai » 2015-06-26, 11:02 UTC

MarkFilipak wrote: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
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64

Plugins: Services2, Startups

User avatar
MVV
Power Member
Power Member
Posts: 8412
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2015-06-26, 20:27 UTC

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.

User avatar
milo1012
Power Member
Power Member
Posts: 1110
Joined: 2012-02-02, 19:23 UTC

Post by *milo1012 » 2015-06-27, 03:16 UTC

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.
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?
TC plugins: PCREsearch and RegXtract

User avatar
MVV
Power Member
Power Member
Posts: 8412
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2015-06-27, 08:22 UTC

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.

User avatar
milo1012
Power Member
Power Member
Posts: 1110
Joined: 2012-02-02, 19:23 UTC

Post by *milo1012 » 2015-06-27, 22:47 UTC

MVV wrote: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?
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.
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.
MVV wrote: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.
TC plugins: PCREsearch and RegXtract

Post Reply