Vim cannot see several *.com files in system directory
Ben Fritz
chcp.com only by copying it from the System32 directory into
$VIMRUNTIME. I think this is NOT a good way to fix the problem. As
soon as Vim 7.4 or 8.0 comes out the workaround will stop working.
Yes, my $PATH contains the system32 directory.
C:\eclim-git\eclim>dir C:\WINDOWS\system32\*.com
Volume in drive C is Local Disk
Volume Serial Number is EA9A-15F2
Directory of C:\WINDOWS\system32
02/18/2007 06:00 AM 9,216 chcp.com
02/18/2007 06:00 AM 12,288 diskcomp.com
02/18/2007 06:00 AM 9,728 diskcopy.com
02/18/2007 06:00 AM 30,720 format.com
02/18/2007 06:00 AM 43,008 mode.com
02/18/2007 06:00 AM 25,088 more.com
02/18/2007 06:00 AM 17,408 tree.com
7 File(s) 147,456 bytes
0 Dir(s) 181,770,612,736 bytes free
C:\eclim-git\eclim>"C:\Program Files (x86)\vim\vim73\vim.exe" -N -u
NONE -i NONE
:r !dir C:\WINDOWS\system32\*.com
Volume in drive C is Local Disk
Volume Serial Number is EA9A-15F2
Directory of C:\WINDOWS\system32
02/18/2007 06:00 AM 29,696 format.com
02/18/2007 06:00 AM 16,384 more.com
2 File(s) 46,080 bytes
0 Dir(s) 181,772,042,240 bytes free
John Beckett
> :r !dir C:\WINDOWS\system32\*.com
>
> Volume in drive C is Local Disk
> Volume Serial Number is EA9A-15F2
>
> Directory of C:\WINDOWS\system32
>
> 02/18/2007 06:00 AM 29,696 format.com
> 02/18/2007 06:00 AM 16,384 more.com
> 2 File(s) 46,080 bytes
> 0 Dir(s) 181,772,042,240 bytes free
I stopped following Windows a few years ago so I do not know
what is going on, but that looks like it's part of the privilege
escalation security procedures in Windows. I suspect that since
gvim.exe is not signed, Windows runs it with some reduced
privilege and a fake view of certain directories (even if the
user is in Administrators).
John
MacDonald, Stuart
> Any ideas here what might be going on? I was able to get Vim to use
> chcp.com only by copying it from the System32 directory into
> $VIMRUNTIME. I think this is NOT a good way to fix the problem. As
> soon as Vim 7.4 or 8.0 comes out the workaround will stop working.
>
> Yes, my $PATH contains the system32 directory.
>
> C:\eclim-git\eclim>dir C:\WINDOWS\system32\*.com
> Volume in drive C is Local Disk
> Volume Serial Number is EA9A-15F2
>
> Directory of C:\WINDOWS\system32
>
> 02/18/2007 06:00 AM 9,216 chcp.com
> 02/18/2007 06:00 AM 12,288 diskcomp.com
> 02/18/2007 06:00 AM 9,728 diskcopy.com
> 02/18/2007 06:00 AM 30,720 format.com
> 02/18/2007 06:00 AM 43,008 mode.com
> 02/18/2007 06:00 AM 25,088 more.com
> 02/18/2007 06:00 AM 17,408 tree.com
> 7 File(s) 147,456 bytes
> 0 Dir(s) 181,770,612,736 bytes free
>
> C:\eclim-git\eclim>"C:\Program Files (x86)\vim\vim73\vim.exe" -N -u
64-bit Windows versions (Win 7) contain a bunch of filesystem
redirections so that 32 bit apps can believe they are on a 32 OS and
be happy, and 64 bit apps get the same treatment. What you are seeing
is almost certainly a result of those redirections, as vim is a 32-bit
app.
I'm not a Windows programmer, but I understand there are special new
windows calls that will give the raw situation if the app really wants
it.
A couple of quick links:
http://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365743(v=vs.85).aspx
...Stu
Ben Fritz
On Feb 15, 8:30 am, "MacDonald, Stuart"
> 64-bit Windows versions (Win 7) contain a bunch of filesystem
> redirections so that 32 bit apps can believe they are on a 32 OS and
> be happy, and 64 bit apps get the same treatment. What you are seeing
> is almost certainly a result of those redirections, as vim is a 32-bit
> app.
>
> I'm not a Windows programmer, but I understand there are special new
> windows calls that will give the raw situation if the app really wants
> it.
>
>
Thanks, that does shed a light on things. I thought something like
that might be going on.
I see the following:
"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. This mechanism is flexible and
easy to use, therefore, it is the recommended mechanism to bypass file
system redirection. Note that 64-bit applications cannot use the
Sysnative alias as it is a virtual directory not a real one.
Windows Server 2003 and Windows XP: The Sysnative alias was added
starting with Windows Vista."
Unfortunately I'm running XP 64-bit, not Vista or 7 just yet.
The pages you link say that "Disabling file system redirection for
longer periods can prevent 32-bit applications from loading system
DLLs, causing the applications to fail." What if we add an option to
64-bit Windows Vim to disable the redirection? It could even
automatically set the $PATH to include the 32-bit directories before
their 64-bit counterparts so that system files continue to load
properly, but anything not found in the 32-bit directories will be
looked for in the 64-bit ones.
And of course all this is *intended* to be transparent to the user :-\
MacDonald, Stuart
>
> The pages you link say that "Disabling file system redirection for
> longer periods can prevent 32-bit applications from loading system
> DLLs, causing the applications to fail." What if we add an option to
> 64-bit Windows Vim to disable the redirection? It could even
> automatically set the $PATH to include the 32-bit directories before
> their 64-bit counterparts so that system files continue to load
> properly, but anything not found in the 32-bit directories will be
> looked for in the 64-bit ones.
I say an option is the correct way; make 32-bit vim operate "normally"
but allow it to see past the redirection if that's needed.
...Stu
Ingo Karkat
From http://www.vim.org/download.php#pc:
> Native 64-bit binaries for MS-Windows can be found at
> http://code.google.com/p/vim-win3264/. The Win32 binaries should run
> too, but the 64 bit version has a few minor advantages (see the web page
> at the link).
I guess avoiding the file system redirection is one of the "few minor
advantages" the text hints at. I've been using the 64-bit version on Windows 7
without problems. To me, this is too little of an issue (and, as this discussion
showed, it's already difficult to actually detect the proper underlying root
cause from the symptoms (blame Microsoft for that)) to warrant a special
implementation and option in 32-bit Vim.
-- regards, ingo
MacDonald, Stuart
> On 16-Feb-2012 16:15, MacDonald, Stuart wrote:
> > I say an option is the correct way; make 32-bit vim operate "normally"
> > but allow it to see past the redirection if that's needed.
>
> From http://www.vim.org/download.php#pc:
>
> > Native 64-bit binaries for MS-Windows can be found at
> > http://code.google.com/p/vim-win3264/. The Win32 binaries should run
> > too, but the 64 bit version has a few minor advantages (see the web
> page
> > at the link).
And at the link you find that there are a few disadvantages too:
- Command-line installer
- Not supported; not well tested.
Also, I prefer to get official vim.org releases.
> I guess avoiding the file system redirection is one of the "few minor
> advantages" the text hints at. I've been using the 64-bit version on
Possibly. It's not clear to me if 64-bit native apps see the whole raw
filesystem on 64-bit Windows, or if they see the 64-bit view of the
filesystem.
> Windows 7
> without problems. To me, this is too little of an issue (and, as this
Vim has many features, and I could say that all the ones I don't use
are too little of an issue to have been implemented. Nevertheless they
were. Ultimately, it's Bram's call. However, 32-bit vim cannot
interact with parts of the Win 64-bit filesystem without this. That
makes it worthwhile all by itself IMHO.
...Stu
Ben Fritz
On Feb 16, 10:33 am, Ingo Karkat <sw...@ingo-karkat.de> wrote:
>
> To me, this is too little of an issue (and, as this discussion
> showed, it's already difficult to actually detect the proper underlying root
> cause from the symptoms (blame Microsoft for that)) to warrant a special
> implementation and option in 32-bit Vim.
>
system()? Or is that too weird, to have a Windows-only argument to a
function? I like this because the MS docs say the redirection should
only be suppressed temporarily, and this would allow that. I don't
like it because a user might want to use :! or :r !{cmd} instead of
system(). But I don't think we normally want users to set the option
and leave it set, unless they also tweak their path to search in the
32-bit directories along with the 64-bit ones.
Actually I don't think it's a big issue on modern Windows systems. I'm
on XP 64-bit. Starting with Windows Vista, supposedly you can use a
special path alias to get to the non-redirected folders. Also, XP 64-
bit is not widely used, and I imagine they've worked out some of the
missing apps in the 32-bit folder with Vista and later. I don't like
"you're out of luck if you don't use 64-bit Vim" but I suppose I can
accept it if it works in Vista and later.
Ingo Karkat
> What if, instead of an option, we add an optional argument to
> system()? Or is that too weird, to have a Windows-only argument to a
> function?
Do we know of any plugins that break because of this, or is this a purely
theoretical case (well, except for the reported chcp.com) so far? All the
"common" ones do exist in both 32 and 64-bit versions (cmd.exe, cscript.exe, ...)
> I like this because the MS docs say the redirection should
> only be suppressed temporarily, and this would allow that. I don't
> like it because a user might want to use :! or :r !{cmd} instead of
> system(). But I don't think we normally want users to set the option
> and leave it set, unless they also tweak their path to search in the
> 32-bit directories along with the 64-bit ones.
Yes, turning off the redirection can cause issues with loading DLLs, as these
are then taken from the wrong directory and have the wrong bitness, so their
loading fails. As Vim is able to do this via libcall(), it is an issue, though
there are probably few to no users of this functionality.
> Actually I don't think it's a big issue on modern Windows systems. I'm
> on XP 64-bit. Starting with Windows Vista, supposedly you can use a
> special path alias to get to the non-redirected folders. Also, XP 64-
> bit is not widely used, and I imagine they've worked out some of the
> missing apps in the 32-bit folder with Vista and later. I don't like
> "you're out of luck if you don't use 64-bit Vim" but I suppose I can
> accept it if it works in Vista and later.
Right, you mean C:\Windows\Sysnative. Microsoft offers a hotfix that backports
this to Windows XP and 2003 (http://support.microsoft.com/kb/942589), but few
will have this installed, and documenting all these hoops is a real hassle.
-- regards, ingo
Ben Fritz
On Feb 17, 2:13 pm, Ingo Karkat <sw...@ingo-karkat.de> wrote:
>
> Right, you mean C:\Windows\Sysnative. Microsoft offers a hotfix that backports
> this to Windows XP and 2003 (http://support.microsoft.com/kb/942589), but few
> will have this installed, and documenting all these hoops is a real hassle.
>
can do this:
" Note, 64-bit Windows doesn't let Vim access the real
system32 folder
" by default, so add an alias to this directory to the path if
one
" exists to allow us to access any important files which might
be
" missing from the SysWOW64 directory.
if isdirectory('C:\Windows\Sysnative')
let $PATH.=';C:\Windows\Sysnative'
endif
MacDonald, Stuart
> > on XP 64-bit. Starting with Windows Vista, supposedly you can use a
> > special path alias to get to the non-redirected folders. Also, XP 64-
> > bit is not widely used, and I imagine they've worked out some of the
> > missing apps in the 32-bit folder with Vista and later. I don't like
> > "you're out of luck if you don't use 64-bit Vim" but I suppose I can
> > accept it if it works in Vista and later.
>
> Right, you mean C:\Windows\Sysnative. Microsoft offers a hotfix that
> backports
> this to Windows XP and 2003 (http://support.microsoft.com/kb/942589), but
> few
> will have this installed, and documenting all these hoops is a real
> hassle.
Speak of the devil. Since this thread I ran across
C:\Windows\System32\gatherNetworkInfo.vbs. Curious, I right-clicked,
"Edit with Vim" and received a blank file with the status line
'"C:\Windows\System32\gatherNetworkInfo.vbs" [New file]'. I can edit
the file by doing
:e C:\Windows\Sysnative\gatherNetworkInfo.vbs
Understandably, the Sysnative part does not auto-complete, but once I
got to the 'g' I could autocomplete the filename.
So there's one real-world case. I really think this needs to be noted
in the help, if nothing else.
...Stu