From: Bu on
On Sat, 14 Nov 2009 15:17:20 -0500, "mayayana" <mayaXXyana(a)rcXXn.com>
wrote:

> WMI is a tool for system info. and sys. admin.
>management introduced with either Win2000 or
>WinME. (I'm not sure which.) It's not Windows
>API. Earlier systems will not have it unless it's
>been specifically installed.
>
> On NT systems WMI runs as a service. If the
>WMI Process Launcher service has been shut off
>then WMI is not available. (I'm not sure whether
>there might be another service dependency.)
>
> Since WMI is mainly used by system administrators
>via scripting, others could have it shut down for
>security or performance reasons.
>
> So while there's a good chance that you'll be able
>to use WMI on any system where you ship your
>software, it's not certain, and taking that risk is
>unnecessary when you can easily use the Windows
>API instead.
>
> On top of that, WMI is slow, bloated, and really
>provides little of interest other than system info.
>It has Windows Installer functions that are just an
>inferior wrapper around existing WI APIs. It has
>Registry functions that are poorly designed and
>superfluous if you have the Registry API. Etc.
>
Mayayana thanks for the clarification
Bu

>
>> I go for Larry's solution. Just wondering why you can ue it only in
>> your own code.
>> Bu
>>
>

From: Tony Toews [MVP] on
"mayayana" <mayaXXyana(a)rcXXn.com> wrote:

> WMI is a tool for system info.

I've seen WMI before and never quite trusted it. Thanks for your
extensive thoughts.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
From: mayayana on

> > WMI is a tool for system info.
>
> I've seen WMI before and never quite trusted it. Thanks for your
> extensive thoughts.
>

I think it was mainly produced for sys. admins.
I looked into it because I do a lot of scripting.
The SQL-style design provides a lot of ways to
gather information, but it's also a pain in the
neck to deal with the syntax. And when I really
looked into it I just didn't find much of value.

I get the impression that a lot of sys. admins
like it because it's suited for using across a network
on a large number of machines. I've never worked
on a network, so I can't speak to that.

I use it now sometimes for VBScript Registry
access. But I don't understand why MS marketed
it to programmers. I remember a big article about
it in VBPJ when WMI first came out, as though
it were some sort of new Swiss Army knife for VB
programmers. That just didn't make sense to me.
Anyone who has VB, unless they're trying to knock
off a system info. program without writing drivers,
has no use for WMI that I can see.


From: Larry Serflaten on

"mayayana" <mayaXXyana(a)rcXXn.com> wrote

> Anyone who has VB, unless they're trying to knock
> off a system info. program without writing drivers,
> has no use for WMI that I can see.

Except that it gets just about any system info with
a minimal amount of code. Great for one-off quick
access, but for reasons you pointed out, not a good
choice for public use.

LFS


From: Bu on
On Sat, 14 Nov 2009 22:16:44 +0100, Bu <si(a)si.si> wrote:

>On Sat, 14 Nov 2009 15:17:20 -0500, "mayayana" <mayaXXyana(a)rcXXn.com>
>wrote:
>
>> WMI is a tool for system info. and sys. admin.
>>management introduced with either Win2000 or
>>WinME. (I'm not sure which.) It's not Windows
>>API. Earlier systems will not have it unless it's
>>been specifically installed.
>>
>> On NT systems WMI runs as a service. If the
>>WMI Process Launcher service has been shut off
>>then WMI is not available. (I'm not sure whether
>>there might be another service dependency.)
>>
>> Since WMI is mainly used by system administrators
>>via scripting, others could have it shut down for
>>security or performance reasons.
>>
>> So while there's a good chance that you'll be able
>>to use WMI on any system where you ship your
>>software, it's not certain, and taking that risk is
>>unnecessary when you can easily use the Windows
>>API instead.
>>
>> On top of that, WMI is slow, bloated, and really
>>provides little of interest other than system info.
>>It has Windows Installer functions that are just an
>>inferior wrapper around existing WI APIs. It has
>>Registry functions that are poorly designed and
>>superfluous if you have the Registry API. Etc.
>>
>Mayayana thanks for the clarification
>Bu
>
>>
>>> I go for Larry's solution. Just wondering why you can ue it only in
>>> your own code.
>>> Bu
>>>
>>
Allthoug my program will be used in a small group i changed my program
based on Mike's suggestion.
Everybody thanks on your comments
Bu