Maybe each service is just like an application... just some running threads
etc... ?

And maybe only an api to start/stop them ?

So that would mean each service could be totally different, some
communication via protocols others maybe via their own api's etc...

So there is not really a standardized way of using them ?

"Skybuck Flying" wrote in message
news:btav0t$f09$1@news4.tilbu1.nb.home.nl...
> Hi,
>
> Windows NT/2000/XP comes with all these nice services.
>
> Future operating systems of microsoft will have even more services.
>
> It's like the next step. First we had components... and now services.
>
> It seems to me as an interesting idea to split software into multiple
> services and a smaller application.
>
> How does one communicate with these services programmatically ?
>
> ( using windows api, or tcp/ip communication ? )
>
> Does Delphi support these services (using them and writing them).
>
> What are the possibilities offered by this services technology.
>
> Thx,
> Skybuck.
>
>

Suppose I want to write my own service for windows.

How can I let my applications communicate with that service ?

Ofcourse I see the possibility of using protocols like tcp/ip etc and
sockets...

But I don't really like that option... but it would be cool... remote stuff
would also be possible...

But what about a normal/local api ?

I know dll's could use api's... but mostly procedural for compatibility with
other languages...

Maybe the new .NET Framework offers a solution ?

Can services be written in .NET and how to make a .NET application
communicate with such a service ?

( without using protocols possible ? )

Bye,
Skybuck.

"Skybuck Flying" wrote in message
news:btavjo$l84$1@news4.tilbu1.nb.home.nl...
> Maybe each service is just like an application... just some running
threads
> etc... ?
>
> And maybe only an api to start/stop them ?
>
> So that would mean each service could be totally different, some
> communication via protocols others maybe via their own api's etc...
>
> So there is not really a standardized way of using them ?
>
> "Skybuck Flying" wrote in message
> news:btav0t$f09$1@news4.tilbu1.nb.home.nl...
> > Hi,
> >
> > Windows NT/2000/XP comes with all these nice services.
> >
> > Future operating systems of microsoft will have even more services.
> >
> > It's like the next step. First we had components... and now services.
> >
> > It seems to me as an interesting idea to split software into multiple
> > services and a smaller application.
> >
> > How does one communicate with these services programmatically ?
> >
> > ( using windows api, or tcp/ip communication ? )
> >
> > Does Delphi support these services (using them and writing them).
> >
> > What are the possibilities offered by this services technology.
> >
> > Thx,
> > Skybuck.
> >
> >
>
>

