Usage of access(*, X_OK) in file.c and Windows Vista.

Hello Ruby-Core,

Looking at file.c:860 (int eaccess function) it is correcting IO
access mode only if _MSC_VER is greater than 1400:

#else
# if _MSC_VER >= 1400
    mode &= 6;
# endif
    return access(path, mode);
#endif

This happens due the usage of X_OK when looking for executable bit on Windows.

Previous version of MSVCRT (6.0) ignored any value that is not defined
in the mode table [1], like X_OK (with value 1). Later version of
MSVCRT (7.1 and 8.0) strictly report failure using unsupported modes,
which makes applications deployed in Windows Vista fail, since Vista
offer a 8.0 version of MSVCRT that cannot be replaced by local
path/folder implementations.

So, users running Ruby build with VC 6 (MSC_VER 1200) will see this
problem when deploying current One-Click under this platform.

On a side effect, MinGW got affected by this behavior too, so they
conditionally define __USE_MINGW_ACCESS prior including <io.h> to
workaround this issue.

I don't know if will be better provide a patch for win32/win32.h prior
inclusion of io.h, like this:

Index: ruby_1_8/win32/win32.h
===================================================================
--- ruby_1_8/win32/win32.h	(revision 16110)
+++ ruby_1_8/win32/win32.h	(working copy)
@@ -69,6 +69,9 @@
 #else
 # include <utime.h>
 #endif
+#if defined(__GNUC__)
+#define __USE_MINGW_ACCESS
+#endif
 #include <io.h>
 #include <malloc.h>

or use something in configure.in that generates something inside
ruby.h, so all the extensions created for ruby that depends on access
functionality will have it for free?

(I think the later will fit better, but just asking).

Thanks in advance for your time,
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams