Compartilhar via


Moving a Notification LED Driver from GWES to Device Manager (Windows CE 5.0)

Send Feedback

Starting with Windows CE .NET 4.2, the notification LED (NLED) driver was the only platform-specific component directly linked into GWES. If you move the NLED driver from GWES to a separate DLL loaded by Device Manager, there are no platform-specific components directly linked into GWES and you no longer need to build GWES in your platform. If your configuration requires the notification LED APIs NLedGetDeviceInfo and NLedSetDevice, you will need to set SYSGEN_NLED=1 to include them in your image. With this change, it is no longer necessary to build GWES in your platform – instead, use "sysgen gwes". The change deletes the GWE directory from the standard platforms. If you are using a different platform, you will need to remove GWE and possibly make your NLED driver, if it exists, an installable driver. The following steps explain how to move an existing NLED driver from GWES to a separate DLL.

To move a notification LED driver from GWES to Device Manager

  1. Determine if your platform's NLED driver actually controls any hardware. Some platforms supply dummy drivers to satisfy the linker when building GWES. If your platform has a dummy NLED driver, you can use the sample NLED driver in public\common\oak\drivers\nleddrvr without modification, or you can delete NLED from your configuration entirely. In this case, go to step 11.

  2. Steps 2 through step 10 convert a GWES-based NLED driver into a platform-dependent driver (PDD) for the NLED driver. The model device driver (MDD) for the NLED driver is located in public\common\oak\drivers\nleddrvr. First, copy your NLED driver files to drivers\nleddrvr in your platform directory.

  3. If the NLedDriverDllEntry entry point in your driver source code, delete it. This entry point has not been invoked for several revisions of the OS, so it is useless if present in your driver.

  4. Because the NLED driver is now being loaded by Device Manager, it is possible that it will be unloaded as well. To handle unloading, add an NLedDriverDeInitialize entry point to your driver. You should already have an NLedDriverInitialize entry point. The NLedDriverDeInitialize routine handles cleanup if the driver is unloaded. It should have the following signature:

    BOOL WINAPI NLedDriverDeInitialize(VOID);
    

    This routine should return TRUE if successful and FALSE if there is an error.

  5. Copy Nleddrvr.def from public\common\oak\drivers\nleddrvr into your driver's directory.

  6. Edit your driver's SOURCES files as follows:

    • Set TARGETTYPE=DYNLINK.
    • Set TARGETNAME=nleddrvr.
    • Set DEFFILE=nleddrvr.def.
    • Set RELEASETYPE=PLATFORM.
    • Set WINCEOEM=1.
    • Add $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\nleddrvr_lib.lib to SOURCELIBS.

    Include any platform-specific libraries your driver needs to link successfully. Determine which libraries might fit in this category by looking at SOURCES files in your platform directories.

  7. Compile and link your driver by running build -c in your platform's drivers\nleddrvr directory. Resolve any build errors before continuing.

  8. Add nleddrvr to the list of directories being built by modifying the DIRS file in your platform directory's drivers directory. This causes the NLED driver to be built automatically when the rest of the platform is compiled.

  9. Add the new NLED driver to your platform's Platform.bib file adding the following lines to the MODULES section:

    ; @CESYSGEN IF CE_MODULES_NLEDDRVR
    
    IF BSP_NONLED !
    IF IMG_NONLED !
        nleddrvr.dll        $(_FLATRELEASEDIR)\nleddrvr.dll                $(REGION_NAME) SH
    ENDIF   ; IMG_NONLED !
    ENDIF   ; BSP_NONLED !
    
    ; @CESYSGEN ENDIF CE_MODULES_NLEDDRVR
    

    Depending on your platform configuration, you may need to replace $(REGION_NAME) with NK in your Platform.bib file.

    The CESYSGEN line is intended to make your platform easier to componentize. BSP_NONLED indicates that even though the NLED component has been selected, your platform does not support it. IMG_NONLED is useful for debugging because it excludes the NLED DLL from your image, which forces the DLL to be downloaded by means of KITL when the driver is loaded. All of these conditionals are optional.

  10. Add the new NLED driver to your platform's Platform.reg file by adding the following lines:

    ; @CESYSGEN IF CE_MODULES_NLEDDRVR
    
    #include "$(DRIVERS_DIR)\nleddrvr\nleddrvr.reg"
    
    ; @CESYSGEN ENDIF CE_MODULES_NLEDDRVR
    

    If your platform does not define DRIVERS_DIR, you can define it at the top of the file by adding this line:

    #define DRIVERS_DIR     $(_WINCEROOT)\public\common\oak\drivers
    
  11. Delete the GWES directory from your platform. It is now linked during Sysgen, not built in your platform. If you do not want to delete the directory, you can remove GWES from your platform's top-level DIRS file.

  12. Delete any versions of GWES still in the platform's target directory. This directory contains executables and DLLs that are linked when the platform is built. To delete the files, use these commands:

    cd %_targetplatroot%\target

    del /s /q gwes.*

    If these files are not deleted, they overwrite the version linked during Sysgen when buildrel copies files to the release directory.

  13. Rebuild your platform, make a new image, and verify that GWES and the NLED interface both work correctly. To do this, from the command line, use blddemo clean -q. In Platform Builder, use the Rebuild command.

Send Feedback on this topic to the authors

Feedback FAQs

© 2006 Microsoft Corporation. All rights reserved.