[ros-dev] [ros-diffs] [ekohl] 45640: Partially revert patches 45626 and 45633. Several services do not report their status to the service manager properly. Therefore we must not use any code that relies on service status information as part of the setup and boo

[Eric Kohl]

Ged Murphy wrote:
> Are these our services and if so do you have a note of which ones?
> 
> 
> -----Original Message-----
> From: ros-diffs-bounces at reactos.org [mailto:ros-diffs-bounces at reactos.org] On Behalf Of ekohl at svn.reactos.org
> Sent: 20 February 2010 23:11
> To: ros-diffs at reactos.org
> Subject: [ros-diffs] [ekohl] 45640: Partially revert patches 45626 and 45633. Several services do not report their status to the service manager properly. Therefore we must not use any code that relies on service status information as part of the setup and boot pr
> 
> Author: ekohl
> Date: Sun Feb 21 00:10:53 2010
> New Revision: 45640
> 
> URL: http://svn.reactos.org/svn/reactos?rev=45640&view=rev
> Log:
> Partially revert patches 45626 and 45633.
> 
> Several services do not report their status to the service manager properly. Therefore we must not use any code that relies on service status information as part of the setup and boot processes as long as these issues have not been fixed. The service manager still needs to provide fake information about the service status.
> 
> Modified:
>     trunk/reactos/base/system/services/database.c
>     trunk/reactos/dll/win32/syssetup/install.c

Yes, these are our services (in the meaning of: they are in our source 
tree).

The dhcp service is totally broken, besause it doesn't report anything 
back to the service manager, it doesn't even retrieve a service status 
handle. ;-( Rpcss, umpmpmgr and eventlog might need some work too but 
I'm not really sure about this because the service manager doesn't 
protect the service database from concurrent access yet.

I haven't checked the manually starting services yet.

These services seemed to run properly because the service mamager 
started the process of a given service, sent a start command to the 
services main thread and silently set the status to 'running'. With 
Dmitrys patches, the service manager sets the service status to 'start 
pending' and waits for the service to report the status changes.

Now, an application like 2nd stage setup may check umpnpmgr for example. 
It finds out that the service is 'start pending' and bails out, although 
the service is running properly. It just forgot to tell the service 
manager that it is running.

I hope this answers your question.

Now, I've got something to clean up...


Regards
Eric