0

I have some free-standing C++ code (i.e. not a Windows program) that needs to identify the version of Windows that is installed on a PC.

I can easily differentiate between the different Windows client releases by kernel version (e.g. GetFileVersionInfo on ntoskrnl.exe), however I'm wondering if there's a reliable way to distinguish between a client and server installation.

A problem arises when using this method to distinguish between Windows Vista SP2 and Windows Server 2008 SP2 (6.0 build 6002 the both of them) and Windows 7 and Windows Server 2008 R2 (6.1 build 7600 for RTM and 6.1 build 7601 for SP2, both). What is a reliable (and preferably as straight forward as possible, avoiding the registry would be great as access to Win32 API is not available) method of identifying client vs server OSes correctly for code running outside the environment?

I suppose I could check for files only present on the server edition (what's a good file guaranteed to be on any server edition install, regardless of configuration?), check the Panther folder (which is safe to delete, so no guarantees there), etc. but I'm sure this is a problem that people have run into before and (hopefully) solved more elegantly?

(Sidenote: this question has been asked on SO before, but the solution (WMI) is inapplicable for out-of-band checking)

Community
  • 1
  • 1
Mahmoud Al-Qudsi
  • 28,357
  • 12
  • 85
  • 125

3 Answers3

0

I'm not entirely sure what you mean about out of band checking, so I'm going to ignore that for the moment.

The normal way would be to call GetVersionEx, and look at the wProductType member of the OSVERSIONINFOEX.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • I did indicate in my post that "out-of-band" means that I'm not *in* Windows and I don't have access to the Windows API. Will look into `wProductType` and see if I can grab it from the PE headers in `ntoskrnl.exe` – Mahmoud Al-Qudsi May 11 '12 at 03:33
  • Do you know where `GetVersionEx` gets `OSVERSIONINFOEX`? I cannot locate any of that in the PE object headers for ntoskrnl.exe: http://pastebin.com/DTADp2EV – Mahmoud Al-Qudsi May 11 '12 at 03:58
  • @MahmoudAl-Qudsi: I'm pretty sure it retrieves data from the registry. There is (or at one time was) a hack to let workstation act more like server (allow more client connections and such) by modifying the registry to it thought it was a copy of server; the binary files themselves at least used to be the same. Don't know if that's true any more though (it became prominent around the NT4/Win2K time frame). – Jerry Coffin May 11 '12 at 04:01
  • If that's what it boils down to, I could manually load and search the registry hive, but I'd much rather not... – Mahmoud Al-Qudsi May 11 '12 at 04:03
  • @MahmoudAl-Qudsi: I sure can't blame you there, but I'm not sure how much else you can really depend on either. – Jerry Coffin May 11 '12 at 04:05
0

A PE image does NOT specify whether the image should work on a client or server. It only specifies the runtime requirements regarding subsystem, dependencies, memory, affinity, etc...

mox
  • 6,084
  • 2
  • 23
  • 35
  • Thanks, but that's not an answer to my question.. did you mean to post this as a comment? – Mahmoud Al-Qudsi May 11 '12 at 07:22
  • Sorry, yes, this is a comment. :-) – mox May 11 '12 at 07:24
  • FYI you can delete and repost it as a comment by clicking the link under your answer. And, btw, the PE header does contain subsystem info, and dependency info can be pulled from the binary. You can see the subsystem info in this link: http://pastebin.com/DTADp2EV – Mahmoud Al-Qudsi May 11 '12 at 07:25
  • My apologies, I misread your post. In that case, the PE image *does* provide version info, which I had originally be banking on to solve my problem, but cannot for the reasons outlined in my post. – Mahmoud Al-Qudsi May 11 '12 at 07:37
  • No problem! :-) The version info provided by PE is only the version of the required OS to run the image but not the type (client vs. server). – mox May 11 '12 at 07:46
0

I ended up searching for a number of binaries in the system32 directory that are generally associated with the Server Edition of Windows. It's not very clean, but in practice it works very well.

Mahmoud Al-Qudsi
  • 28,357
  • 12
  • 85
  • 125