Compartilhar via

Services.exe Migration for Applications in CE 6.0

  • Artigo

Thanks to Seattle getting snowed in and MS borderline shutting down and me not having an emulator image built yet, this will be my first ever two blog in one day.

OK, enough soon to be dated blog chattiness.  Down to business.

Suppose you're writing an application that calls into a service in servicesd.exe.  (Servicesd.exe still looks weird to me even after knowing about it for 1.5 years, I still keep wanting to call it the old services.exe.)  The list below calls out the changes that you need to be aware of. 

• Applications that registered to be started early in the boot process via the HKLM\Init registry key could indicate not to be started until services.exe had completed initializing in previous versions.  Now, applications should indicate to wait until servicesStart.exe has completed initializing.  servicesStart.exe will not signal to the kernel to start applications waiting on it until all services have been loaded, exactly as services.exe previously did.
• The GetServiceHandle and ServiceIoControl APIs have been deprecated since Windows CE 5.0.  When an application calls these APIs now, the calls will be handled by CreateFile and DeviceIoControl in order to maintain some application compatibility.  Note that there will be some changes to the way that the service is called in this case.  Previously GetServiceHandle would not call a service’s xxx_Open; now it will.  The handle returned by GetServiceHandle must be closed with CloseHandle.  In previous releases this was not the case.

• Applications could previously do h = ActivateService(L"Foo",...) and then ServiceIoControl(h), using the returned handle.  This is no longer supported, relating to the changes in the point above about ServiceIoControl ultimately only being able to process true kernel handles from CreateFile, not from GetServiceHandle or ActivateService.
• GetServiceHandle no longer retrieves the fields for szDllName and pdwDllBuf.
• When an application calls ServiceEnumInfo, the service handle is no longer returned in the hServiceHandle member of ServiceEnumInfo.  This field is now always NULL.
• The RegisterService API has been removed.
• ServiceAddPort no longer will persist super-services registry values using the szRegWritePath value.  Applications that want super-services registry key changes must manually write these out to the registry.

%95 of applications that are using servicesd.exe have no real clue they're doing it and won't need to change.  For instance, apps that use MSMQ are calling to servicesd.exe under the covers but don't realize this thanks to abstraction.   These apps won't change at all.  So this really only applies to apps that are directly manipulating services themselves via the services.exe API's a la GetServiceHandle.  RegisterService may have to come back in the next Windows Mobile release, it seems that apps are using it after all.

[Author: John Spaith]

Comments