detect Win 7 
Author Message
 detect Win 7

How can my VB6 program detect which operating system is in use, and if
it's 32 or 64 bit?

Thanks



Sat, 12 May 2012 05:49:51 GMT  
 detect Win 7
Win 7 = NT 6.1


| How can my VB6 program detect which operating system is in use, and if
| it's 32 or 64 bit?
|
| Thanks



Sat, 12 May 2012 05:53:14 GMT  
 detect Win 7

Quote:
> How can my VB6 program detect which operating system is in use, and if
> it's 32 or 64 bit?

See this VB6 sample:

http://vbnet.mvps.org/code/helpers/iswinversion.htm

See GetVersionEx() in MSDN for OS version. However, they removed pre-Windows
2000 information from the online documentation, so see your local copy for
Windows 9x/NT4.



Sat, 12 May 2012 07:11:46 GMT  
 detect Win 7

Quote:


> > How can my VB6 program detect which operating system is in use, and if
> > it's 32 or 64 bit?

> See this VB6 sample:

> http://vbnet.mvps.org/code/helpers/iswinversion.htm

> See GetVersionEx() in MSDN for OS version. However, they removed pre-Windows
> 2000 information from the online documentation, so see your local copy for
> Windows 9x/NT4.

Thanks Nobody,
That's exactly what I was looking for. It's very informative.


Sat, 12 May 2012 07:26:03 GMT  
 detect Win 7


Quote:
> How can my VB6 program detect which operating system is in use, and if
> it's 32 or 64 bit?

To get the Windows' version, you can use the GetVersionEx API function. As
Abhishek said, the major version will be 6 and the minor version will be 1.
One sort-of caveat is that IF your app is running in compatibility mode,
GetVersionEx will report the version of the compatible OS being used.  So,
in other words, if the OS is Win7 BUT your app is running under WinXP
compatibility mode, GetVersionEx is going to report that the Windows version
is 5.1. There's been quite a few debates as to whether this is the way it
should be.  I personally think it is, but I think I'm also in a minority of
people having that opinion.

You have to take a different approach to determine if it's 32 bit or 64 bit
because GetVersionEx won't tell you that. What I would consider a "cheat"
would be to check for the existence of certain system folders that will only
exist in a 64 bit system. For example, the SysWOW64 subfolder of the Windows
folder. Another would be "Program Files (x86)". This latter folder will
exist in the root of the same drive as the Windows folder.  You should NOT
hard-code this to be the C: drive because it may not be the C: drive. As
best as I know, the "proper" way to determine 32 bit or 64 bit is to call
the GetNativeSystemInfo API function. This function is only exported by
WinXP or later, so you should either check for the OS being at least WinXP
OR write an error handler to deal with the possibility of the function not
existing. Here's some example code.

-----BEGIN CODE
Private Type SYSTEM_INFO
  wProcessorArchitecture        As Integer
  wReserved                     As Integer
  dwPageSize                    As Long
  lpMinimumApplicationAddress   As Long
  lpMaximumApplicationAddress   As Long
  dwActiveProcessorMask         As Long
  dwNumberOfProcessors          As Long
  dwProcessorType               As Long
  dwAllocationGranularity       As Long
  wProcessorLevel               As Integer
  wProcessorRevision            As Integer
End Type

Private Type OsVersionInfo
    dwOSVersionInfoSize        As Long
    dwMajorVersion             As Long
    dwMinorVersion             As Long
    dwBuildNumber              As Long
    dwPlatformID               As Long
    szCSDVersion               As String * 128
End Type

Private Const PROCESSOR_ARCHITECTURE_AMD64 As Long = 9      'x64 (AMD or
Intel)
Private Const PROCESSOR_ARCHITECTURE_IA64  As Long = 6      'Intel Itanium
Processor Family (IPF)
Private Const VER_PLATFORM_WIN32_NT = 2

Private Declare Sub GetNativeSystemInfo Lib "kernel32" (lpSystemInfo As
SYSTEM_INFO)
Private Declare Function GetVersionEx Lib "kernel32" Alias "GetVersionExA"
(lpVersionInformation As Any) As Long

