Discussion:
How do I start/stop a system service
(too old to reply)
GS
2012-03-09 19:36:29 UTC
Permalink
My apps rely on WMI for gathering hardware info. How would I start WMI
if not running, then stop it when I'm done using it?
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
MikeD
2012-03-09 20:45:47 UTC
Permalink
My apps rely on WMI for gathering hardware info. How would I start WMI if
not running, then stop it when I'm done using it?
The simplest way I can think of would be to use "net start" from the command
line. You can run cmd.exe with the /c parameter followed by the net start
command. For example (syntax may not be exactly right):

cmd.exe /c net start "Windows Management Instrumentation"

Similarly, to stop the service, use "net stop".

Mike
GS
2012-03-09 22:38:43 UTC
Permalink
Post by MikeD
My apps rely on WMI for gathering hardware info. How would I start WMI if
not running, then stop it when I'm done using it?
The simplest way I can think of would be to use "net start" from the command
line. You can run cmd.exe with the /c parameter followed by the net start
cmd.exe /c net start "Windows Management Instrumentation"
Similarly, to stop the service, use "net stop".
Mike
Thanks, Mike. I assume you mean to do this via Shell or ShellExecute? I
was thinking there'd be API[s] involved but if it's that simple...
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
MikeD
2012-03-10 12:27:19 UTC
Permalink
Post by GS
Post by MikeD
Post by GS
My apps rely on WMI for gathering hardware info. How would I start WMI
if not running, then stop it when I'm done using it?
The simplest way I can think of would be to use "net start" from the
command line. You can run cmd.exe with the /c parameter followed by the
cmd.exe /c net start "Windows Management Instrumentation"
Similarly, to stop the service, use "net stop".
Mike
Thanks, Mike. I assume you mean to do this via Shell or ShellExecute? I
was thinking there'd be API[s] involved but if it's that simple...
--
Yes. Use Shell.

