How do I obtain the computer manufacturer’s name from C++?


Some time ago, I gave a scripting solution to the problem of obtaining the computer manufacturer and model. But what if you want to do this from C++?

I could translate the script into C++, or I could just point you to Creating a WMI Application Using C++ in MSDN. In particular, one of the WMI C++ Sample Applications does exactly what you want: Example: Creating a WMI Application. The only things you need to do are

  • change SELECT * FROM Win32_Process to SELECT * FROM Win32_ComputerSystem, and
  • change Name to Manufacturer, and then again to Model.
Comments (14)
  1. Joshua says:

    One of these days you're going to get a followup question that goes "… when WMI services is not running". Not that this particular question is of all that much value so that it would be reasonable to have to worry about it, but I've seen some where it would make sense.

  2. Koro says:

    Why is this stuff not queryable with a regular API?

    [Not sure what make WMI not a "regular API". -Raymond]
  3. @Koro: Define regular API?  If you mean regular SQL using SQL connections, that would be because this isn't meant to be a standard SQL database.  It uses similar querying syntax, but that's just an implementation detail.  If you mean using API functions similar to most of the rest of Win32, it's because this was developed to satisfy the CIM open standard and is similar in design to the CIM Query Language.

    If your question is why not both?  Then the answer probably is, "why both?"

  4. @MNGoldenEagle I suspect because, as Joshua noted, you can stop the WMI service.  There is data in the registry, of course, in the HKEY_LOCAL_MACHINEHARDWAREDESCRIPTIONSystemBIOSSystem* keys.  I wouldn't be at all surprised if that's where WMI got the data from in the first place.  Mind you I wouldn't be surprised if it wasn't either.

  5. Richard says:

    @Koro:

    By "Regular API" do you mean

     msdn.microsoft.com/…/ms724379(v=vs.85).aspx

    and

     msdn.microsoft.com/…/ms724259(v=vs.85).aspx

    Microsoft also has a White Paper on how Windows provides a solution to this post's problem:

    download.microsoft.com/…/SMBIOS.doc

  6. alegr1 says:

    @Koro:

    Because WMI *API* allows you to implement your own providers and classes (such as CPU temperatures, etc) to query, without having to add new functions and interfaces to API. WMI also allows you to query this information from a remote machine.

  7. smf says:

    I imagine that a regular API is one that doesn't require you to pass in ascii, although a completely SQL based operating system (GetMessage, TranslateMessage etc) would be interesting.

    [Not sure what you're after. The WMI interface is all-Unicode. -Raymond]
  8. Joshua says:

    [Not sure what you're after. The WMI interface is all-Unicode. -Raymond]

    Are you being deliberately obtuse?

    [No. But apparently I am inadvertently obtuse. I was responding to the speculation that a "regular API is one that doesn't require you to pass in ascii", and the WMI interface satisfies that criterion. Perhaps your definition of "regular API" is something else? (E.g. "Something easier to use than WMI, where I just call 'GetManufacturerName' and out comes the manufacturer name for the local computer.") -Raymond]
  9. Joshua says:

    While I have a complaint about WMI it's not about the API and not for discussion today.

    smf doesn't like passing in pseudo-SQL.

  10. Joshua says:

    While I have a complaint about WMI it's not about the API and not for discussion today.

    smf doesn't like passing in pseudo-SQL.

    [Okay, that's totally not the read I got at all. smf seemed intrigued by pseudo-SQL ("would be interesting"). -Raymond]
  11. T. West says:

    Have to say that my read of the question was identical to Raymond's.  "Pass in pseudo-SQL commands" would have given me the idea.  "Pass in ASCII" means ASCII vs. Unicode to my mind.

  12. Gabe says:

    Remember, smf is just speculating about what a "regular API" is. And I'm speculating that smf is speculating that it means an API that doesn't involve composing strings.

    Most other APIs use flags or enumerated types to define what data is being queried. Presumably something like FindFirstFile or getaddrinfo are "regular" APIs. Clearly those are a very different style of API than IWbemServices::ExecQuery.

    [Okay, now I see. s/ASCII/strings/. WMI is extensible, which means you need some way to add support for something after the API was written. This rules out flags and enumerations, since there will be no definition for your new thing. You would have to use GUIDs or strings, and strings are much more readable (and scriptable). -Raymond]
  13. ErikF says:

    I recall that MCI used a string-based command language in addition to a binary API (it certainly made testing easy!) So the fact that an API uses human-readable commands is not new, and makes sense in the context of an extensible system that might be scripted. My guess is that the main objection is performance-based, but I have to wonder what program would even notice the performance difference? You'd have to call WMI functions thousands of times a second before it would become an issue!

Comments are closed.