Public Function IsOS64Bit() As Boolean

    Dim si      As SYSTEM_INFO

    If IsWinXP Then 'can only call GetNativeSystemInfo under WinXP and later
        Call GetNativeSystemInfo(si)
        If (si.wProcessorArchitecture = PROCESSOR_ARCHITECTURE_AMD64) Or
(si.wProcessorArchitecture = PROCESSOR_ARCHITECTURE_IA64) Then
            IsOS64Bit = True
        Else
            IsOS64Bit = False
        End If
    Else
        IsOS64Bit = False
    End If

End Function

Public Function IsWinXP() As Boolean

    'Returns True if the OS is Windows XP or greater (this includes Vista,
Win7, and Server 2003/2008)

    Dim osvi As OsVersionInfo

    With osvi
        .dwOSVersionInfoSize = Len(osvi)
        GetVersionEx osvi
        IsWinXP = (.dwPlatformID = VER_PLATFORM_WIN32_NT) And _
            (((.dwMajorVersion = 5) And (.dwMinorVersion >= 1)) Or _
            (.dwMajorVersion >= 6))
    End With

End Function
-----END CODE

You should be able to adapt the IsWinXP function above for any other version
of Windows (assuming you know each one's version number). Through various
means, you can find out exactly what edition of Windows your app is running
under.  For example, whether it's WinXP Home or Pro, whether it's Vista Home
or Home Premium or Ultimate, etc., whether it's Windows Server 2003 or
Windows Server 2003 R2, and on and on and on.

Note that any function which returns a boolean for an OS version should
return True if the OS is actually greater than the version you're checking.
Failure to do so will likely cause problems in your app, forcing users to
run your app in compatibility mode when it may not otherwise have to (which
is exactly the reason GetVersionEx reports the version number for the
compatibility mode rather than the "true" OS version...too many programmers
didn't write their code properly when using GetVersion or GetVersionEx).

Also note that it is NOT recommended to check the Windows version number for
specific functionality.  This is because such functionality can sometimes be
added to Windows via updates, optional downloads, etc.

A gotcha to look out for involves WinXP 64 bit and Windows Server 2003.
These both have the same version number, which is 5.2.  Yes, that version
number is right for XP 64 bit.  I know, XP 32 bit's version number is 5.1.
Why XP 64 bit's version number is the same as WinServer 2003, probably only
Microsoft knows.  Unfortunately, you can't differentiate between them by
calling the IsOS64Bit function because WinServer2003 could be 64 bit. You
have to call GetVersionEx using the OSVERSIONINFOEX structure and checking
if wProductType = VER_NT_WORKSTATION when the major version is 5 and the
minor version is 2.

And to reiterate, this all assumes your app is NOT running under
compatibility mode.

 --
Mike



Sat, 12 May 2012 07:55:29 GMT  
 detect Win 7
MikeD wrote :

Quote:
> You have to take a different approach to determine if it's 32 bit or 64 bit
> because GetVersionEx won't tell you that. What I would consider a "cheat"
> would be to check for the existence of certain system folders that will only
> exist in a 64 bit system. For example, the SysWOW64 subfolder of the Windows
> folder. Another would be "Program Files (x86)". This latter folder will exist
> in the root of the same drive as the Windows folder.  You should NOT
> hard-code this to be the C: drive because it may not be the C: drive.

Are they localized, too?

--
[.NET: It's About Trust!]



Sat, 12 May 2012 09:35:03 GMT  
 detect Win 7


Quote:
> MikeD wrote :
>> You have to take a different approach to determine if it's 32 bit or 64 bit because GetVersionEx won't tell you that. What I
>> would consider a "cheat" would be to check for the existence of certain system folders that will only exist in a 64 bit system.
>> For example, the SysWOW64 subfolder of the Windows folder. Another would be "Program Files (x86)". This latter folder will exist
>> in the root of the same drive as the Windows folder.  You should NOT hard-code this to be the C: drive because it may not be the
>> C: drive.

> Are they localized, too?

I don't know for sure, but I'd guess probably.

--
Mike



Sat, 12 May 2012 22:25:59 GMT  
 detect Win 7
Hi Karl,

Karl E. Peterson schrieb:

Quote:
> MikeD wrote :
>> You have to take a different approach to determine if it's 32 bit or
>> 64 bit because GetVersionEx won't tell you that. What I would consider
>> a "cheat" would be to check for the existence of certain system
>> folders that will only exist in a 64 bit system. For example, the
>> SysWOW64 subfolder of the Windows folder. Another would be "Program
>> Files (x86)". This latter folder will exist in the root of the same
>> drive as the Windows folder.  You should NOT hard-code this to be the
>> C: drive because it may not be the C: drive.

> Are they localized, too?

German Windows 7:

Dir in a console reports following folders:

- Program Files
- Program Files (x86)

Windows Explorer shows:

- Programme
- Programme (x86)

Btw, AFAIK under W7 the system is *always* reported to be on drive C, no
matter wether this is the first partition on the drive or not.

--
Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.proSource.de/Downloads/



Sat, 12 May 2012 23:16:01 GMT  
 detect Win 7
Ulrich Korndoerfer used his keyboard to write :

Quote:
> Hi Karl,

> Karl E. Peterson schrieb:
>> MikeD wrote :
>>> You have to take a different approach to determine if it's 32 bit or 64
>>> bit because GetVersionEx won't tell you that. What I would consider a
>>> "cheat" would be to check for the existence of certain system folders that
>>> will only exist in a 64 bit system. For example, the SysWOW64 subfolder of
>>> the Windows folder. Another would be "Program Files (x86)". This latter
>>> folder will exist in the root of the same drive as the Windows folder.  
>>> You should NOT hard-code this to be the C: drive because it may not be the
>>> C: drive.

>> Are they localized, too?

> German Windows 7:

> Dir in a console reports following folders:

> - Program Files
> - Program Files (x86)

> Windows Explorer shows:

> - Programme
> - Programme (x86)

I'll be darned!  I'm seeing lots of stuff like that, there.  Screwy!

Quote:
> Btw, AFAIK under W7 the system is *always* reported to be on drive C, no
> matter wether this is the first partition on the drive or not.

Reported by what?

--
[.NET: It's About Trust!]



Sun, 13 May 2012 07:03:10 GMT  
 detect Win 7
Hi,

sorry for the delay, but somehow I managed to not see your answer until now.

Karl E. Peterson schrieb:

Quote:
> Ulrich Korndoerfer used his keyboard to write :
>> Hi Karl,

>> Karl E. Peterson schrieb:
>>> MikeD wrote :
>>>> You have to take a different approach to determine if it's 32 bit or
>>>> 64 bit because GetVersionEx won't tell you that. What I would
>>>> consider a "cheat" would be to check for the existence of certain
>>>> system folders that will only exist in a 64 bit system. For example,
>>>> the SysWOW64 subfolder of the Windows folder. Another would be
>>>> "Program Files (x86)". This latter folder will exist in the root of
>>>> the same drive as the Windows folder.  You should NOT hard-code this
>>>> to be the C: drive because it may not be the C: drive.

>>> Are they localized, too?

>> German Windows 7:

>> Dir in a console reports following folders:

>> - Program Files
>> - Program Files (x86)

>> Windows Explorer shows:

>> - Programme
>> - Programme (x86)

> I'll be darned!  I'm seeing lots of stuff like that, there.  Screwy!

There are real file system folders (folders, that exist in the file
system), NTFS hard links to file system folders (those are file system
objects too) and mapped folders (those that appear in the explorer under
an other name).

Eg. on a german windows 7:

- "Program Files" is a file system folder (seen by using Dir)
- "Programme" is a hard link to "Program files" (seen by using Dir /AL)

Explorer (when told to not hide system files) shows:

- "Programme" -> the underyling file system folder is "Program Files"
- "Programme" annotated as link -> a link, however explorer does not
show the target folder

If one uses the systems apis to retreive the folder where programs
should be stored in, the path to "Program Files" is returned.

However an application also can use a hardcoded path in traditional
notation. Then both pathes

C:\Program Files
C:\Programme

point to the file system folder "Program Files".

More fun comes with the file system "Users" folder. There are two hard
links:

"Document and Settings" and "Dokumente und Einstellungen" and explorer
shows "Dokumente und Einstellungen" (and alos the links if told so).

So a program that ignores the system apis and uses hardcoded pathes
could access the "Users" folder by using either

"C:\Document and Settings"
"C:\Dokumente und Einstellungen"
"C:\Users"

In earlier versions of windows (at least till XP) the file system folder
for the users settings and documents had a localized name, so on a
german windows its name would have been "Dokumente und Einstellungen",
and on an english system its name would have been "Documents and
Settings". Applications using hardcoded pathes then would have had
problems when they did not take into account localization.

Under Windows 7 they can use for hardcoded pathes the new name "Users"
or he old name either in the english or localized naming. This is what I
assume MS would call "progress" :-)

Quote:
>> Btw, AFAIK under W7 the system is *always* reported to be on drive C,
>> no matter wether this is the first partition on the drive or not.

> Reported by what?

Sorry, report is the wrong word, map is better. Under W7 the system
partition is always mapped to drive letter C. Earlier versions (till
Vista) could have a system partition mapped eg to the drive letter E.
AFAIK this is no more possible under W7.

--
Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.proSource.de/Downloads/



Thu, 17 May 2012 08:46:53 GMT  
 detect Win 7


| There are real file system folders (folders, that exist in the file
| system), NTFS hard links to file system folders (those are file system
| objects too) and mapped folders (those that appear in the explorer under
| an other name).
|
| Eg. on a german windows 7:
|
| - "Program Files" is a file system folder (seen by using Dir)
| - "Programme" is a hard link to "Program files" (seen by using Dir /AL)
|
| Explorer (when told to not hide system files) shows:
|
| - "Programme" -> the underyling file system folder is "Program Files"
| - "Programme" annotated as link -> a link, however explorer does not
| show the target folder
|
| If one uses the systems apis to retreive the folder where programs
| should be stored in, the path to "Program Files" is returned.
|
| However an application also can use a hardcoded path in traditional
| notation. Then both pathes
|
| C:\Program Files
| C:\Programme
|
| point to the file system folder "Program Files".
|
| More fun comes with the file system "Users" folder. There are two hard
| links:
|
| "Document and Settings" and "Dokumente und Einstellungen" and explorer
| shows "Dokumente und Einstellungen" (and alos the links if told so).
|
| So a program that ignores the system apis and uses hardcoded pathes
| could access the "Users" folder by using either
|
| "C:\Document and Settings"
| "C:\Dokumente und Einstellungen"
| "C:\Users"
|
| In earlier versions of windows (at least till XP) the file system folder
| for the users settings and documents had a localized name, so on a
| german windows its name would have been "Dokumente und Einstellungen",
| and on an english system its name would have been "Documents and
| Settings". Applications using hardcoded pathes then would have had
| problems when they did not take into account localization.
|
| Under Windows 7 they can use for hardcoded pathes the new name "Users"
| or he old name either in the english or localized naming. This is what I
| assume MS would call "progress" :-)
|
| >> Btw, AFAIK under W7 the system is *always* reported to be on drive C,
| >> no matter wether this is the first partition on the drive or not.
| >
| > Reported by what?
| >
|
| Sorry, report is the wrong word, map is better. Under W7 the system
| partition is always mapped to drive letter C. Earlier versions (till
| Vista) could have a system partition mapped eg to the drive letter E.
| AFAIK this is no more possible under W7.

Additional (and possibly relevent) information on hard links, courtesy
Raymond Chen:

http://blogs.msdn.com/oldnewthing/archive/2009/09/28/9900082.aspx



Thu, 17 May 2012 09:29:42 GMT  
 detect Win 7
Quick and dirty.

Private Declare Function GetBinaryType Lib "kernel32.dll" Alias
"GetBinaryTypeA" (ByVal lpApplicationName As String, ByRef lpBinaryType As
Long) As Long

Private Sub Command1_Click()

    Dim fs As New FileSystemObject
    Dim temp As String
    Dim index As Long

    temp = fs.GetSpecialFolder(0) & "\explorer.exe"

    If  fs.FileExists(temp) Then

        GetBinaryType temp, index

        Select Case index
            Case 0: temp = "32 Bit"
            Case 1: temp = "DOS"
            Case 2: temp = "16 Bit Windows"
            Case 3: temp = "PIF Binary"
            Case 4: temp = "POSIX"
            Case 5: temp = "16 Bit OS/2"
            Case 6: temp = "64 Bit"
        End Select

     Debug.Print "Binary Type   " & temp

End Sub


Quote:
> Hi,

> sorry for the delay, but somehow I managed to not see your answer until
> now.

> Karl E. Peterson schrieb:

>> Ulrich Korndoerfer used his keyboard to write :
>>> Hi Karl,

>>> Karl E. Peterson schrieb:
>>>> MikeD wrote :
>>>>> You have to take a different approach to determine if it's 32 bit or
>>>>> 64 bit because GetVersionEx won't tell you that. What I would consider
>>>>> a "cheat" would be to check for the existence of certain system
>>>>> folders that will only exist in a 64 bit system. For example, the
>>>>> SysWOW64 subfolder of the Windows folder. Another would be "Program
>>>>> Files (x86)". This latter folder will exist in the root of the same
>>>>> drive as the Windows folder.  You should NOT hard-code this to be the
>>>>> C: drive because it may not be the C: drive.

>>>> Are they localized, too?

>>> German Windows 7:

>>> Dir in a console reports following folders:

>>> - Program Files
>>> - Program Files (x86)

>>> Windows Explorer shows:

>>> - Programme
>>> - Programme (x86)

>> I'll be darned!  I'm seeing lots of stuff like that, there.  Screwy!

> There are real file system folders (folders, that exist in the file
> system), NTFS hard links to file system folders (those are file system
> objects too) and mapped folders (those that appear in the explorer under
> an other name).

> Eg. on a german windows 7:

> - "Program Files" is a file system folder (seen by using Dir)
> - "Programme" is a hard link to "Program files" (seen by using Dir /AL)

> Explorer (when told to not hide system files) shows:

> - "Programme" -> the underyling file system folder is "Program Files"
> - "Programme" annotated as link -> a link, however explorer does not show
> the target folder

> If one uses the systems apis to retreive the folder where programs should
> be stored in, the path to "Program Files" is returned.

> However an application also can use a hardcoded path in traditional
> notation. Then both pathes

> C:\Program Files
> C:\Programme

> point to the file system folder "Program Files".

> More fun comes with the file system "Users" folder. There are two hard
> links:

> "Document and Settings" and "Dokumente und Einstellungen" and explorer
> shows "Dokumente und Einstellungen" (and alos the links if told so).

> So a program that ignores the system apis and uses hardcoded pathes could
> access the "Users" folder by using either

> "C:\Document and Settings"
> "C:\Dokumente und Einstellungen"
> "C:\Users"

> In earlier versions of windows (at least till XP) the file system folder
> for the users settings and documents had a localized name, so on a german
> windows its name would have been "Dokumente und Einstellungen", and on an
> english system its name would have been "Documents and Settings".
> Applications using hardcoded pathes then would have had problems when they
> did not take into account localization.

> Under Windows 7 they can use for hardcoded pathes the new name "Users" or
> he old name either in the english or localized naming. This is what I
> assume MS would call "progress" :-)

>>> Btw, AFAIK under W7 the system is *always* reported to be on drive C, no
>>> matter wether this is the first partition on the drive or not.

>> Reported by what?

> Sorry, report is the wrong word, map is better. Under W7 the system
> partition is always mapped to drive letter C. Earlier versions (till
> Vista) could have a system partition mapped eg to the drive letter E.
> AFAIK this is no more possible under W7.

> --
> Ulrich Korndoerfer

> VB tips, helpers, solutions -> http://www.proSource.de/Downloads/



Thu, 17 May 2012 11:30:43 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. VB detect win resolution.

2. QuickBasic program won't detect directories under NT

3. VB4 RDO Won't detect an error in an SQL Server 6.0 stored procedure

4. Detecting Novell Logonid in Win NT

5. Best way to detect TCP/IP on Win 3.11

6. HELP!!! detecting/installing DUN for win 95

7. detecting/installing win 95 dun

8. Comms Port and detecting RLSD/DCD- VB4.00 n Win'95

9. Detecting if Win App opened???

10. How to detect Pentium in WIN 3.1????

11. Detect Message on WIN API

12. How to detect TCP/IP on Win 3.11?

 

 
Powered by phpBB® Forum Software