There are API calls you can make (as per Jeff's reply), but I think this is
simpler. The only caveat, if you want to even call it that, is that a
command prompt window will open and close, but you could hide that.

And Farnsworth made the excellent point that I neglected to, which is that
the user must have permissions to start and stop services.

Mike
GS
2012-03-10 18:16:29 UTC
Permalink
Post by MikeD
Post by MikeD
My apps rely on WMI for gathering hardware info. How would I start WMI if
not running, then stop it when I'm done using it?
The simplest way I can think of would be to use "net start" from the
command line. You can run cmd.exe with the /c parameter followed by the
cmd.exe /c net start "Windows Management Instrumentation"
Similarly, to stop the service, use "net stop".
Mike
Thanks, Mike. I assume you mean to do this via Shell or ShellExecute? I was
thinking there'd be API[s] involved but if it's that simple...
--
Yes. Use Shell.
There are API calls you can make (as per Jeff's reply), but I think this is
simpler. The only caveat, if you want to even call it that, is that a command
prompt window will open and close, but you could hide that.
I assume I can do this via cmd line switches? I have no idea how but
I'd be happy to research any ref docs you can point me to. Of course, a
code example is always an appreciated alternative.
Post by MikeD
And Farnsworth made the excellent point that I neglected to, which is that
the user must have permissions to start and stop services.
Yeah, that's a good point. I agree with Mayayana that it will only be
stopped if corporate Group Policy or Active Directory has disabled it.
I make it perfectly clear (up front) that it must be fully functional
for my app to work properly, and so I don't anticipate ever needing to
start it anyway. That doesn't exclude, however, personal machines where
it has inadvertently been stopped/paused by some process. It's this
scenario that I want to be able to mitigate...
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
MikeD
2012-03-10 22:57:36 UTC
Permalink
This post might be inappropriate. Click to display it.
GS
2012-03-11 02:08:40 UTC
Permalink
Post by MikeD
Post by MikeD
Post by GS
Post by MikeD
Post by GS
My apps rely on WMI for gathering hardware info. How would I start WMI
if not running, then stop it when I'm done using it?
The simplest way I can think of would be to use "net start" from the
command line. You can run cmd.exe with the /c parameter followed by the
cmd.exe /c net start "Windows Management Instrumentation"
Similarly, to stop the service, use "net stop".
Mike
Thanks, Mike. I assume you mean to do this via Shell or ShellExecute? I
was thinking there'd be API[s] involved but if it's that simple...
--
Yes. Use Shell.
There are API calls you can make (as per Jeff's reply), but I think this
is simpler. The only caveat, if you want to even call it that, is that a
command prompt window will open and close, but you could hide that.
I assume I can do this via cmd line switches? I have no idea how but I'd be
happy to research any ref docs you can point me to. Of course, a code
example is always an appreciated alternative.
If you simply use VB's Shell function, you should be able to specify the
Shell "cmd.exe /c net start ""Windows Management Instrumentation""", vbHide
Shell "cmd.exe /c net stop ""Windows Management Instrumentation""", vbHide
Make SURE you specify the /c parameter. It's important. If you're not
familiar with cmd.exe parameters, type "cmd /?" from a command prompt window.
Thanks, I appreciate your efforts...
Post by MikeD
I need to qualify "works". Apparently at least on Windows 7, there could be
services running that are dependent on WMI. So, if you try to stop WMI and
any of these dependent services are running, you're informed of these other
services and prompted to continue (need to type Y or N). If the window is
hidden, there's no way to respond to this prompt. That shouldn't have any
affect on what you're doing because you'll only be stopping WMI if you had to
start it, so those dependent services shouldn't be running. But I just wanted
to mention this. On ANY version of Windows, either MS or 3rd party services
could be installed that are dependent on WMI, and you'd run into the same
problem.
Not likely to encounter this scenario, but glad you mentioned this
important detail.
Post by MikeD
Post by MikeD
And Farnsworth made the excellent point that I neglected to, which is that
the user must have permissions to start and stop services.
Yeah, that's a good point. I agree with Mayayana that it will only be
stopped if corporate Group Policy or Active Directory has disabled it. I
make it perfectly clear (up front) that it must be fully functional for my
app to work properly, and so I don't anticipate ever needing to start it
anyway. That doesn't exclude, however, personal machines where it has
inadvertently been stopped/paused by some process. It's this scenario that
I want to be able to mitigate...
Here's my opinion on the whole thing though. I don't really agree with what
you're doing. I don't think any program has any business starting/stopping
services or doing certain other things behind the scenes (i.e. without the
user's knowledge or consent). OK. You say you make it perfectly clear that
WMI has to be running. That's making a couple of assumptions. First is that
the user actually READ that. Now I don't know where you have it documented,
but users are notorious for not fully reading documentation.
I display a notification at runtime about any missing dependencies, so
it's always fresh info. The app won't run otherwise, and so it puts it
on the end user to make sure WMI is running OR don't use my app!
Post by MikeD
And even if they
did read it at one time, they could forget. Second assumption is that WMI is
not disabled for whatever reason (which you mentioned). It boils down to
this: don't make your program dependent on things that you can't necessarily
control. Now I don't know what hardware information you're trying to get, but
I'd bet there's other ways besides using WMI to get it. Maybe there are API
functions or perhaps you can even just get it from the Registry.
If this was doable I'd probably go that route, though access to the
necessary keys may be restricted.
Post by MikeD
I just think what you're doing is not really "clean" and could be considered
a little bit devious. I'm not saying there are bad or ill intentions behind
what you're doing. If *I* were evaluating your program, I might very well
choose not to use it.
I'm just collecting machine-applicable hardware info for locking a
license to a specific machine. It may also be a USB thumbdrive if the
users ellects to create a 'portable' version for use on any machine
running Windows. I don't mind if users elect to not use my apps<g>!
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
MikeD
2012-03-11 03:57:12 UTC
Permalink
Gonna cut out a lot of the previous quotes because it's getting a tad
lengthy.
Post by GS
I display a notification at runtime about any missing dependencies, so
it's always fresh info. The app won't run otherwise, and so it puts it on
the end user to make sure WMI is running OR don't use my app!
Well that's not really a good approach IMO. It's kind of arrogant, actually.
What you're really kind of saying is "I'm gonna collect information specific
to your computer and if you don't like, you can't use my program."

And really? Your app is not going to run if WMI isn't available? That's
just not right.
Post by GS
And even if they did read it at one time, they could forget. Second
assumption is that WMI is not disabled for whatever reason (which you
mentioned). It boils down to this: don't make your program dependent on
things that you can't necessarily control. Now I don't know what hardware
information you're trying to get, but I'd bet there's other ways besides
using WMI to get it. Maybe there are API functions or perhaps you can
even just get it from the Registry.
If this was doable I'd probably go that route, though access to the
necessary keys may be restricted.
Almost everything in the Registry is readable. It's write permissions that
are restricted.
Post by GS
I just think what you're doing is not really "clean" and could be
considered a little bit devious. I'm not saying there are bad or ill
intentions behind what you're doing. If *I* were evaluating your program,
I might very well choose not to use it.
I'm just collecting machine-applicable hardware info for locking a license
to a specific machine. It may also be a USB thumbdrive if the users
ellects to create a 'portable' version for use on any machine running
Windows. I don't mind if users elect to not use my apps<g>!
To me, that's the wrong attitude. I take it your apps are shareware or
something along the same lines? I used to be in that so I'm familiar with
trying to protect your software. And that's fine. It's something that,
sadly, you have to do. I don't think you're going about it the right way,
though. I thought you were wanting to get hardware information for
troubleshooting purposes and had users' consent to collect such information,
not for copy protection. There are better ways to protect your software.

Mike
GS
2012-03-11 04:58:27 UTC
Permalink
Post by MikeD
Gonna cut out a lot of the previous quotes because it's getting a tad
lengthy.
I display a notification at runtime about any missing dependencies, so it's
always fresh info. The app won't run otherwise, and so it puts it on the
end user to make sure WMI is running OR don't use my app!
Well that's not really a good approach IMO. It's kind of arrogant, actually.
What you're really kind of saying is "I'm gonna collect information specific
to your computer and if you don't like, you can't use my program."
And really? Your app is not going to run if WMI isn't available? That's just
not right.
And even if they did read it at one time, they could forget. Second
assumption is that WMI is not disabled for whatever reason (which you
mentioned). It boils down to this: don't make your program dependent on
things that you can't necessarily control. Now I don't know what hardware
information you're trying to get, but I'd bet there's other ways besides
using WMI to get it. Maybe there are API functions or perhaps you can even
just get it from the Registry.
If this was doable I'd probably go that route, though access to the
necessary keys may be restricted.
Almost everything in the Registry is readable. It's write permissions that
are restricted.
I just think what you're doing is not really "clean" and could be
considered a little bit devious. I'm not saying there are bad or ill
intentions behind what you're doing. If *I* were evaluating your program,
I might very well choose not to use it.
I'm just collecting machine-applicable hardware info for locking a license
to a specific machine. It may also be a USB thumbdrive if the users ellects
to create a 'portable' version for use on any machine running Windows. I
don't mind if users elect to not use my apps<g>!
To me, that's the wrong attitude. I take it your apps are shareware or
something along the same lines? I used to be in that so I'm familiar with
trying to protect your software. And that's fine. It's something that, sadly,
you have to do. I don't think you're going about it the right way, though. I
thought you were wanting to get hardware information for troubleshooting
purposes and had users' consent to collect such information, not for copy
protection. There are better ways to protect your software.
Mike
Ok, Mike. I appreciate your opinion and I use this service at the
user's consent. As I stated previously, WMI is rarely not running and
so my attitude about using/requiring it is insignificant since I'm
primarily looking for a way to restart the service if it was
inadvertently stopped (not deliberately disabled), OR in cases of
deliberately disabled a way to 'temporarily' use it with the user's
permission to do so.

WMI is all I know to use for this. I'm all ears if you can show me
other ways to get the following info:

PC make, model, bios serial#

USB drive make, model, PNPDeviceID

All drive info for local/unc volumes
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Jason Keats
2012-03-11 09:22:18 UTC
Permalink
WMI is all I know to use for this. I'm all ears if you can show me other
PC make, model, bios serial#
USB drive make, model, PNPDeviceID
All drive info for local/unc volumes
You mean this sort of information...?

http://www.karenware.com/powertools/ptprofiler.asp

http://www.karenware.com/powertools/ptdinfo.asp

You can thank Karen, not me.

HTH
GS
2012-03-11 19:54:48 UTC
Permalink
Post by Jason Keats
WMI is all I know to use for this. I'm all ears if you can show me other
PC make, model, bios serial#
USB drive make, model, PNPDeviceID
All drive info for local/unc volumes
You mean this sort of information...?
http://www.karenware.com/powertools/ptprofiler.asp
http://www.karenware.com/powertools/ptdinfo.asp
You can thank Karen, not me.
HTH
Jason,
*Very impressive* project! There's a couple of reasons it won't work
for me...

1. Requires Karen's written permission to use/distribute in my apps.
No big deal but no guarantee she'll allow this.

2. It shows my USB drives as 'Fixed' type, not 'Removeable' type.

3. Doesn't retrieve serial number info for CPU/BIOS. Maybe because
it can't enum that info directly from the hardware component.

4. Doesn't retrieve PNPDeviceID/SerialNumber for USB drives.
Maybe because it doesn't recognize removeable drives, and/or
can't enum the info directly from the USB device.

5. This is the clincher: It requires way more coding than I want
to put into my projects! (Karen's EXE is already 2x larger than
my largest app; over 10x larger than my addin frontloaders)
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Jason Keats
2012-03-12 04:19:16 UTC
Permalink
Post by GS
Post by Jason Keats
WMI is all I know to use for this. I'm all ears if you can show me other
PC make, model, bios serial#
USB drive make, model, PNPDeviceID
All drive info for local/unc volumes
You mean this sort of information...?
http://www.karenware.com/powertools/ptprofiler.asp
http://www.karenware.com/powertools/ptdinfo.asp
You can thank Karen, not me.
HTH
Jason,
*Very impressive* project! There's a couple of reasons it won't work for
me...
1. Requires Karen's written permission to use/distribute in my apps.
No big deal but no guarantee she'll allow this.
2. It shows my USB drives as 'Fixed' type, not 'Removeable' type.
3. Doesn't retrieve serial number info for CPU/BIOS. Maybe because
it can't enum that info directly from the hardware component.
4. Doesn't retrieve PNPDeviceID/SerialNumber for USB drives.
Maybe because it doesn't recognize removeable drives, and/or
can't enum the info directly from the USB device.
5. This is the clincher: It requires way more coding than I want
to put into my projects! (Karen's EXE is already 2x larger than
my largest app; over 10x larger than my addin frontloaders)
I provided a link to non-WMI *source code* that will get most of the
information you want because you said "WMI is all I know".

I only agree with point #3, above - so use a MACAddress (or something
else) instead.
GS
2012-03-12 05:14:10 UTC
Permalink
Post by Jason Keats
Post by GS
Post by Jason Keats
WMI is all I know to use for this. I'm all ears if you can show me other
PC make, model, bios serial#
USB drive make, model, PNPDeviceID
All drive info for local/unc volumes
You mean this sort of information...?
http://www.karenware.com/powertools/ptprofiler.asp
http://www.karenware.com/powertools/ptdinfo.asp
You can thank Karen, not me.
HTH
Jason,
*Very impressive* project! There's a couple of reasons it won't work for
me...
1. Requires Karen's written permission to use/distribute in my apps.
No big deal but no guarantee she'll allow this.
2. It shows my USB drives as 'Fixed' type, not 'Removeable' type.
3. Doesn't retrieve serial number info for CPU/BIOS. Maybe because
it can't enum that info directly from the hardware component.
4. Doesn't retrieve PNPDeviceID/SerialNumber for USB drives.
Maybe because it doesn't recognize removeable drives, and/or
can't enum the info directly from the USB device.
5. This is the clincher: It requires way more coding than I want
to put into my projects! (Karen's EXE is already 2x larger than
my largest app; over 10x larger than my addin frontloaders)
I provided a link to non-WMI *source code* that will get most of the
information you want because you said "WMI is all I know".
I only agree with point #3, above - so use a MACAddress (or something else)
instead.
I appreciated your contribution.., enough that I thoroughly checked it
out. Thanks for your efforts...

MacAddresses can be changed, and so doesn't meet my criteria.

As for it getting *most* of the info I want, I didn't see very much of
that info everywhere else I looked. Also, I don't have any problems
using WMI. It's just that everyone else was suggesting there's other
ways to get the info but nothing suggested thus far provides it.<g>

Mayayana maybe be on to something worth pursuing!
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Mike Williams
2012-03-11 09:20:00 UTC
Permalink
Post by MikeD
Well that's not really a good approach IMO. It's kind of arrogant,
actually. What you're really kind of saying is "I'm gonna collect
information specific to your computer and if you don't like, you
can't use my program."
Micro$oft have been getting away with that for years ;-)

Mike
MikeD
2012-03-11 23:11:59 UTC
Permalink
Post by Mike Williams
Post by MikeD
Well that's not really a good approach IMO. It's kind of arrogant,
actually. What you're really kind of saying is "I'm gonna collect
information specific to your computer and if you don't like, you
can't use my program."
Micro$oft have been getting away with that for years ;-)
I KNEW somebody would come back with that. <g>

But, it still doesn't mean it's right. Look at everybody the complained
about MS collecting hardware information for activation of their products.
Yeah, they're still doing it, but I think they've scaled back on it a bit.
And no offense to Gary, but with his apps, we're not talking about a billion
dollar company and software that's an operating system or an office suite. I
think the "rules" are just a little bit different.
--
Mike
Mike Williams
2012-03-11 09:13:12 UTC
Permalink
Post by GS
I display a notification at runtime about any missing dependencies,
so it's always fresh info. The app won't run otherwise, and so it
puts it on the end user to make sure WMI is running OR don't
use my app!
I think you'll find that many of them will choose the latter.

Mike
GS
2012-03-11 20:19:33 UTC
Permalink
Post by Mike Williams
Post by GS
I display a notification at runtime about any missing dependencies,
so it's always fresh info. The app won't run otherwise, and so it
puts it on the end user to make sure WMI is running OR don't
use my app!
I think you'll find that many of them will choose the latter.
Mike
You're probably correct, though it hasn't happened yet! Unfortunately,
my app chooses for them when its dependencies are missing or not
available at startup. Users are cordially notified about the reasons
for startup failure and are given suggestions to rectify things and try
again, along with an option to solicit user support about the
issue/incident.

The usual deterent about using my licensed apps is they're not free.
Otherwise, users can test drive them (with full functionality) for 30
days.

Since it's rare that WMI is NOT running, I'm just trying to accomodate
a solution that kicks in when/if the situation warrants. There's
absolutely nothing wrong with using WMI for my purposes; -That's why
it's there! When you right-click on My Computer and select 'Manage' the
Computer Management dialog opens. Expanding 'Services and Application'
and clicking on 'Services' brings up the list. Clicking on 'Windows
Management Instrumentation' displays the following description...

"Provides a common interface and object model to access management
information about operating system, devices, applications and
services. *If this service is stopped, most Windows-based software
will not function properly. If this service is disabled, any
services that explicitly depend on it will fail to start."
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
MikeD
2012-03-11 23:23:43 UTC
Permalink
Post by GS
The usual deterent about using my licensed apps is they're not free.
Otherwise, users can test drive them (with full functionality) for 30
days.
Since it's rare that WMI is NOT running, I'm just trying to accomodate a
solution that kicks in when/if the situation warrants. There's absolutely
nothing wrong with using WMI for my purposes; -That's why it's there! When
you right-click on My Computer and select 'Manage' the Computer Management
dialog opens. Expanding 'Services and Application' and clicking on
'Services' brings up the list. Clicking on 'Windows Management
Instrumentation' displays the following description...
"Provides a common interface and object model to access management
information about operating system, devices, applications and
services. *If this service is stopped, most Windows-based software
will not function properly. If this service is disabled, any
services that explicitly depend on it will fail to start."
I think you're missing that point that I'm trying to make and that I think
Mike Williams is too.

There's no issue with using WMI *if* it's available. The problem is that
you're basically FORCING people to have WMI available in order to use your
app. If you're only using this for licensing of your app, then I think it's
in your best interest to come up with a better licensing scheme. It's one
thing to use WMI to obtain hardware and software information in order to
troubleshoot a problem. It's entirely different to make WMI a required
dependency for licensing purposes when there's other ways you can protect
your software.

Mike
Mayayana
2012-03-12 01:54:43 UTC
Permalink
| Since it's rare that WMI is NOT running, I'm just trying to accomodate
| a solution that kicks in when/if the situation warrants. There's
| absolutely nothing wrong with using WMI for my purposes;

That made me wonder something: WMI is always there,
from 2000 on, I think. But the service isn't always running.
Most of WMI is superfluous bloat wrappers around things like
msi.dll (Windows Installer) and Registry functions. It's
designed for IT people who are not able to write software.
The notable exception to that is the hardware info. As I
understand it, WMI *does* add new libraries (drivers?) of
some kind to find the hardware info. It can do things that
the Win32 API does not have available. So.... I wonder if
there might be a way to call into those libraries, bypassing
the WMI interface. If you could do that you could get the
info. you need without needing to mess with services.

I don't know where to start with that. WMI is not set
up to provide that kind of info. It's set up to wrap the
details. But, for instance, the Win32 provider seems to be
in cimwin32.dll. That DLL calls into setupapi.dll for these
functions:

SetupDiDestroyDeviceInfoList
SetupDiEnumDeviceInterfaces
SetupDiGetClassDevsW
SetupDiGetDeviceInterfaceDetailW

Maybe that's a dead end or maybe it's a start to getting
hardware info. through VB without needing the WMI
intermediary.
GS
2012-03-12 02:12:59 UTC
Permalink
Post by Mayayana
Post by GS
Since it's rare that WMI is NOT running, I'm just trying to accomodate
a solution that kicks in when/if the situation warrants. There's
absolutely nothing wrong with using WMI for my purposes;
That made me wonder something: WMI is always there,
from 2000 on, I think. But the service isn't always running.
Most of WMI is superfluous bloat wrappers around things like
msi.dll (Windows Installer) and Registry functions. It's
designed for IT people who are not able to write software.
The notable exception to that is the hardware info. As I
understand it, WMI *does* add new libraries (drivers?) of
some kind to find the hardware info. It can do things that
the Win32 API does not have available. So.... I wonder if
there might be a way to call into those libraries, bypassing
the WMI interface. If you could do that you could get the
info. you need without needing to mess with services.
I don't know where to start with that. WMI is not set
up to provide that kind of info. It's set up to wrap the
details. But, for instance, the Win32 provider seems to be
in cimwin32.dll. That DLL calls into setupapi.dll for these
SetupDiDestroyDeviceInfoList
SetupDiEnumDeviceInterfaces
SetupDiGetClassDevsW
SetupDiGetDeviceInterfaceDetailW
Maybe that's a dead end or maybe it's a start to getting
hardware info. through VB without needing the WMI
intermediary.
That would be ideal! I'm not all that crazy about having to mess with
services, but I would rather it be me than my user since there's a good
chance I'll be able to do it without breaking anything. Most of my
users can't find files outside their 'My Documents' folder let alone
navigate the Computer Management dialog to start/stop a service.

Both Scriptomatic and WMICode Creator are built to use WMI and what..,
they can't run if the service is stopped. Not to mention several
security service and firewall services that will also be restarted when
WMI restarts. An alternative is definitely welcome here...!
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Mayayana
2012-03-12 14:57:36 UTC
Permalink
| An alternative is definitely welcome here...!

Goodie! I look forward to benefitting from the fruits
of your research. :)