Hi !
"Skybuck Flying" wrote in message
news:btav0t$f09$1@news4.tilbu1.nb.home.nl...
> Hi,
>
> Windows NT/2000/XP comes with all these nice services.
>
> Future operating systems of microsoft will have even more services.
>
> It's like the next step. First we had components... and now services.
>
> It seems to me as an interesting idea to split software into multiple
> services and a smaller application.
>
> How does one communicate with these services programmatically ?
>
With different IPC methods ( remember that services are different exe than
you app
> ( using windows api, or tcp/ip communication ? )
TCP/IP possible but in this case all winsock chain work for that , maybe it
will be better to use pipes or
even mapfiles. The using of windows messages possible but strongly not
recommended because you have to open
services for desktop world in this case
Arkady

>
> Does Delphi support these services (using them and writing them).
>
> What are the possibilities offered by this services technology.
>
> Thx,
> Skybuck.
>
>

"Arkady Frenkel" wrote in message
news:#2JJCS10DHA.3116@TK2MSFTNGP11.phx.gbl...
> Hi !
> "Skybuck Flying" wrote in message
> news:btav0t$f09$1@news4.tilbu1.nb.home.nl...
> > Hi,
> >
> > Windows NT/2000/XP comes with all these nice services.
> >
> > Future operating systems of microsoft will have even more services.
> >
> > It's like the next step. First we had components... and now services.
> >
> > It seems to me as an interesting idea to split software into multiple
> > services and a smaller application.
> >
> > How does one communicate with these services programmatically ?
> >
> With different IPC methods ( remember that services are different exe
than
> you app
> > ( using windows api, or tcp/ip communication ? )
> TCP/IP possible but in this case all winsock chain work for that , maybe
it
> will be better to use pipes or
> even mapfiles. The using of windows messages possible but strongly not
> recommended because you have to open
> services for desktop world in this case
> Arkady

Ah yes, thank you for pointing me in some possible directions. I''ll check
it out.

Bye,
Skybuck

>
> >
> > Does Delphi support these services (using them and writing them).
> >
> > What are the possibilities offered by this services technology.
> >
> > Thx,
> > Skybuck.
> >
> >
>
>

Hmm..

..NET remoting seems interesting

"Skybuck Flying" wrote in message
news:btb065$7v5$1@news3.tilbu1.nb.home.nl...
>
> "Arkady Frenkel" wrote in message
> news:#2JJCS10DHA.3116@TK2MSFTNGP11.phx.gbl...
> > Hi !
> > "Skybuck Flying" wrote in message
> > news:btav0t$f09$1@news4.tilbu1.nb.home.nl...
> > > Hi,
> > >
> > > Windows NT/2000/XP comes with all these nice services.
> > >
> > > Future operating systems of microsoft will have even more services.
> > >
> > > It's like the next step. First we had components... and now services.
> > >
> > > It seems to me as an interesting idea to split software into multiple
> > > services and a smaller application.
> > >
> > > How does one communicate with these services programmatically ?
> > >
> > With different IPC methods ( remember that services are different exe
> than
> > you app
> > > ( using windows api, or tcp/ip communication ? )
> > TCP/IP possible but in this case all winsock chain work for that , maybe
> it
> > will be better to use pipes or
> > even mapfiles. The using of windows messages possible but strongly not
> > recommended because you have to open
> > services for desktop world in this case
> > Arkady
>
> Ah yes, thank you for pointing me in some possible directions. I''ll check
> it out.
>
> Bye,
> Skybuck
>
> >
> > >
> > > Does Delphi support these services (using them and writing them).
> > >
> > > What are the possibilities offered by this services technology.
> > >
> > > Thx,
> > > Skybuck.
> > >
> > >
> >
> >
>
>

"Skybuck Flying" wrote in message
news:btb0i2$81p$1@news2.tilbu1.nb.home.nl...
> Hmm..
>
> .NET remoting seems interesting

It does seem a bit new and dangerous

This article sums up some methods

http://www.hower.org/Kudzu/Articles/AdvancedIPC/

And this one looks interesting too: ( shared memory, which is what you ment
with map files ? )

http://www.codeproject.com/threads/sharedmemipc.asp

It works on windows 95/98 too

>
> "Skybuck Flying" wrote in message
> news:btb065$7v5$1@news3.tilbu1.nb.home.nl...
> >
> > "Arkady Frenkel" wrote in message
> > news:#2JJCS10DHA.3116@TK2MSFTNGP11.phx.gbl...
> > > Hi !
> > > "Skybuck Flying" wrote in message
> > > news:btav0t$f09$1@news4.tilbu1.nb.home.nl...
> > > > Hi,
> > > >
> > > > Windows NT/2000/XP comes with all these nice services.
> > > >
> > > > Future operating systems of microsoft will have even more services.
> > > >
> > > > It's like the next step. First we had components... and now
services.
> > > >
> > > > It seems to me as an interesting idea to split software into
multiple
> > > > services and a smaller application.
> > > >
> > > > How does one communicate with these services programmatically ?
> > > >
> > > With different IPC methods ( remember that services are different exe
> > than
> > > you app
> > > > ( using windows api, or tcp/ip communication ? )
> > > TCP/IP possible but in this case all winsock chain work for that ,
maybe
> > it
> > > will be better to use pipes or
> > > even mapfiles. The using of windows messages possible but strongly not
> > > recommended because you have to open
> > > services for desktop world in this case
> > > Arkady
> >
> > Ah yes, thank you for pointing me in some possible directions. I''ll
check
> > it out.
> >
> > Bye,
> > Skybuck
> >
> > >
> > > >
> > > > Does Delphi support these services (using them and writing them).
> > > >
> > > > What are the possibilities offered by this services technology.
> > > >
> > > > Thx,
> > > > Skybuck.
> > > >
> > > >
> > >
> > >
> >
> >
>
>

"Skybuck Flying" wrote in message
news:btb1ci$gjb$1@news2.tilbu1.nb.home.nl...
>
> "Skybuck Flying" wrote in message
> news:btb0i2$81p$1@news2.tilbu1.nb.home.nl...
> > Hmm..
> >
> > .NET remoting seems interesting
>
> It does seem a bit new and dangerous
>
> This article sums up some methods
>
> http://www.hower.org/Kudzu/Articles/AdvancedIPC/
>
> And this one looks interesting too: ( shared memory, which is what you
ment
> with map files ? )
>
> http://www.codeproject.com/threads/sharedmemipc.asp
>
> It works on windows 95/98 too

**** lol the example code is in C++

Oh well.. I am gonna give .NET remoting a try with Delphi 8 for .NET

>
> >
> > "Skybuck Flying" wrote in message
> > news:btb065$7v5$1@news3.tilbu1.nb.home.nl...
> > >
> > > "Arkady Frenkel" wrote in message
> > > news:#2JJCS10DHA.3116@TK2MSFTNGP11.phx.gbl...
> > > > Hi !
> > > > "Skybuck Flying" wrote in message
> > > > news:btav0t$f09$1@news4.tilbu1.nb.home.nl...
> > > > > Hi,
> > > > >
> > > > > Windows NT/2000/XP comes with all these nice services.
> > > > >
> > > > > Future operating systems of microsoft will have even more
services.
> > > > >
> > > > > It's like the next step. First we had components... and now
> services.
> > > > >
> > > > > It seems to me as an interesting idea to split software into
> multiple
> > > > > services and a smaller application.
> > > > >
> > > > > How does one communicate with these services programmatically ?
> > > > >
> > > > With different IPC methods ( remember that services are different
exe
> > > than
> > > > you app
> > > > > ( using windows api, or tcp/ip communication ? )
> > > > TCP/IP possible but in this case all winsock chain work for that ,
> maybe
> > > it
> > > > will be better to use pipes or
> > > > even mapfiles. The using of windows messages possible but strongly
not
> > > > recommended because you have to open
> > > > services for desktop world in this case
> > > > Arkady
> > >
> > > Ah yes, thank you for pointing me in some possible directions. I''ll
> check
> > > it out.
> > >
> > > Bye,
> > > Skybuck
> > >
> > > >
> > > > >
> > > > > Does Delphi support these services (using them and writing them).
> > > > >
> > > > > What are the possibilities offered by this services technology.
> > > > >
> > > > > Thx,
> > > > > Skybuck.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

..NET Remoting with Delphi 8 for .NET is not working (yet?) for me.

I got this error:

[Fatal Error] Could not import assembly 'unit_TRemotableType' because it
contains namespace 'Borland.Delphi.System'

:|

Skybuck.

Mapfile is shared memory for sure , but if you have access in Delphi for
those API I really don't know
Arkady

"Skybuck Flying" wrote in message
news:btb1ci$gjb$1@news2.tilbu1.nb.home.nl...
>
> "Skybuck Flying" wrote in message
> news:btb0i2$81p$1@news2.tilbu1.nb.home.nl...
> > Hmm..
> >
> > .NET remoting seems interesting
>
> It does seem a bit new and dangerous
>
> This article sums up some methods
>
> http://www.hower.org/Kudzu/Articles/AdvancedIPC/
>
> And this one looks interesting too: ( shared memory, which is what you
ment
> with map files ? )
>
> http://www.codeproject.com/threads/sharedmemipc.asp
>
> It works on windows 95/98 too
>
> >
> > "Skybuck Flying" wrote in message
> > news:btb065$7v5$1@news3.tilbu1.nb.home.nl...
> > >
> > > "Arkady Frenkel" wrote in message
> > > news:#2JJCS10DHA.3116@TK2MSFTNGP11.phx.gbl...
> > > > Hi !
> > > > "Skybuck Flying" wrote in message
> > > > news:btav0t$f09$1@news4.tilbu1.nb.home.nl...
> > > > > Hi,
> > > > >
> > > > > Windows NT/2000/XP comes with all these nice services.
> > > > >
> > > > > Future operating systems of microsoft will have even more
services.
> > > > >
> > > > > It's like the next step. First we had components... and now
> services.
> > > > >
> > > > > It seems to me as an interesting idea to split software into
> multiple
> > > > > services and a smaller application.
> > > > >
> > > > > How does one communicate with these services programmatically ?
> > > > >
> > > > With different IPC methods ( remember that services are different
exe
> > > than
> > > > you app
> > > > > ( using windows api, or tcp/ip communication ? )
> > > > TCP/IP possible but in this case all winsock chain work for that ,
> maybe
> > > it
> > > > will be better to use pipes or
> > > > even mapfiles. The using of windows messages possible but strongly
not
> > > > recommended because you have to open
> > > > services for desktop world in this case
> > > > Arkady
> > >
> > > Ah yes, thank you for pointing me in some possible directions. I''ll
> check
> > > it out.
> > >
> > > Bye,
> > > Skybuck
> > >
> > > >
> > > > >
> > > > > Does Delphi support these services (using them and writing them).
> > > > >
> > > > > What are the possibilities offered by this services technology.
> > > > >
> > > > > Thx,
> > > > > Skybuck.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

"Skybuck Flying" wrote in message news:...
> Hi,
>
> Windows NT/2000/XP comes with all these nice services.
>
> Future operating systems of microsoft will have even more services.
>
> It's like the next step. First we had components... and now services.
>
> It seems to me as an interesting idea to split software into multiple
> services and a smaller application.
>
> How does one communicate with these services programmatically ?
>
> ( using windows api, or tcp/ip communication ? )
>
> Does Delphi support these services (using them and writing them).
>
> What are the possibilities offered by this services technology.


Come on, did you even *try* to read any of the MS doc on the subject?

A service is just an application that runs under a distinct login, and
usually does not have access to the desktop. It must also implement
the service control manager interface to allow the OS to start and
stop the service (which for many services, is under a hundred lines of
code). MS, in fact, has a small front end application (called SRVANY,
IIRC) which allow you to run many applications as a service.

In practical terms, writing a service raises issues of installation,
security, communications and management, which are more easily glossed
over in a typical application.

For example a service runs, by default, in the LOCAL_SYSTEM account.
This provides pretty broad access to the local machine, but no windows
networking support (eg. there is no way to read a file in a share on
another machine on the network). Alternatively, you can set up a
service to run with a different signon, but then you get to muck with
setting up an account and whatnot in your installation program.

Also on the installation side, you have to define the service to
Windows.

Since services run independent of any user signon, there are
management issues. For example, most services log messages to the
event log, which isn't that hard, just another area to address. In
terms of management, many services provide a management application,
that uses some form of IPC to communicate with the service. Named
pipes are a popular method, since they interact well with Windows
security (for example, create the named pipe in the service with the
SACL specifying thay only members of group
"MY_SERVICE_MANAGEMENT_GROUP" can open the other end of the pipe, and
voila, only users who are members of that group can manage the
service). Named pipes also work over Windows networking. Other IPCs
can be used as well. TCP/IP, of course (no security there), anonymous
pipes, mailslots, shared memory, pretty much any IPC mechanism you can
use between two processes.

This might be a little off-topic, but is there a tutorial available on this
subject (multiple applications commucating with each other). I know how to
work with TCP/IP but I want to learn more conventional methods.

Evert

> In terms of management, many services provide a management application,
> that uses some form of IPC to communicate with the service. Named
> pipes are a popular method, since they interact well with Windows
> security (for example, create the named pipe in the service with the
> SACL specifying thay only members of group
> "MY_SERVICE_MANAGEMENT_GROUP" can open the other end of the pipe, and
> voila, only users who are members of that group can manage the
> service). Named pipes also work over Windows networking. Other IPCs
> can be used as well. TCP/IP, of course (no security there), anonymous
> pipes, mailslots, shared memory, pretty much any IPC mechanism you can
> use between two processes.

"Evert Pot" wrote in message news:<6RxKb.85665$g%5.3330@amsnews02.chello.com>...
> This might be a little off-topic, but is there a tutorial available on this
> subject (multiple applications commucating with each other). I know how to
> work with TCP/IP but I want to learn more conventional methods.


There have been several books with titles having some permutation of
"Windows Network Programming". None of them are spectacular, but the
ones by Sinha and Ohlund are not bad, and the one by Davis also covers
some non-networking IPC stuff.

Or look at http://www.msdn.microsoft.com/library/

For networking stuff, expand the "+Networking and Directory Service"
item, for general IPC try:

http://www.msdn.microsoft.com/librar...unications.asp

http://www.msdn.microsoft.com/librar..._functions.asp

"Robert Wessel" wrote in message
news:bea2590e.0401052319.519ee3bd@posting.google.c om...
>
> Come on, did you even *try* to read any of the MS doc on the subject?

Note that Skybuck chokes on C++; therefore the documentation would be
dangerous.

"Skybuck Flying" wrote in message
news:btav0t$f09$1@news4.tilbu1.nb.home.nl...
>
> It's like the next step. First we had components... and now services.

If I understand what a "component" is, then I consider a service to be more
like a DOS TSR than a component. A component is OLE/COM/ActiveX stuff,
right? If so, then components and srvices are totally different.

"Skybuck Flying" wrote in message
news:btb1ci$gjb$1@news2.tilbu1.nb.home.nl...
>
> This article sums up some methods
>
> http://www.hower.org/Kudzu/Articles/AdvancedIPC/


That article is interesting, but I think it is either incomplete, erroneous
or misleading; perhaps all of those.

For example, it does not indicate that RPCs are used by COM for
inter-process and inter-system (DCOM) communication. I am not familiar with
networks (programming or otherwise) anywhere close to what the experts here
(in the microsoft.public.win32.programmer.networks newsgroup) are, but it is
my understanding that it is possible for a DCOM client or server to exist in
a non-Windows system and to communicate with a DCOM server or client using
standard (DCE) RPC software.

"Sam Hobbs" wrote in message news:...
> "Skybuck Flying" wrote in message
> news:btav0t$f09$1@news4.tilbu1.nb.home.nl...
> >
> > It's like the next step. First we had components... and now services.
>
> If I understand what a "component" is, then I consider a service to be more
> like a DOS TSR than a component. A component is OLE/COM/ActiveX stuff,
> right? If so, then components and srvices are totally different.


"DOS TSR" as a concept has a huge amount of baggage, which I think
just confuses the issue. Even the first word of the name,
"Terminate", is flatly wrong for what happens in a service. In any
event the functionality of many (most?) TSRs needs to be implemented
in an ordinary applications and *not* in a service. Think SideKick -
clearly an application and not a service.

A *nix deamon or in other OSs, background processes, services or
subsystems are better comparisons.

On 12 Jan 2004 21:42:20 -0800, robertwessel2@yahoo.com (Robert Wessel)
wrote:



>
>"DOS TSR" as a concept has a huge amount of baggage, which I think
>just confuses the issue. Even the first word of the name,
>"Terminate", is flatly wrong for what happens in a service. In any
>event the functionality of many (most?) TSRs needs to be implemented
>in an ordinary applications and *not* in a service. Think SideKick -
>clearly an application and not a service.
>
>A *nix deamon or in other OSs, background processes, services or
>subsystems are better comparisons.

'Terminate' is perhaps misleading in TSR
- although they do sort of 'Terminate' when they return primary
control to DOS

SideKick is just one use of TSRs
- other uses include extensions to DOS and/or background operations
- very like 'Services' and 'hooks'

DCOM use UDP with known ( defined ) message format ( the first bytes are
MEOW word ( a cat was near MS guys when they thought about format IMHO ).
Arkady

"Sam Hobbs" wrote in message
news:uDe8NeV2DHA.2636@TK2MSFTNGP09.phx.gbl...
> "Skybuck Flying" wrote in message
> news:btb1ci$gjb$1@news2.tilbu1.nb.home.nl...
> >
> > This article sums up some methods
> >
> > http://www.hower.org/Kudzu/Articles/AdvancedIPC/
>
>
> That article is interesting, but I think it is either incomplete,
erroneous
> or misleading; perhaps all of those.
>
> For example, it does not indicate that RPCs are used by COM for
> inter-process and inter-system (DCOM) communication. I am not familiar
with
> networks (programming or otherwise) anywhere close to what the experts
here
> (in the microsoft.public.win32.programmer.networks newsgroup) are, but it
is
> my understanding that it is possible for a DCOM client or server to exist
in
> a non-Windows system and to communicate with a DCOM server or client using
> standard (DCE) RPC software.
>
>

"Robert Wessel" wrote in message
news:bea2590e.0401122142.1e167c68@posting.google.c om...
> "Sam Hobbs" wrote in message
news:...
> > "Skybuck Flying" wrote in message
> > news:btav0t$f09$1@news4.tilbu1.nb.home.nl...
> > >
> > > It's like the next step. First we had components... and now services.
> >
> > If I understand what a "component" is, then I consider a service to be
more
> > like a DOS TSR than a component. A component is OLE/COM/ActiveX stuff,
> > right? If so, then components and srvices are totally different.
>
>
> "DOS TSR" as a concept has a huge amount of baggage, which I think
> just confuses the issue. Even the first word of the name,
> "Terminate", is flatly wrong for what happens in a service. In any
> event the functionality of many (most?) TSRs needs to be implemented
> in an ordinary applications and *not* in a service. Think SideKick -
> clearly an application and not a service.
>
> A *nix deamon or in other OSs, background processes, services or
> subsystems are better comparisons.


Yes, a DOS TSR is very primitive, just as DOS is primitive. DOS TSRs are a
bad example but the important thing is to make it clear that "First we had
components... and now services." is the result of a huge misunderstanding.
Unless I misunderstand what is meant by "components", the valididty of that
statement is so far from the truth that it must be corrected.