Services.exe Migration (Windows Embedded CE 6.0)

1/6/2010

This topic provides information that is helpful when you migrate services and applications that use services from previous versions of Windows Embedded CE to Windows Embedded CE 6.0. Services.exe was rewritten and renamed in CE 6.0 for the new kernel, so you must be careful when you migrate your services.

Services.exe Migration for Windows Embedded CE 6.0

The following information is important to understand when you migrate from a previous version of Windows Embedded CE to Windows Embedded CE 6.0.

• In previous versions of Windows Embedded CE, the name of this process was services.exe. In the current version of Windows Embedded CE, the name of this process is servicesd.exe.

• In CE 6.0, servicesd.exe is a process that acts as a host to service DLLs. Services that run for a long time and that do not need direct access to hardware or kernel functions, such as the TCP stack, should be hosted by servicesd.exe, rather than being hosted in the kernel. Servicesd.exe provides enhanced loading capabilities, such as support for starting, pausing, and stopping services. The process services.exe, which was the host process of services DLLs prior to CE 6.0, now only acts as a command line interpreter.

• In CE 6.0, IOCTL_SERVICE_CALLBACK_FUNCTIONS is no longer supported.

• For the HKEY_LOCAL_MACHINE\Services\<Service Name> registry subkey, the old named value Context must never be set; if it is set, the service will fail to load. For this subkey, the following named value is new for CE 6.0:

  Value: type	Description
  ServiceContext : REG_DWORD	Initial value passed into the initialization routine.

• For the HKEY_LOCAL_MACHINE\Services\<Service Name> registry subkey, the Flags named value has an additional option:

  DEVFLAGS_NOUNLOAD (0x00000020) Do not allow the service to be unloaded.
  

• To unload a service in CE 6.0, you can use the following sample code. This code completely unloads the service DLL from the service host, unless the service has the DEVFLAGS_NOUNLOAD flag set. When this flag is set, attempts to unload the service by using DeregisterService will fail. To reload an unloaded service, you must call ActivateService.
  In the following sample code, szServicePrefix will be a service prefix in the form “HTP0:” as an example.

  HANDLE h = CreateFile(szServicePrefix,GENERIC_READ|GENERIC_WRITE,0,
                            NULL,OPEN_EXISTING,0,NULL);
  
      if (h == INVALID_HANDLE_VALUE) {
          return 0;
      }
  
      DEVMGR_DEVICE_INFORMATION devInfo;
      devInfo.dwSize = sizeof(devInfo);
  
      if (! GetDeviceInformationByFileHandle(h,&devInfo)) {
          CloseHandle(h);
          return 0;
      }
  
      // Must close handle before unloading so there's no open references.
      CloseHandle(h);
  
      if (! DeregisterService(devInfo.hDevice)) {
          return 0;
      }
  

Services.exe Migration for Services in CE 6.0

The following information is important to understand when you migrate a service written for a previous version of Windows Embedded CE to Windows Embedded CE 6.0.

• The virtual memory model for Windows Embedded CE has changed. Previously, each application was limited to a 32 megabyte virtual address space. In the current version, each application has a 4 gigabyte virtual address space. Because of this, services cannot directly access pointers when processing a PSL call, as they did previously. For more information on migrating a driver, see Migrating a Windows Embedded CE Driver to Windows Embedded CE 6.0.
• Previously, the process that was named services.exe acted as both the host for service DLLs, when it was the first services.exe instance created on a system, and a command-line interpreter that enabled operations on services such as stopping a service, starting a service, and so on. In CE 6.0, the process that hosts service DLLs is now named servicesd.exe. Currently, the services.exe process only acts as a command-line interpreter.
• For the HKEY_LOCAL_MACHINE\Services\<Service Name> registry subkey, the Context registry value for service DLLs must not be used. When you set Context to a non-zero value, servicesd.exe will not load your service. To configure options, such as SERVICE_INIT_STOPPED (0x00000001), you must set the ServiceContext registry value, not the Context registry value.
• You can no longer instantiate an additional, limited-functionality copy of services.exe to host a service in its own process space. This functionality was previously enabled by using the SERVICE_INIT_STANDALONE Context flag.
• In previous versions of Windows Embedded CE, from the services command line, a user could type a command such as services command <servicePrefix> arg1 arg2 arg3… and then the arguments were passed to the specified service through IOCTL_SERVICE_COMMAND_LINE_PARAMS. This functionality is no longer supported in CE 6.0.
• In previous versions of Windows Embedded CE, services.exe queried a service with IOCTL_SERVICE_QUERY_CAN_DEINIT before unloading the service. The service could indicate that it did not want to be unloaded by using this mechanism. This functionality is no longer supported. In the current version, a service can indicate that it should not be unloaded by setting the Flags registry value to DEVFLAGS_NOUNLOAD.

Services.exe Migration for Applications in CE 6.0

The following information is important to understand when you migrate applications from a previous version of Windows Embedded CE that interact with a service DLL on the same Windows Embedded CE powered device.

• Applications can be registered through the HKEY_LOCAL_MACHINE\Init registry key to be started early when a device starts up. In previous versions of Windows Embedded CE, these applications could specify not to be started until services.exe had completed initialization. In the current version, applications should indicate to wait until servicesStart.exe has completed initialization. ServicesStart.exe will not signal to the kernel to start applications waiting on it until all services have been loaded, which is exactly what services.exe did previously.
• The GetServiceHandle and ServiceIoControl functions have been deprecated since Windows CE 5.0. When an application calls these functions in the current version, the functions will be handled by CreateFile and DeviceIoControl in order to maintain application compatibility. Notice that there are changes in the way that the service is called when this occurs. Previously, GetServiceHandle would not call the xxx_Open function of the service; in the current version of Windows Embedded CE, it does call this function. In the current version, the handle returned by GetServiceHandle must be closed with CloseHandle, which was not required in previous versions.
• 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 function has been removed.
• In the current version of Windows Embedded CE, the ServiceAddPort function no longer persists super-services registry values by using the szRegWritePath value. If an application wants super-services registry key changes, it must manually write these values in the registry.

For general migration information, see Migrating from an Earlier Version of Windows Embedded CE.

See Also

Other Resources

Services.exe