45 replies to this topic

[Comedy]

That's a nice bit of coding I used to use SC.exe but I'll be switching to this straight away.

[WaZaa]

Oooh my goodness, .. this is some explanding work, .. really impressive ...

i would like to know as much as you about programming such a code, ...

really nice ... and learnfull

so gonna take a closer look, thanks for code + exe!

Greetz WaZaa

[apoc_neo]

ok, seem i missed out the header file in the source code all these times!

latest release and source attached.

Note that the restart service option fails on cygwin apps, since the pid returned by createprocess is different to the final pid of a cygwin app (due to the way cygwin works).

you should remove the injection code if you need it to work on such apps.

i also added a bug fix where it was not providing parameters to apps correctly.

something is now wrong with the file you attached, it says it is corrupt.. can anybody double check this and confirm it?

[hm1ch]

the file isn't corrupt for me.
Try to download it again.

Friendly.

[globey]

first, tnx for this great tool
its batter then FD in my opinion.

but i got problem. i try to make service to my bnc and the prog run my bnc more the 1 time.
what can i do?

[tibbar]

is your bnc running under cygwin?

[S3M73X]

Hi tiddbar,

i am using psyBNC on win32 which is compiled with cygwin.
I wanted it to make it a service with ServiceME, the Microsoft SRVany and also with your ServiceDaemon.

But none of it works. It says it starts the service successfully but it does not listen on the Port. If i start the psyBNC normally it works.

So do you have an idea whats wrong in there? I guess it is a problem caused by cygwin but i dunno howto solve that.

[tibbar]

cygwin is a real bastard. it creates a new process after you run it, so the PID changes 500ms after you do net start xxxx.

i'm sure i posted an how-to somewhere on gso about this, which get's around the problem with servicedaemon...

ok:

QUOTE
Process Creation

The fork call in Cygwin is particularly interesting because it does not map well on top of the Win32 API. This makes it very difficult to implement correctly. Currently, the Cygwin fork is a non-copy-on-write implementation similar to what was present in early flavors of UNIX.

The first thing that happens when a parent process forks a child process is that the parent initializes a space in the Cygwin process table for the child. It then creates a suspended child process using the Win32 CreateProcess call. Next, the parent process calls setjmp to save its own context and sets a pointer to this in a Cygwin shared memory area (shared among all Cygwin tasks). It then fills in the child's .data and .bss sections by copying from its own address space into the suspended child's address space. After the child's address space is initialized, the child is run while the parent waits on a mutex. The child discovers it has been forked and longjumps using the saved jump buffer. The child then sets the mutex the parent is waiting on and blocks on another mutex. This is the signal for the parent to copy its stack and heap into the child, after which it releases the mutex the child is waiting on and returns from the fork call. Finally, the child wakes from blocking on the last mutex, recreates any memory-mapped areas passed to it via the shared area, and returns from fork itself.

While we have some ideas as to how to speed up our fork implementation by reducing the number of context switches between the parent and child process, fork will almost certainly always be inefficient under Win32. Fortunately, in most circumstances the spawn family of calls provided by Cygwin can be substituted for a fork/exec pair with only a little effort. These calls map cleanly on top of the Win32 API. As a result, they are much more efficient. Changing the compiler's driver program to call spawn instead of fork was a trivial change and increased compilation speeds by twenty to thirty percent in our tests.

However, spawn and exec present their own set of difficulties. Because there is no way to do an actual exec under Win32, Cygwin has to invent its own Process IDs (PIDs). As a result, when a process performs multiple exec calls, there will be multiple Windows PIDs associated with a single Cygwin PID. In some cases, stubs of each of these Win32 processes may linger, waiting for their exec'd Cygwin process to exit.


Ok, this explains why!

So the rule is, if you use servicedaemon for cygwin based apps, dont set it to restart. Only use options 0 0 or 0 1.

[aiO]

very nice job.


Is there a way to do it so ServiceDaemon.exe does not run along with the service?

[tibbar]

no

[John]

Hey tibbar, I am experiencing some problems with your source code. My problem is when I recompile from your source, using Visual Studio 6 and Visual Studio 8, both compiled in debug then release modes. Everytime I run a program with ServiceDaemon, it crashes and keeps relauching it with the same result.

I have once before found the solution to this problem, and it had something to do with the compiler or my compiler settings. But either I have forgotten what I did, or what I am doing now is not working.

[tibbar]

I don't think there's anything special you need to do - are you sure you are not trying to launch a cygwin based app - these will fail unless on mode 0.

[John]

Indeed I was, thanks for your help Tibbar.

[Deeya]

Good job mate;>

[sars]

my application is in task manager but it does not do its job. for example; doesnt create a file or write in a file etc.