Re: Detecting Vista x64 (was Problems while creating/running apps for Vista)
> > Rob Kennedy wrote:
>
> >>> and check to see if OS.dwMajorVersion = 5, and OS.MinorVersion is 1
> >>> for XP 32 bit, or 2 for XP 64bit.
> >>
> >> Note that those version numbers are already fetched in global variables
> >> in the SysUtils unit. No need to call GetVersionEx.
>The version of Windows doesn't matter. Delphi calls GetVersionEx and
>stores the numbers (and string) returned by it into global variables. I
>think one has a name like Win32MajorVersion. Find that, and the rest are
>declared nearby.
True, but that's irrelevant for the problem of detecting Vista x64,
since GetVersionEx or its wrapper in SysUtils reports major version 6
minor version 0 for both x32 and x64. There's no problem in detecting
Vista, the problem is detecting Vista x64 reliably.
>Can't the installer set up a compatibility mode when the program is
>installed? Why does the user need to be bothered with it?
The installer I'm using doesn't know about compatibility modes. I
haven't looked into doing this via raw API calls from the dll which I
write for it and which it reads and executes the callbacks.
>And don't you mean virtual memory? A program will never be given a
>physical address anyway, so the physical memory size shouldn't matter to
>any user-mode program.
GlobalMemoryStatus returns information for the system as well as the
process. The dwTotalPhysical may report a number greater than 2GB
even on 32-bit hardware - this is the physical memory installed and
accessible to the OS. The address space for the process is shown in
the dwTotalVirtual field. This will always be 2GB unless {$SetPEFlags
$20) is set, on any hardware and OS.
If SetPEFlags is used and the physical memory is larger than 2GB,
then my D7 programs crash under both 32 and 64 bit Vista and under XP
x32 and x64 due to integer typecasting of pointers in 3rd party code.
On machines with 2GB or less memory, my programs behave normally
regardless of its use on three of the four OS's. I don't have an x64
Vista on a machine with less than 4GB, so I don't know what happens
in that case.
If SetPEFlags is not used, they crash under 64 bit Vista (and 64 bit
XP) on the 4GB physical memory system, but not under 32 bit Vista and
XP on that machine. There may be other reasons for this which I'll
try to locate with the remote debugger.
>And programs can *already* be given addresses that go beyond 2 GB. You can
>see that with programs written for Delphi 3, where programmers used
>LongInt as an equivalent for THandle. Windows NT returns handle values
>that are larger than 2 GB, and when that old code, compiled in newer
>Delphi versions, assigns a THandle value to a LongInt, you can get an
>ERangeError because the now-unsigned THandle value is too big for the
>signed LongInt. So why is being able to detect Windows Vista important for
>working around this problem?
GetVersionEx or its wrapper in SysUtils returns the value major 6 -
minor 0 for Vista. The problem is distinguishing it from x64 Vista
which also returns 6 - 0.
> > I hoped that IsWOW64Process would be helpful. Unfortunately
> > concerning IsWOW64Process, MSDN warns:
> >
> > For compatibility with operating systems that do not support this
> > function, call GetProcAddress to detect whether IsWow64Process is
> > implemented in Kernel32.dll. If GetProcAddress succeeds, it is safe
> > to call this function. Otherwise, WOW64 is not present. Note that
> > this technique is not a reliable way to detect whether the operating
> > system is a 64-bit version of Windows because the Kernel32.dll in
> > current versions of 32-bit Windows also contains this function.
>
>Why is that a problem?
Because IsWOW64Process returning true doesn't guarantee I'm on 64bit
Vista if I understand what MSDN says. If not, please correct me.
For 64 bit XP, GetVersionEx returns major version 5, minor version 2,
instead of 5 and 1 for 32 bit XP or 5 and 0 for Win2000, so there's
no problem in detecting and differentiating x64 XP from x32 XP, as
well as all earlier versions.
>If the function doesn't exist, then you're definitely not on a 64-bit OS.
I already know this if I get 5 or less from earlier versions so
there's no need to test with IsWOW64Process.
>If it does exist, then call it. A value of True means you're a 32-bit
>application running on a 64-bit OS.
I hope so. I'll test this.
>A value of False means you're running on a 32-bit OS or you're a
>64-bit application. And surely the program knows whether it's a
>64-bit program without having to call any external functions.
I don't have any 64 bit Delphi applications yet (sigh!). In the
meantime, with 32 bit Delphi and two otherwise indistinguishable
flavors of Vista, I have a problem.
> > Other alternatives, taken from MSDN x64 driver installation
> > instructions include:
> >
> > 1 Check the value returned by UpdateDriverForPlugAndPlayDevices.
> >
> > If the return value is ERROR_IN_WOW64, the 32-bit application is
> > executing on a 64-bit platform.
> >
> > 2 Call GetSystemWow64Directory.
> >
> > If GetSystemWow64Directory fails and GetLastError returns
> > ERROR_CALL_NOT_IMPLEMENTED, the installer is running on 32-bit Windows.
> >
>
>What's the problem with GetSystemWow64Directory? If it's not present in
>Kernel32, then you're on a pre-Windows XP system and clearly not a 64-bit
>OS.
We know when we are on XP, Win2000 or earlier from GetVersionEx, so
this is not needed.
>If it's present, then call it. If it fails and the error code is
>Error_Call_Not_Implemented, then you're on a 32-bit OS.
Agreed.
>If the call succeeds, or if it fails for any other reason, then
>you're on a 64-bit OS.
Since both success and failure with another error code both point to
a 64bit OS, how reliable is this?
>Calling UpdateDriverForPlugAndPlayDevices doesn't seem wise as a detection
>method, unless your program actually has to update drivers anyway. (That
>is, prefer a detection method that doesn't have system-altering side
>effects.)
Agreed.
I don't understand why MS doesn't distinguish between Vista 32 and
Vista64 in GetVersionEx like it does for XP x32 and x64 since there
is no source for GetVersionEx. Perhaps they just forgot to implement it?
Irwin Scollar
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
