Hello all,

I'm looking for someone with a bit of free time and a Win32 system who'd
be willing to help out a Free/Libre Open Source Software project.

The project in question is "Harboured", an automated back-up program
designed to backup through firewalls. The help I need is with
implementing a set of functions that make it easy to install and manage
a Windows service. The reason I can't do it myself is that I don't have
a Windows box at home.

The problems to solve are the following:
1. service installation
- POSIX systems don't need any special handling for the installation of
daemons: they just need to get run and dive into the background.
According to whether the system in question is using SystemV-style
or BSD-style init scripts, handling may be slightly different but
that is up to package maintainers to take care of..
- Win32 systems need to have services installed in the registry to have
them be started on system start-up. There is an API that takes care
of this
- The library should provide an install function that takes care of
service installation on either POSIX or Win32 systems - I need
someone to write the Win32 version.
2. service running
- On POSIX systems, when a service is started it "dives into the
background" with a combination of detaching from the tty and a couple
of calls to fork(2)
- On Win32 systems, a service is already started in the background
(IIRC)
- The library should provide a function that takes care of going into
the background. For Win32 systems, this function probably won't need
to do anything (but that should be checked)
3. communicating with the world
The application will communicate with the world through the
command-line and through a network socket connection.
- On POSIX, the command-line is passed to main() - there are no
variations on this scheme..
On POSIX, BSD sockets are ubiquitously available..
- On Win32, there's main() and there's WinMain(). I am not certain, but
I *think* services can't be console applications, meaning they need
WinMain(). In that case, I'd need a WinMain function to call main()
in the "usual" way, perhaps doing anything Windows-specific before
doing so..
Also WinSock is not quite BSD sockets, so some wrapping may be
necessary, That said, there's a C++ wrapper library for sockets for
both Windows and POSIX/Unix/Linux at http://tinyurl.com/423wy, which
might be used..

Harboured is not anywhere in the public domain yet, but if some-one is
willing to join me on this project (which has just come out of the
planning stage) I'll set it up on SourceForge.

License will be GPL.

rlc

In article <2unb1uF2bvn9iU1@uni-berlin.de>, Ronald Landheer-Cieslak <ronald@landheer.com> writes:
I suspect a Windows programming group would probably be the better
place to ask.

And a call to setsid(2) between the two calls to fork(2), I hope. A
daemon should be in its own session and not be a session group leader,
to prevent its acquiring a new controlling tty.

Stevens also recommends changing the current directory to /, so that
the daemon isn't holding a mounted filesystem open. (Some daemons
may use a different cwd.) And setting the umask to 0 and using
explicit permissions for all filesystem-object creation activities,
and closing unneeded file descriptors.

More or less. We're really talking about WinNT-based systems, by the
way, not Win32, which includes Windows 95 and its descendants. They
don't have the Service Manager.

Windows programs do or do not have stdio open in some command-line
session (which might be a cmd.exe session, or might be something
else, such as the SFU ksh implementation). They also do or do not
have a handle to a Desktop on a Winstation. Desktops are the NT
abstraction of the GUI screen: it is the container for application
windows and the like. Winstations are the NT abstraction of the GUI
session; they contain desktops and other GUI objects such as
clipboards. There's at least one interactive Winstation which also
has the keyboard and pointer devices. (There can be multiple
interactive Winstations if Windows is hosting remote users, eg via
Terminal Services.)

A typical CLI program has open stdio handles if it's running in the
foreground. A typical GUI program has an open Desktop handle if it's
running in the foreground, to a Desktop on an interactive Winstation.
A program can have handles to both, but that's rarely useful.

Services have Desktop handles. In theory, they're usually to a
Desktop on a special Services Winstation, which lets them use various
system functions without giving them access to the interactive
Desktop. That's important for various security reasons we needn't go
into here.

However, it's possible to configure a service to use the interactive
Desktop. (In the Services control panel, this is the startup option
"Allow service to interact with desktop".) Many - far too many -
services use this facility in order to put some stupid icon in the
system tray or do something else of marginal usefulness, while
greatly compromising system security. This is because many Windows
programmers are idiots.

In short (I know, too late), Windows services are not necessarily in
the "foreground" or "background" because those terms aren't really
well-defined on Windows. (They're actually not all that well-defined
on Unix, either, once you introduce X Windows, but generally we
understand them to mean whether the program has a controlling tty.)

Ah. In fact, Windows services need to do a bunch of stuff. The
Service Manager requires that services interact with it in various
ways. It's actually a fairly sensible system (for example, service
shutdown is negotiated with the manager, using a simple watchdog
mechanism, so the manager can tell with some confidence whether a
service is hung or just taking a while to clean up). It does require
some work, though. The service must talk to the service manager and
be prepared to respond to requests from it.

Nope. WinMain, generally speaking, is for interactive GUI programs -
ones with windows on the interactive Desktop. I've worked on a couple
of programs that support the Windows Service Manager interface and
neither of them had a WinMain. (They also both support running from
the command line, and detect which mode they're started in. That stuff
isn't hard.)

Generally what happens is you call a function early in startup to see
if you're running under the Service Manager, and if so do your initial
Service Manager setup and then start a thread to handle Service Manager
requests.

Winsock does have its quirks (Winsock2 is a definite improvement), but
IME it's usually pretty trivial to wrap it for POSIX compatibility.

If you can't find anyone else to help with the Windows-specific stuff
I may be able to help out, but I'd have to get permission from Micro
Focus first; since my Windows machines all belong to them, anything I
do on those systems without explicit prior exemption becomes their
property.

--
Michael Wojcik michael.wojcik@microfocus.com

Not the author (with K.Ravichandran and T.Rick Fletcher) of "Mode specific
chemistry of HS + N{_2}O(n,1,0) using stimulated Raman excitation".