I wonder about the whole ID thing, though. Did you
ever establish a definitive criterion? The info. that
Jason was talking about can be had here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\

That might be as specific as you get. Even Microsoft
has a hard time ID-ing a PC. They settle for the same
model of motherboard. There simply isn't any such thing
as a PC. It's a box with a dozen or so parts that companies
like Dell and HP have marketed as stand-alone appliances.
So Microsoft claims to license their software to a fiberglass
plate. (There's a dark, ironic humor there. The American
Supreme Court of the Plutocracy has ruled that corporations
are sentient beings with all the rights and none of the
responsibilities of human beings. Microsoft has designated
a plastic plate as a human being for the purposes of unilaterally
establishing a software contract. Now you have to pay
monopoly prices for a deal made between a concept and
a piece of plastic... But you're merely a human citizen. You
haven't got a legal leg to stand on. :)

As far as what WMI provides...
I don't know about USB IDs, but I don't find anything in
what WMI returns that is really definitive. I have a WMI
script I wrote some time back to get basic system information.
On my own PC, which I built myself, the BIOS serial number
returns "System Serial Number". The motherboard DeviceID
returns "motherboard". There is no serial number for disk drives.
Win32_ComputerSystemProduct Product UUID returns a
GUID, but I have to assume that's nonsense, since I'm
the manufacturer and I never gave the box an ID. Though
it's possible that WMI is generating this number and then
storing it. On the other hand, didn't someone suggest just
generating a GUID at install?
GS
2012-03-12 17:24:02 UTC
Permalink
Post by Mayayana
Post by GS
An alternative is definitely welcome here...!
Goodie! I look forward to benefitting from the fruits
of your research. :)
The result of my rather extensive research over the years I've wrestled
with this issue has been that WMI is the only tool that provides
difinitive info! That doesn't mean I've 'arrived' at the optimum
solution, just that I have one that works really well 'for now'!
Post by Mayayana
I wonder about the whole ID thing, though. Did you
ever establish a definitive criterion? The info. that
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\
Yes, I do have an explicit criteria. The ID thing (BIOS serial#) is
only an issue on the odd 'clone' machine. (a.k.a. home-built)! In this
case I assign a digital ID and create a 256bit hash serial number from
this and bits of other machine info. Not ideal but serves me fine in
those rare cases where it doesn't exist. Possibly, I could use this for
all except USB drives.
Post by Mayayana
As far as what WMI provides...
I don't know about USB IDs, but I don't find anything in
what WMI returns that is really definitive. I have a WMI
script I wrote some time back to get basic system information.
On my own PC, which I built myself, the BIOS serial number
returns "System Serial Number". The motherboard DeviceID
returns "motherboard". There is no serial number for disk drives.
Win32_ComputerSystemProduct Product UUID returns a
GUID, but I have to assume that's nonsense, since I'm
the manufacturer and I never gave the box an ID. Though
it's possible that WMI is generating this number and then
storing it. On the other hand, didn't someone suggest just
generating a GUID at install?
USB device info is a bit tricky because the data comes from 2 separate
tables. The only connection for these tables is a common value (or
values) that have to be compared for exact matches. Otherwise,
everything else comes from a single table. The ones I use currently
are:

Win32_LogicalDisk
Win32_DiskDrive
Win32_LogicalDiskToPartition
Win32_BIOS

I haven't spent much time trolling the respective Registry keys in
Vista/Win7 to see if there's new info not provided in XP. But since WMI
is pretty much an essential service it just doesn't make any sense to
me why someone would turn it off. (Though, that doesn't mean I don't
understand how someone can 'rational-lies' to themselves their reasons
for turning it off!<g>)
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
GS
2012-03-12 17:59:48 UTC
Permalink
Post by Mayayana
On the other hand, didn't someone suggest just
generating a GUID at install?
I already do assign a unique 'SeatID', but this doesn't id the
hardware. It's purpose is to identify which install the license key
belongs to.

<FWIW>
What may not be foremost in everyone's mind is that I do not 'use' the
Registry for storing anything because my apps can be 'portable'.
Therefore, the license is 'locked' to the hardware the app is installed
on. 'Portable' precludes use of removeable media and could be either a
USB external drive or a memstick. The only way this happens is if a
licensed user chooses to exercise the 2nd seat option included with
every license for this purpose. If so, their licensed app generates the
files and license config on the USB device they select. The process
includes registration of the 2nd seat and I send a 'license activator'
to unlock the app for use on that USB device regardless to which
computer the drive is plugged into.
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Henning
2012-03-12 21:46:11 UTC
Permalink
Post by Mayayana
On the other hand, didn't someone suggest just
generating a GUID at install?
I already do assign a unique 'SeatID', but this doesn't id the hardware.
It's purpose is to identify which install the license key belongs to.
<FWIW>
What may not be foremost in everyone's mind is that I do not 'use' the
Registry for storing anything because my apps can be 'portable'.
Therefore, the license is 'locked' to the hardware the app is installed
on. 'Portable' precludes use of removeable media and could be either a USB
external drive or a memstick. The only way this happens is if a licensed
user chooses to exercise the 2nd seat option included with every license
for this purpose. If so, their licensed app generates the files and
license config on the USB device they select. The process includes
registration of the 2nd seat and I send a 'license activator' to unlock
the app for use on that USB device regardless to which computer the drive
is plugged into.
--
Garry
Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Have you ever concidered that you can only protect software for the 'nice'
guys. For the 'bad' guys all your efforts however complicated ends up with a
simple Software Valid, Yes/No.

/Henning
GS
2012-03-12 22:59:03 UTC
Permalink
Post by Henning
Post by Mayayana
On the other hand, didn't someone suggest just
generating a GUID at install?
I already do assign a unique 'SeatID', but this doesn't id the hardware.
It's purpose is to identify which install the license key belongs to.
<FWIW>
What may not be foremost in everyone's mind is that I do not 'use' the
Registry for storing anything because my apps can be 'portable'. Therefore,
the license is 'locked' to the hardware the app is installed on. 'Portable'
precludes use of removeable media and could be either a USB external drive
or a memstick. The only way this happens is if a licensed user chooses to
exercise the 2nd seat option included with every license for this purpose.
If so, their licensed app generates the files and license config on the USB
device they select. The process includes registration of the 2nd seat and I
send a 'license activator' to unlock the app for use on that USB device
regardless to which computer the drive is plugged into.
-- Garry
Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Have you ever concidered that you can only protect software for the 'nice'
guys. For the 'bad' guys all your efforts however complicated ends up with a
simple Software Valid, Yes/No.
/Henning
Yeah, this just keeps honest folk honest! I also have unlicensed
projects and most users really like that, though few will 'donate' to
contribute to the ongoing development.<g>
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Farnsworth
2012-03-09 21:01:33 UTC
Permalink
Post by GS
My apps rely on WMI for gathering hardware info. How would I start WMI
if not running, then stop it when I'm done using it?
One obvious VB6 source site(Vbnet) shows how to call API functions to
accomplish that, but it seems that you didn't search the web or newsgroups.

But forget it. You can't start or stop services if your app is running in
the context of the limited "Users" group, and perhaps unelevated Admins in
Vista+, but you can query if the service is running or not.
GS
2012-03-09 22:36:05 UTC
Permalink
Post by Farnsworth
Post by GS
My apps rely on WMI for gathering hardware info. How would I start WMI
if not running, then stop it when I'm done using it?
One obvious VB6 source site(Vbnet) shows how to call API functions to
accomplish that, but it seems that you didn't search the web or newsgroups.
I did search (Google: -always my first course of action) but only found
stuff relating to a VB6 ActiveX.exe, indicating I should have tried
different keywords.

I don't get your inference to Vbnet being an 'obvious source' for
Classic VB!!!
Post by Farnsworth
But forget it. You can't start or stop services if your app is running in the
context of the limited "Users" group, and perhaps unelevated Admins in
Vista+, but you can query if the service is running or not.
I can query by attempting to use a ref to it. That part isn't an issue.
Though, you do raise a good point about the permissions issue!
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Farnsworth
2012-03-09 23:55:38 UTC
Permalink
Post by GS
I don't get your inference to Vbnet being an 'obvious source' for
Classic VB!!!
It's for classic VB despite the name, which was in use before VB.Net was
created, and perhaps where you got the WMI source code examples:

http://vbnet.mvps.org/

http://vbnet.mvps.org/code/network/enumservices.htm
GS
2012-03-10 02:30:13 UTC
Permalink
Post by Farnsworth
Post by GS
I don't get your inference to Vbnet being an 'obvious source' for
Classic VB!!!
It's for classic VB despite the name, which was in use before VB.Net was
http://vbnet.mvps.org/
http://vbnet.mvps.org/code/network/enumservices.htm
Thanks! I'm going to check these out...

Actually, I got the WMI code from scouring Excel forums for ways to
identify computers for app licensing. To enhance my use of it I got
Scriptomatic and WMICodeCreator to use for resources.

I got started with classic VB as a result of expanding my VBA to
COMAddins. My resource for getting started was F. Balena's "Programming
Visual Basic 6.0". There was mention of a website called "VB2TheMax"
which kinda disappeared into dotnet land. I also spent a lot of time
studying Brad Martinez's examples, and Karl Petersen's stuff.
Otherwise, I owe a lot of gratitude to many folks from these forums who
have contributed greatly to my growth in my quest to become a VB
programmer. I think I'm still a newbie in most respects and so it seems
like my journey is a very long one. Also, I have Lou Gehrig's and so
there's a limited amount of energy to invest each day, but I push
myself onward as best I can. That said, I'm extremely grateful when
people step up to assist my learning by any measure.
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Farnsworth
2012-03-11 16:14:56 UTC
Permalink
Post by GS
Post by Farnsworth
Post by GS
I don't get your inference to Vbnet being an 'obvious source' for
Classic VB!!!
It's for classic VB despite the name, which was in use before VB.Net
http://vbnet.mvps.org/
http://vbnet.mvps.org/code/network/enumservices.htm
Thanks! I'm going to check these out...
Actually, I got the WMI code from scouring Excel forums for ways to
identify computers for app licensing. To enhance my use of it I got
Scriptomatic and WMICodeCreator to use for resources.
I got started with classic VB as a result of expanding my VBA to
COMAddins. My resource for getting started was F. Balena's
"Programming Visual Basic 6.0". There was mention of a website called
"VB2TheMax" which kinda disappeared into dotnet land. I also spent a
lot of time studying Brad Martinez's examples, and Karl Petersen's
stuff. Otherwise, I owe a lot of gratitude to many folks from these
forums who have contributed greatly to my growth in my quest to
become a VB programmer. I think I'm still a newbie in most respects
and so it seems like my journey is a very long one. Also, I have Lou
Gehrig's and so there's a limited amount of energy to invest each
day, but I push myself onward as best I can. That said, I'm extremely
grateful when people step up to assist my learning by any measure.
I have seen some in the newsgroups asking for samples, and where referred to
that site more than once, then come back and ask for more samples, but the
site offered exactly what they wanted. If you click on "Code Library", then
WMI you will see several examples of how to use WMI. It was the site to go
to for WMI and other samples, so I assumed that is where you got it from. I
apologize if you where offended by my first reply.
Jeff Johnson
2012-03-09 22:41:41 UTC
Permalink
This post might be inappropriate. Click to display it.
GS
2012-03-09 23:23:12 UTC
Permalink
Wow! Thanks, Jeff...
I'll definitely spend the time to digest this. Very much appreciated...

Also, thanks for confirming there's not much out there in Googleland.

BTW, I do use a fairly simple naming convention:

Attribute VB_Name = "mSCM_Services"

SaveAs = "SCM_Services.bas"
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Mayayana
2012-03-10 14:24:04 UTC
Permalink
Also note:

WMI requires DCOM Server Process Launcher running.
There's also a WMI Driver Extensions service. DCOM
Server Process Launcher is not listed as a dependency.
I actually don't know the story on that. All I know is
that I usually disable as many services as possible, and
one time I found that when I re-enabled WMI for something
it wouldn't work. By process of elimination I found that
I had to also enable DCOM Server Process Launcher.

WMI can work remotely, but it doesn't need to, and I
wasn't using it that way. But it seems to be set up to
"consider itself hobbled" if it's not prepared to work
remotely. That's the only reason I can think of for it
needing DCOM Server Process Launcher.

It might be better to just show a message if WMI is
not enabled, for the following reasons:

1) WMI seems to be enmeshed with other services.

