On Sat, 31 Jul 2004 12:45:07 UTC, "Mike Weiss"
<
w_eis_smik_e_REMOVE_UNDERSCORES_AND_CAPS@hotmail.com>wrote:
Quote
I'm developing a Windows Service (using ATL). The Service EXE must use a
legacy COM/OLE component, written in MFC, that uses several CAsyncSocket
classes to send and receive data on the network.
I've just discovered that CAsyncSocket uses a window internally to do it's
"magic".
Is there ANY WAY for this to work inside a Service??
I'm unsure what windowing services exist (if ANY?!) when running as a
Service. So far I can only get the system to work when not running as a
Service - so it doesn't look good...
HELP!!
Mike,
Yes, Services generally don't have windows and that causes a minor
problem when moving part of an application into that mode. I've used
TCP/IP on other systems for years before the C*Socket stuff was created.
Its always seemed hokey that they required a window for so many things
that could have just had normal interface hooks.
If you want, you can run a GUI app as a service. Its not really
a service, but it can be done. There are a couple ways to run
normal apps as servies. The GUI isn't available to a user, but
the rest of the code does function. You'd need to add some method
to control it though since it doesn't conform to the normal service
control logic.
I've heard obscure references to getting the window event handler
loop to run in a service but never been able to find an example. Those
that made any comment generally said "... it can be done with far
too much effort..."
I've preferred to rewrite all the legacy windows code I have to
use code I can trust. The original code base was based on CSocket
which worked fine in the lab but wasn't stable enough for the
intended use. CAsyncSocket is a bit better but still requires a
window to operate. Any *nix TCP/UDP/IP example code works under
Windows using the WinSock interface. The code is much smaller than
you might expect (for a robust solution). This type of code requires
a responsive thread just like a window would provide, but it can be
easily ported to a service with no rework. I work mostly in C++
and have my own classes for such communications. So long as you
are able to handle multi-threaded programming or work the required
socket logic into your existing window logic it can be done. I'm
not sure what options VB has.
This doesn't help you with your legacy COM/ATL code (the first
couple options might) but if you have the source to those objects
perhaps you could move them to non-windows based socket logic.
Search Google for "CSocketServer CSocketClient C++ windows" and
you can find many articles and third party tools (nearly all free
and easy to use).
David
-
