WMI to use or not to use
in [Visual Basic]
|
Prev: MSDN((VB6) won't install
Next: DLL Wrapper (I Think?)
From: Mike B on 3 Jan 2010 22:40 "Alex Clark" <quanta(a)noemail.noemail> wrote in message news:OS0tFjNjKHA.1824(a)TK2MSFTNGP04.phx.gbl... > "Mike B" <mDotByerley(a)VerizonDottieNettie> wrote in message > news:e84G0dIjKHA.1652(a)TK2MSFTNGP05.phx.gbl... >> >> This C++ code purports to get the CPU_ID: > > But AFAIK there is no API in Windows that will return that value - your > example is a pinch of inline ASM in C++. Also, for the distrib-proc app I > was working on, I had to query machines' hardware capabilities from across > the network, and having a single unified API (WMI) on hand to do all of > that was extremely useful. For querying obscure hardware properties, > there are some things the Windows API can do - for everything else, > there's WMI ;-) Thing is, unless MS specifically added some functions in the core of WMI to produce things like CPUID, it is likely there exists undocumented stubs in the OS for these features. > >
From: mayayana on 4 Jan 2010 01:17 > Thing is, unless MS specifically added some functions in the core of WMI to > produce things like CPUID, I suspect they did just that. WMI has a lot of hardware info. functions, many of which are new. (In fact many are generally useless because they're not even implemented with most hardware.) Since those methods (like motherboard ID, for instance, or "system enclosure part number") exist even in the first versions of WMI I suspect that MS probably wrote drivers specifically for WMI.
From: Karl E. Peterson on 8 Jan 2010 17:56 It happens that mayayana formulated : > When Tom referred to "creating websites" it > sounded like he was talking about something > on the level of web design. I think he's talking about actually *creating* websites. <G> That is, defining where on the hard disk it will live, what host headers it will respond to, what users have what rights to it, how it will be indexed and logged, and so on and so on. It's actually a very intriguing suggestion, as I've always done this manually and it can get rather tedious. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Tom Shelton on 8 Jan 2010 18:14 On 2010-01-08, Karl E Peterson <karl(a)exmvps.org> wrote: > It happens that mayayana formulated : >> When Tom referred to "creating websites" it >> sounded like he was talking about something >> on the level of web design. > > I think he's talking about actually *creating* websites. <G> That is, > defining where on the hard disk it will live, what host headers it will > respond to, what users have what rights to it, how it will be indexed > and logged, and so on and so on. It's actually a very intriguing > suggestion, as I've always done this manually and it can get rather > tedious. > You got it. That's exactly what I was refering to. I define all of this in an xml file once and then my deployment tool goes out to each server and makes it so. -- Tom Shelton
From: Tom Shelton on 8 Jan 2010 18:20
On 2010-01-08, Karl E Peterson <karl(a)exmvps.org> wrote: > It happens that mayayana formulated : >> When Tom referred to "creating websites" it >> sounded like he was talking about something >> on the level of web design. > > I think he's talking about actually *creating* websites. <G> That is, > defining where on the hard disk it will live, what host headers it will > respond to, what users have what rights to it, how it will be indexed > and logged, and so on and so on. It's actually a very intriguing > suggestion, as I've always done this manually and it can get rather > tedious. > Just a thought, Karl - I had to do my stuff in C# do to insfrastructure requirements, so, I know it's of know interest to you. But, when I first started toying with the idea, I was goign to do it with PowerShell - accessing wmi stuff is pretty easy in ps. But, I couldn't go installing PS on all of the servers - which because of the way the internal standardized deployment system works, I would have had to. Anyway, there is a good PS project for you :) -- Tom Shelton |