2) WMI *not* running is likely to be a rare occurence.

3) In any instance where WMI has been disabled it was
probably done deliberately for security reasons, so you
really have no right to re-enable it.
GS
2012-03-10 18:06:32 UTC
Permalink
Post by Mayayana
WMI requires DCOM Server Process Launcher running.
There's also a WMI Driver Extensions service. DCOM
Server Process Launcher is not listed as a dependency.
I actually don't know the story on that. All I know is
that I usually disable as many services as possible, and
one time I found that when I re-enabled WMI for something
it wouldn't work. By process of elimination I found that
I had to also enable DCOM Server Process Launcher.
I saw the 2nd dependency but wasn't aware of the DCOM SPL.
Post by Mayayana
WMI can work remotely, but it doesn't need to, and I
wasn't using it that way. But it seems to be set up to
"consider itself hobbled" if it's not prepared to work
remotely. That's the only reason I can think of for it
needing DCOM Server Process Launcher.
Can you elaborate on how to make it work remotely?
Post by Mayayana
It might be better to just show a message if WMI is
1) WMI seems to be enmeshed with other services.
2) WMI *not* running is likely to be a rare occurence.
3) In any instance where WMI has been disabled it was
probably done deliberately for security reasons, so you
really have no right to re-enable it.
I already give notifications at startup if any dependencies are missing
whether they be files, COM components, or OS Services. Anything I can
do at this point would be done as per users selecting "YES" to a
prompt.

