Irwin Scollar wrote: > Rob Kennedy wrote: >> I assume it also doesn't offer the Vista look under Vista, either, right? > > Vista puts it's own look on some things, not on others.
Sounds like Windows XP. >>> 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. > > D7 was published several years before XP x64 and of course before > Vista x64. I haven't looked to see what SysUtils from D7 shows in > these cases. Does anyone know what Delphi 2007 shows? I'm waiting > for a 64 bit version before I spend any money on it. > > Using GetVersionEx gives better control in my view. 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. Thus, you don't need to declare a record variable and call GetVersionEx yourself. The RTL has already done it for you. All you need to do is look at the numbers. Delphi 7 didn't need to know about Windows Vista to be able to accept the value 6 being stored in an Integer variable. Delphi doesn't make any judgment about what the numbers mean. But neither does GetVersionEx. >>> Unhappily, this technique does not detect the difference between >>> Vista x32 and x64, where both give 6.0 as a result. >> >> Does it have to? You're only looking to know when to delete the manifest >> file. Does the coloring only look wrong on one kind of processor and not >> the other? > > In this immediate case, it doesn't matter, but there are other > reasons for wanting to know if the app is running under Vista x32 or > Vista x64 or one of the compatibility modes. One reason is to warn > users to setup a compatibility mode if there is integer typecasting > of pointers in a third party dll without source code and physical > memory is larger than 2GB. Can't the installer set up a compatibility mode when the program is installed? Why does the user need to be bothered with it? 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. 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? > 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? If the function doesn't exist, then you're definitely not on a 64-bit OS. If it does exist, then call it. A value of True means you're a 32-bit application running on a 64-bit OS. 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. > 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. > > Neither seems to guarantee unique results. Any ideas will be appreciated. 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. 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. If the call succeeds, or if it fails for any other reason, then you're on a 64-bit OS. 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.) -- Rob _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
