Mail Archives: cygwin/2001/11/29/17:45:50
On Sun, 25 Nov 2001 01:10:14 GMT, swamp-dog AT ntlworld DOT com (Guy Harrison)
wrote:
Hi again folks (he says after a week - sorry about that),
I have some questions at the end.
>I've a need for this myself - so I'm writing one (C++). Here's its
>"usage"...
>
>Usage: cygqrysrv
>--machine machine-name
>--database database-name
>--access-level GENERIC_ [ READ WRITE EXEC ]
> SC_MANAGER_
> [
> ALL_ACCESS
> CONNECT
> CREATE_SERVICE
> ENUMERATE_SERVICE
> LOCK
> QUERY_LOCK_STATUS
> ]
>--service-type SERVICE_ [ WIN32 DRIVER ]
>--service-state SERVICE_ [ ACTIVE INACTIVE STATE_ALL ]
I've not said much about the code so far so here goes. I have two needs:
a) A command line version.
b) A GUI version (later).
All the common functionality will be residing inside a "Service" class
so that (a) & (b) will differ only in the gathering of their input and
emission of their output. The initial design implemented everything via
a single class. This is no longer the case. It has been split into
three; four if you include the class which helps turn bitfields into
their "names".
ServiceControl is the front-end. The transparent ServiceControlDatabase
ensures the service manager gets closed again. ServiceControlBuffer
holds the information we want. Finally ServiceStatus can be used to help
format that data. Example...
static void FC
Display(const ServiceControlBuffer & scb)
{
for (size_t i = 0; i < scb.Size(); i++) {
const ServiceStatus ss (scb[i].ServiceStatus);
cout
<< scb[i].lpServiceName << '\n'
<< scb[i].lpDisplayName << '\n'
<< ss.dwServiceType.AsText() << '\n'
<< ss.dwCurrentState.AsText() << '\n'
<< ss.dwControlsAccepted.AsText() << '\n'
;
}
}
..churns out this kind of output...
Browser
Computer Browser
SERVICE_WIN32_SHARE_PROCESS,
SERVICE_RUNNING
SERVICE_ACCEPT_STOP,SERVICE_ACCEPT_SHUTDOWN,
EventLog
EventLog
SERVICE_WIN32_SHARE_PROCESS,
SERVICE_RUNNING
SERVICE_ACCEPT_SHUTDOWN,
<snip>
TapiSrv
Telephony Service
SERVICE_WIN32_OWN_PROCESS,
SERVICE_RUNNING
SERVICE_ACCEPT_STOP,SERVICE_ACCEPT_PAUSE_CONTINUE,
Obtaining the ServicControlBuffer 'scb' to pass to Display can be
achieved thus (error/exception checking omitted)...
/*[$PROTO external]*/
const int FC
ccMain(
const char * const machine,
const char * const database,
const sd::uint32 access_level,
const sd::uint32 service_type,
const sd::uint32 service_state
)
/*[]*/
{
ServiceControl sc (
machine,database,
access_level,
service_type,service_state
);
sc.Active(true);
Display(sc);
return //whatever;
}
..in the above the service manager is is invoked to open the database
when the Active(true) method is called. Active(false) will close it but
this will occur automatically when the underlying ServiceControlDatabase
destructs. I can find nothing in the winapi docs(*) concerning the
effect of having the database open/locked when something else attempts
to do similar so I'm assuming that doing so is detrimental - therefore
it will be possible to copy the information elsewhere and get it closed
asap.
(*) I've been bitten by this kind of microsoft "omission" more than once
before.
The questions...
C++ exceptions - I use them a lot and will create my own when the need
arises. Is this okay?
C++ datatypes - std::string being the most obvious. Offhand I do not
recall seeing any being used in cygwin application sources. Can somebody
elaborate?
Multiple platforms - this last one has had me going round in circles. I
have a preliminary version and need some feedback on how to deliver it.
My primary development environment is C++ Builder. It just so happens it
is relatively painless to have both the borland and gcc compiler using
the same source tree: borland generates .obj extenders for its object
files by default so with Builder making use of a "project file" and gcc
using the "makefile" they co-exist nicely. It has just dawned on me why
I'm having so much trouble with this last question - it isn't specific
to me...
How does Mr Windoze Programmer deliver his windoze app when it contains
a subset that is best targeted as a cygwin package? ;-)
--
swamp-dog AT ntlworld DOT com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -