Printable View
I would like my app. to work under various windows OS. : 98SE, 2000. XP, VISTA and now 7.
Depending upon the OS of the host machine, the location of files (especially dependency files) may need to be varied.
Is there a routine whereby a VB program can interrogate the machine for it's OS and return a value which defines it? Given that value, the VB program can then be written so as to adapt to the OS in use, for file location and so forth.
camoore
Wales, UK
VB6 comes with a SysInfo control that can return OS Version information, or you might make API calls yourself to get more detailed information.
However I'm not sure why dependencies might float around based on the OS. For most of them they should be registered as part of installation, and then your programs locate them via the registered class and type information. You would seldom need to know absolute paths in your program.
Even using identical OS versions two machines might have such things in different places, e.g. one might have C: as the system drive and the other D: as system drive.
For most common situations you can avoid OS-related problems by limiting the features you use to ones supported in the oldest OS you must support, using the special folders properly, and using a standard installer package to install your application.
Thank you dilettante. Could you please provide a simple example of code whereby sysinfo returns a value which corresponds to the machine's OS.?
camoore
Wales, UK
For example:
On Vista gives:Code:Private Sub Form_Load()
Print "Windows "; Format$(SysInfo1.OSVersion, "#0.00") & "." & CStr(SysInfo1.OSBuild)
Print Array("Win32s", "Win9x", "WinNT")(SysInfo1.OSPlatform)
End Sub
Code:Windows 6.00.6002
WinNT
See OSVERSIONINFOEX Structure for more details returned by GetVersionEx() calls.
:wave:
Gibra,
Thank you for replying. However your message seems blank apart from the wavy face.
camoore
Wales, UK
I missing he linkQuote:
Originally Posted by camoore
http://vbnet.mvps.org/index.html?cod...winversion.htm
Sorry! :lol:
I use this:
in bas module
Code:Public Declare Function GetVersionExA Lib "kernel32" _
(lpVersionInformation As OSVERSIONINFO) As Integer
Public Type OSVERSIONINFO
dwOSVersionInfoSize As Long
dwMajorVersion As Long
dwMinorVersion As Long
dwBuildNumber As Long
dwPlatformId As Long
szCSDVersion As String * 128
End Type
-----------------------------------------------------------------------------
Public Function GetWindowsVersion() As String
Dim osinfo As OSVERSIONINFO
Dim ret As Integer
Dim ExtendedInfo As String
10 On Error GoTo e
20 osinfo.dwOSVersionInfoSize = 148
30 osinfo.szCSDVersion = space$(128)
40 ret = GetVersionExA(osinfo)
50 If ret = 0 Then
60 GetWindowsVersion = "Unknow"
70 Exit Function
80 End If
90 With osinfo
100 Select Case .dwPlatformId
Case 1
110 Select Case .dwMinorVersion
Case 0
120 GetWindowsVersion = "Windows 95"
130 Case 10
140 GetWindowsVersion = "Windows 98"
150 Case 90
160 GetWindowsVersion = "Windows Millennium"
170 End Select
180 Case 2
190 Select Case .dwMajorVersion
Case 3
200 GetWindowsVersion = "Windows NT 3.51"
210 Case 4
220 GetWindowsVersion = "Windows NT 4.0"
230 Case 5
240 If .dwMinorVersion = 0 Then
250 GetWindowsVersion = "Windows 2000"
260 ElseIf .dwMinorVersion = 1 Then
270 GetWindowsVersion = "Windows XP"
280 Else
290 GetWindowsVersion = "Windows 2003"
300 End If
310 Case 6
Select Case .dwMinorVersion
Case 0
320 GetWindowsVersion = "Windows Vista"
Case 1
GetWindowsVersion = "Windows 7"
End Select
330 Case Else
340 GetWindowsVersion = "Unknow"
350 End Select
360 End Select
370 ExtendedInfo = .szCSDVersion
380 If Mid$(ExtendedInfo, 1, 1) <> Chr(0) Then
390 ExtendedInfo = Left$(ExtendedInfo, InStr(ExtendedInfo, vbNullChar) - 1)
400 GetWindowsVersion = GetWindowsVersion & " - " & ExtendedInfo
410 End If
420 End With
430 Exit Function
e:
ShowError err.Number, err.Description, "Function GetWindowsVersion", Erl 'write to file and display error
End Function
Thank you Gibra, but this link seems to apply to VBnet, not to VB6.
Dilettante, Have tried your code at the form load event. No error is generated, but nothing else seems to happen. Am testing under Win98SE.
camoore
Wales, UK
To use Print on a Form, you'll want to set AutoRedraw = True in the Form properties.
You can just as easily change those to Debug.Print if you want to, or put the results in a Textbox, use MsgBox, whatever.
You are absolutely in error! :DQuote:
Originally Posted by camoore
Gibra, I looked again at your url and apologise. I was put off by the url containing the characters "vbnet". What is proposed there seems very comprehensive, but also long and very complicated.
The code suggested by isnoend07 (thank you) would not compile for me without errors, and hence would not run.
So I have employed the SYSINFO control (as suggested by dilettante) on my form, and this seems to be working for me. This sysinfo control seems to be yet another very useful and powerful aid of which there is little or no mention in all of my VB textbooks (of which I have 7).
At attachment is a simple program which uses the sysinfo control to return, to text boxes, values for OSPLATFORM, OSVERSION and OSBUILD. What I can not seem to find is a comprehensive description of how these relate to the various windows versions. What I have found so far partially agrees with some of the references, but not exactly. My results have been :-
SYSTEM / OSPLATFORM / OSVERSION / OSBUILD
98SE / 4.1 / 1 / 2222
2000profsp4/ 5 / 2 / 2195
XPProfsp3 /5.01 / 2 / 2600
Can anyone please either point me to a comprehensive definition of the values of these sysinfo properties and / or run my program under different OSs (eg. Vista, 7) and post back what values are returned?
Thus far a careful study of all the references I have found, through this thread and elsewhere, seems to show this version definition to be a less than straightforward matter. But as always, the solution to these problems is nothing but very interesting.
Simple program attached as .zip
camoore
Wales, UK
The link to OSVERSIONINFOEX I gave above should take you to a page that lists the correspondence between OSVersion and recent (supported) Windows OSs. OSBuild is only needed to determine what Service Pack level the OS might be at.
Windows 7 is 6.1, Vista is 6.0, some flavors of late XP are 5.2 and others 5.1, Win2K is 5.0, etc. The values corresponding to unsupported Windows versions can be found elsewhere, for example in the October 2001 release of the MSDN Library which is the basic resource for VB6 programming. Windows NT 4.0 is 4.0 and Windows 95 is 4.0 (use OSPlatform to distinguish), Windows 98 is 4.10, Me is 4.90.
In most cases it isn't especially useful to distinguish between the client editions and server editions of Windows or other fine distinctions. Microsoft also suggests:
While that advice seems to contradict itself, the link they provide there takes you to a page where they go into feature detection.Quote:
Remarks
Relying on version information is not the best way to test for a feature. Instead, refer to the documentation for the feature of interest. For more information on common techniques for feature detection, see Operating System Version.
I should also mention again that none of this relates to the location of files as used by different versions of Windows.
To handle this Windows provides ways of locating special folders, generally via shell32.dll which can be used as a COM object or via API calls.
Dilettante : Thank you for the response. The MSDN item to which you provided a url (OSVERSIONINFOEX) does indeed list "version numbers" against OS types, but it does not list the outputs from the SYSINFO control against OS types. It lists the results from the use of GETVERSIONEX, which seems to me to be a somewhat different beast.
Using the SYSINFO control in the simple program I posted above gives, for example, 5.01 as the OSPLATFORM value for WinXP Prof. SP3. Yet under the GETVERSIONEX information XP is 5.1 and 2000 is 5.0. Nowhere can I see a reference to 5.01.
Hence I would be most grateful if anyone would run my little program under XP, Vista or 7 and post back to me the values obtained for OSPLATFORM, OSVERSION and OSBUILD.
Thank you in anticipation.
camoore
Wales, UK
The problem is that majorversion and minorversion are two different values, not a single floating-point value. Version numbers don't work that way.
The SysInfo control attempts to simplify things by returning a combined value as a Single. It does this by dividing minorversion by 100 and adding that to majorversion.
So 5 + (1/100) = 5.01 in the case of 32-bit WinXP.
In the same way Vista gives 6.00, Windows 7 gives 6.01, Win95 gives 4.00, etc.
Thanks for that additional information. But why in the case of win98se do I get from SYSINFO an OSPLATFORM return of 4.1? Should it not be 4.01, and what would win98 (as opposed to 98SE) return?
camoore
Wales, UK
Windows 98 and 98SE are both 4.10. Majorversion = 4, minorversion=10.
4.1 = 4.10, right?
Win98SE was really more like a Service Pack level of Win98, not a new OS version at all.
I think 98SE had buildnumber values starting at 2222 but I cannot confirm this.
Thank you again, dilettante. All understood.
My win98SE returned OSBUILD 2222 to sysinfo.
I have updated my simple program and attach it as a .zip for possible interest of other readers. I will mark the thread as resolved, but would appreciate anyone letting me know the values returned by different operation systems (NT, Xp flavours, Vista, 7 etc.) by PM. or in thread so that I can refine the program code further.
Thanks to all contributors.
camoore
Wales, UK
XP Pro, Version 2002, SP3
Thank you JohnSavage.
Yesterday I made a mistake in that the version of the little program I posted (as .zip) was an earlier stage of writing and not the "latest". The problems with it were that two labels were interposed (OSPlatform and OSVersion) and that one or two of the final detection criteria for the operating system were incorrect (in your case, 5.1 instead of 5.01). I was finding it rather confusing that sysinfo combines the major version number and the minor version number in the manner above kindly described by dilettante. I attach what I hope is the CORRECT program version, which SHOULD identify your OS as "WIN XP" in the bottom box (not "UNKNOWN OS"). Nonetheless your results agree with what I got from my XP machine, which has XP Professional with SP3 and all other current MS updates incorporated. This returned the same values as you got, ie. OSVersion 5.01, OSPlatform2, OSBuild 2600.
Please see the 2/11/09 version attached, and I would appreciate any further comment/results in thread or by PM if judged no longer of general forum interest. The straightforward method developed here has solved the particular problem I was looking at.
camoore
Wales, UK
My very simple code should be easily understood, and it will be apparent how I have gone about "analysing" the OS values returned by sysinfo. (I remain slightly unsure about the OSVersion value for Win ME. The program sets this as 4.09, but from a dilettante post above maybe it should be 4.9. I do not have a ME machine on which to test this).
Yes camoore I've been watching this topic for a few days now. No one has mensioned doing a search as this topic has been asked many times before.
With WinXP you can have Home and Pro version, I differential between these. I don't like the Sysinfo approach I prefer the GetVersionEx API.
Yes there are 2 versions of Win98 the FE has a 1998 build and SE has a 2222 build, you can differential between these as well and Win95 has 3 versions.Quote:
My win98SE returned OSBUILD 2222 to sysinfo.
The http://vbnet.mvps.org/index.html?cod...winversion.htm link works but I find it always says that WinXP is WinNT4 Plus, Win2k Plus, WinXP, WinXP Plus and WinXP Pro. The service pack number can be taken from the szCSDVersion. ;)
Thanks KeithUK. I did start by a search, but could not find a fairly simple solution which would work on my system. Hence the post. Interestingly some of the suggestions also either did not work or seemed to return incorrect values. For example, one dilettante solution for VISTA returned "WIN NT" (see thread.
The isnoend07 solution looked comprehensive, but the code gave me compiling errors and would not run.
What I have now done is to extract from isnoend07's code the analysis logic and apply it to decoding sysinfo returned values. Thank you for confirming dilettante's thought that WIN 98SE started at build 2222.
My latest code is appended as a .zip. Version 3/11/09. It works for me on machines running 98SE, 2000 and XP Prof. I have no other variants, and hence can not test at home further. Thus any results from members able to test it on other systems were requested.
I have found it difficult to find a comprehensive definition of all these Version, Platform and Build numbers. What I have has been pieced together from several sources, with a bit of guesswork sometimes. If you have any further information - about Build Numbers vv. Version for Win 95 or any other system, I would appreciate your letting me know. My code as attached solves all my present problems, but I would like to make it as universal as possible given further information.
Appreciate your response.
camoore
Wales, UK
Windows 7 - error message:
SYSINFO.OCX is not correctly registered: a file is missing or invalid
XP Pro works
Ver 3-11-09 - appears OK:)
Thank you JohnSavage.
I suspect that the problem with the Windows 7 machine may be one of dependency files. Did that Win 7 machine have VB6 installed, or did you make a .exe on your XP machine and try to use that?
My program has these dependencies :
Uses1=MSVBVM60.DLL
Uses2=OLEAUT32.DLL
Uses3=OLEPRO32.DLL
Uses4=ASYCFILT.DLL
Uses5=STDOLE2.TLB
Uses6=COMCAT.DLL
Uses7=SYSINFO.OCX
SYSINFO.OCX is associated with three other files : SYSINFO.dep, SYSINFO.oca and SYSINFO.srg. On my machines these files are found as follows :
Win 98SE C:\Windows\System, Win 2000 C:\WINNT\System32, Win XP C:\Windows\System32.
I am not sure where they "live" on a VISTA or WIN 7 machine. Later today I plan to have a look at one owned by a friend to find out.
I have made no special effort to load these files to any of my machines (98/2000/XP) but they all have VB6 installed and hence the files may have been loaded as part of VB6. Certainly all four SYSINFO files, plus the other 6, are there on each machine.
Above in thread dilettante got a result from SYSINFO on a VISTA machine (but the code declared the system to be NT) but I guess he will have had VB6 loaded and hence will have had these files in his registry already.
Another question : was your WIN 7 32 bit or 64 bit? I am told that WIN 7 comes with either option. If we can make the program work with WIN 7, it will be of interest to see what Version, Platform and Build numbers are returned by SYSINFO in each case.
camoore
Wales, UK
Umm.. you do know that Vista is Windows NT right? It is Windows NT 6.0, just as XP was NT 5.1 and Win2K was NT 5.0.Quote:
For example, one dilettante solution for VISTA returned "WIN NT"
Names like Windows 2000, Windows XP, etc. are just marketing terms. That's why you don't get them back from OS version check requests.
You can't just copy EXEs around and expect them to work. No version of Windows comes with SysInfo.ocx preinstalled, though more recent ones always have some version of the other items in the list above.Quote:
SYSINFO.OCX is not correctly registered: a file is missing or invalid
Dilettante, Thanks for further reply.
I had hoped to obtain a response from SYSINFO which named the installed OS in "everyday" terms eg. Win XP, Vista etc. The various programs I found, and to which contributors kindly pointed me, seem inconsistent in several ways, including the word description of the OS. (It is appreciated that these later OS are variants of NT.). Hence, for my purposes and maybe those of others I decided to try to write my own program.
Thanks for confirming what I suspected was maybe the problem with JohnSavage trying the program on a WIN 7 machine. I have yet to hear back from John however.
If you have any other info. about VERSION/PLATFORM/BUILD numbers for XP, VISTA or 7 flavours it would be appreciated. Also if you could run my program on a WIN 7 machine WITH the dependency files installed, I would like to hear your result.
It remains the case that my initial thread problem is resolved. However, I am very pleased to receive further comment in thread or by PM.,and I will always be happy to send the latest version of my program to anyone who would like it. But as its development is ongoing, I am reluctant to keep posting updates here "blow by blow".
camoore
Wales, UK
I don't have a Win7 RTM handy, but this is a run on Win7 RC which is close. The RTM build might be a later value.
V.V.M.T dilettante. Seems I am getting somewhere, and this points to the problem JohnSavage found with Win 7 being what I suspected - a dependency files issue. If that proves to be the case, it is worthy of note that the SYSINFO control is dependent upon dependency files (sysinfo.ocx and maybe others) which need to be shipped along with an application using it.
Earlier you reported a result with SYSINFO on a VISTA machine. In a spare moment, could you please try my program on that and let me know how it works?
One more thing. Can you see where in VISTA and in 7 the dependency files (such as sysinfo.ocx) get placed? Maybe something like C:\Windows\System32 ? My above post #26 lists where I found them on 98SE, 2000 and XP. All grist to the mill, thanks.
camoore
Wales, UK
camoore
You can Update the zip, no need to upload lots of zips
hope it helps
Thank you 5ms.
This is more grist to the mill. Your result confirms satisfactory operation with XP SP1. The parameters returned seem to be the same as for SP2 and SP3, which is OK for my intended purposes. I believe that SYSINFO does not delve below system build number.Thus, I can not differentiate using SYSINFO between XP SP1/2/3. However the alternate methods suggested above in thread potentially provide that facility if needed.
I.D.C I will post a later version of my program when I have received more input. It is by no means "rocket science". Just a simple way to ascertain the OS of a machine and to be able to use that information within a VB program.
Thanks again,
camoore
Wales, UK
I’m back, sorry for the delay
For the Windows 7 test I just used an .exe as you suspected.
My windows7 is 32bit and VB6 is not installed on this machine.
Which means SYSINFO.OCX is not packaged with Windows 7.
Yes VB6 is on my XP machine which is why your app worked OK
I have attached below the dependencies of your app, as found using the software I use to make distributable packages.
Again if I was using my packaging software SYSINFO.OCX would be registered like this
Code:Source: C:\WINDOWS\system32\SYSINFO.OCX;
DestDir: {sys}; Flags: regserver restartreplace sharedfile;
The items that the SYSINFO.OCX is actually dependent on all either ship as part of Windows or are things that the VB6 runtime also depends on.
The VB6 runtime and its dependencies have shipped with Windows for a long time now (since 98SE or so) though between then and Vista they might be outdated versions that can usually stand updating. Starting with Vista those are protected operating systems components serviced through Windows Update, you can't update (or accidentally downgrade) them without some major gymnastics.
So in the case of your program the only thing you have to deploy is SYSINFO.OCX itself. No version of Windows ships with this library, but everything from 98SE forward should have "good enough" (for this program) versions of the general VB6 dependencies.
A standard install puts this file into System32 on 32-bit Windows. You can see that by opening SYSINFO.DEP in Notepad, which contains instructions for the P&D Wizard that among other things describe where to install the OCX. The rules are entirely different for ClickOnce, Internet Explorer ActiveX control, or reg-free COM deployment of course.
I'm not sure what Great Truth you hope to reveal by any of this though. Checking the OS version is a trivial matter, and for the most part it isn't very useful. Microsoft recommends that you avoid doing this, and instead check for the presence of "features" if your program does any checking at all. This usually involves things like checks for the versions of various system libraries like Shell32.dll, which can be updated over time adding new features.
Determining the marketing name of the current OS is pretty useless. The user already knows, and your programs have nothing to gain by knowing it.
The most common use of OS version info is by installers. They can check to determine whether running on an NT or 9x platform, or can check for a minimum version number. Or they might install different versions of a component library based on the OS version. But a running application generally has no practical use for such information.
There are any number of "program helper" modules in the CodeBank that provide OS version as a minor function.
I normally show username, computer name, operating system, processor, memory and memory available, video driver, screen resolution and colours, hard drive size and free space, language and printer. I shall have to re-think the printer as it works perfectly on Win9x/ME but not on WinNT.
Well this is a stripped down version of my About Form just showing operating system. I haven't tried it on Vista or Win 7 but the code looks for various settings and decides on which operating system with build and service pack.
Don't forget if you are using Sysinfo.ocx thats another ActiveX you have to add to your installation package. This is only used for one piece of info so is it worth it?
See what it shows on your systems? ;)
Thank you John and dilettante.
The problem John found with WIN 7 has been explained.
What do I want this code for? My programs are not generally distributed, but used on a relatively small number of machines under controlled circumstances. Thus it is not necessary to make distributable packages. I can distribute the dependency files separately and the users can load them (eg. using Windows Explorer) into the correct folder. Most programs share the need for just a handful of dependency files. What I wanted to do was add code to the Form Load event whereby the program whizzes round and checks if all its necessary dependency files are present on a given machine, and flag up to the user which are missing (if any). If all are found, the program will simply run and the user will be unaware of the check's having been made.
To do this I need to know the correct PATH to where the file(s) should be. That path varies with the OS. Hence I need to detect the OS. in use. See my post #26 above where the folder PATH is different between 98, 2000 and XP. In 98 they are in the SYSTEM folder and not in SYSTEM32 for example. That is why I asked you where these files get stored in VISTA and WIN 7 machines. From what you say, dilettante, these use the C:\Windows\System32 folder but I would like just to confirm this so that I have the full correct path.
Your assistance has been much appreciated.
camoore
Wales, UK
Keith UK,
On my win98SE machine your program returned "Windows 98 Second Edition Build: 4.10.2222 A" = which I believe is 100% correct.
These numbers may interest you :
WIN 7 ; Platform 2, Major Version 6, Minor Version 1, Build 7100 (win 7 32 bit)
VISTA ; Platform 2, Major Version 6, Minor Version 0, Build 6002 (see post #34 above)
Perhaps you would like to add them to your program?
camoore
Wales, UK
I think you're making things seriously more complicated than they are.
Each Windows installation "knows" where its various special folders are. The Shell "knows" where to find these path locations, and via calls to shell32.dll it provides the actual paths to calling programs.
It is completely impractical to hard-code some list of paths by OS version, since two machines running the exact same version of Windows can have the same special folder in two different paths. If nothing else consider that when the boot drive is D: instead of C: any hard-coded paths will be incorrect.
So in the end I'm not sure why you wouldn't simply make the Shell calls like everyone else does?
Code:Option Explicit
'Reference to Microsoft Shell Controls and Automation.
'
'Listbox List1.
'
Private Sub Form_Load()
'Shell Special Folder examples:
With New Shell32.Shell
List1.AddItem .NameSpace(ssfPROGRAMFILES).Self.Path
List1.AddItem .NameSpace(ssfSYSTEM).Self.Path
List1.AddItem .NameSpace(ssfPROGRAMS).Self.Path
List1.AddItem .NameSpace(ssfPERSONAL).Self.Path
List1.AddItem .NameSpace(ssfMYPICTURES).Self.Path
End With
End Sub
Private Sub Form_Resize()
If WindowState <> vbMinimized Then
List1.Move 0, 0, ScaleWidth, ScaleHeight
End If
End Sub