In those rare cases where I might find WMI not running I would only
enable it for my app's runtime, and restore its state at shutsdown. In
most cases I would just use it at startup for license validation, and
so could restore it when that process no longer requires access.

In light of the additional info you provide here I'll have to check the
dependency services as well and include them as required. Would this be
necessary, though, if using WMI remotely?
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Mayayana
2012-03-10 19:11:27 UTC
Permalink
|
| Can you elaborate on how to make it work remotely?
|

I have no experience with networked computers, so I
can't offer any help with that. My impression is that it's
all down to the creation line, but I'm not sure. On my
PC I can use this in VBS:

Set WMI = GetObject("WinMgmts:")

I think one can do the same on a remote PC named
PC2 with this:

Set WMI = GetObject("WinMgmts:\\PC2")

or

Set WMI = GetObject("WinMgmts:\\192.168.1.50")

But I've never tried anything like that. I just know
it from the docs.
GS
2012-03-10 20:25:07 UTC
Permalink
Post by Mayayana
Post by GS
Can you elaborate on how to make it work remotely?
I have no experience with networked computers, so I
can't offer any help with that. My impression is that it's
all down to the creation line, but I'm not sure. On my
Set WMI = GetObject("WinMgmts:")
I think one can do the same on a remote PC named
Set WMI = GetObject("WinMgmts:\\PC2")
or
Set WMI = GetObject("WinMgmts:\\192.168.1.50")
But I've never tried anything like that. I just know
it from the docs.
That's very helpful! I've tried using WMI remotely over my network but
no luck doing so 'as per samples' I found googling. I'll give this
another shot using your suggested syntax. Though, I really have no need
to do this remotely because I only use WMI for license validation to
see if the hardware my app is running 'from' is licensed. In most cases
this will only happen at startup, but users can use their licensed PC
app to create a 'portable' version that is licensed to a specific USB
drive. Still, this is local use only<g>!
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Loading...