Getting the OS of the pc.

Listening :-)

I write this example for you:

procedure TForm1.Button1Click(Sender: TObject);
const Plateforms: array [0 .. 2] of string[12] = ('Win 3.1', 'Win 95', 'Win NT');
var
  Info: _OSVERSIONINFO;

begin
  info.dwOSVersionInfoSize:= SizeOf(Info);
  GetVersionEx(Info);
  Memo1.Lines.Add('Plateform: ' + Plateforms[Info.dwPlatformId]);
  Memo1.Lines.Add('Major Version: ' + IntToStr(Info.dwMajorVersion));
  Memo1.Lines.Add('Minor Version: ' + IntToStr(Info.dwMinorVersion));
  Memo1.Lines.Add('Builder number: ' + IntToStr(Info.dwBuildNumber));
  Memo1.Lines.Add('Information : ' + Info.szCSDVersion);
end;

Motaz

hi robert,

what program ,the executable containing getversionex?
thats a strange one ,do you know why ?
Regards Barry

Hi guys...  :-)

Thanx Barry...

Robert, I didn't know that. Could you tell me more about the problem? Is there an official way to come around that? Or do we have to do ugly things again?

Regards, Madshi.

inthe, yes.

Here is the current workaround of the Jedi Code Library.
It seems a compatibility trick of WinME to make older Game CDs install on WinME. Maybe even some older Microsoft CDs fail. AFAIK it is not documented.

function GetWindowsVersion: TWindowsVersion;
begin
  Result := wvUnknown;
  case Win32Platform of
    VER_PLATFORM_WIN32_WINDOWS:
      case Win32MinorVersion of
        0..9:
          if Trim(Win32CSDVersion) = 'B' then
            Result := wvWin95OSR2
          else
            Result := wvWin95;
        10..89:
          // On Windows ME Win32MinorVersion can be 10 (indicating Windows 98
          // under certain circumstances (image name is setup.exe). Checking
          // the kernel version is one way of working around that.
          if KernelVersionHi = $0004005A then // 4.90.x.x
            Result := wvWinME
          else if Trim(Win32CSDVersion) = 'A' then
            Result := wvWin98SE
          else
            Result := wvWin98;
        90:
          Result := wvWinME;
      end;
    VER_PLATFORM_WIN32_NT:
      case Win32MajorVersion of
        3:
          Result := wvWinNT3;
        4:
          Result := wvWinNT4;
        5:
          Result := wvWin2000;
      end;
  end;
end;

Thanx Robert for the hint, I'll add that fix in my stuff. I think I should check winXP again, maybe there's such a thing, too...

thanks also,
or if your function returns win98 then can also doublecheck by reading Productname and versionnumber from registry under SOFTWARE\Microsoft\Windows\CurrentVersion and check if are "MICROSOFT WINDOWS ME" or 4.9 ..
a quick search on google revealed this is causing problems for hundreds of people ,and as rob said it's not documented anywhere officially.

Hmmm... I checked it, Robert is right. If your exe is called "setup.exe", GetVersionEx returns minor 10, which is Windows98SE. It doesn't happen for "install.exe", only for "setup.exe".

But I've found a different solution for the problem, which I like better than to check the kernel version: The build number! This number grows independently from the minor number. E.g. for win95 it is < 1000, for win95osr2 it is > 1000. For win98se it's 2222, for winME it's 3000. And it's the same, regardless whether the exe is called "setup.exe" or not. So my solution looks like this:

case minor of
  00..09 : if      build > 1000 then enum := osWin95osr2
           else                      enum := osWin95;
  10     : if      build > 2700 then enum := osWinME
           else if build > 2000 then enum := osWin98se
           else                      enum := osWin98;
  11..90 : enum := osWinME;
  else     enum := osWin9xNew;
end;

Has someone Windows2000 running? Or even XP? My NT based partitions are all broken in the moment. Could someone check the version info for "setup.exe" in these systems? Would be great...

Regards, Madshi.

P.S: If anyone is interested, here comes the part for detecting XP:

case major of
  0..3 : enum := osWinNtOld;
  4    : enum := osWinNt4;
  5    : case minor of
           0  : enum := osWin2k;
           1  : enum := osWinXP
           else enum := osWinNtNew;
         end;
  else   enum := osWinNtNew;
end;

Interesting, for Microsoft win2000 is NT5 and winXP is only something like NT5.1.

To Madshi:
My Win2000 reports Minor = 0 and Major = 5 for both setup.exe and other name. Is that what you wanted to be checked?

Regards, Geo

Great! Thank you very much, Geo!  :-)  So it seems that winME is the only system with such a "compatibility" mode for "setup.exe". Well, don't know about XP right now, will check that later...

Madshi, can we use your code in the JCL?

how can we differentiate the diff. versions of an operating system? i.e. Win2k Pro Edition, Server Edition, and the upcoming WinXP which will have several editions?

Hi Robert, do you mean only the few "build" and XP lines? Or do you mean my whole OS type & function? Both is okay for me. If you want to use the whole type & function, a one-line comment pointing to my homepage would be nice. If you only want to use the few lines, just copy them without a comment.

Hi DragonSlayer, to be honest: I don't know. I would have to install both editions in order to test that. Don't they only differ by the number of available services? I don't know whether the version info is not exactly the same?

Regards, Madshi.

Madshi,

Umm... I don't know... but I suppose for WinNT they only differ by the tools (or services as you'd put them)... not sure about Win2k and XP.

But what if I want to enable an application to only be run in Win2k Server Ed.? Well, not that I really want to do that... it's just as an example.

Also, there's the 64-bit version of XP...

>> But what if I want to enable an application to only be run in Win2k Server Ed.?

Yeah, no question that it would make sense to know on which edition you run, I just don't know how to solve that in the moment.

I recall that WinNT 4.0 Workstation vs Server was only two registry keys which were monitored by a system thread to prevent changes (not counting the server tools).

The trick to change a worstation to a server was to patch the key names in a kernel copy so that the thread monitored the wrong keys. Then do a restart with the new kernel, change the keys and restart to the original kernel.
The monitoring did not check the keys itself. It only prevented key changes.

I thought it was stored in the registry..
Sorry cant fin specific path at present..

No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:

To split between motaz, inthe, madshi, mnasman and robert_marquardt

Please leave any comments here within the next seven days.
 
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
 
Thank you,
Russell

EE Cleanup Volunteer