none
distributing device driver RRS feed

  • General discussion

  • I was wondering what the thoughts of people are on distributing a device driver (DLL driver, application .exe) for CE.  Do you have to give the source code?  So far I have two subprojects, the DLL driver and an application.  The application has some nice library functions in it and so I'll probably want to make this into a DLL as well, right?  So far all I've done is rebuild my NK.BIN whenever I changed the code.  But can I, or is it common, to just send people the .exe or .dll and let them plug it into Platform Builder to make their own NK.BIN?
    Wednesday, July 21, 2010 9:33 PM

All replies

  • I have a similar problem, but I've thought that if I can just sign the .dll properly, then it won't need to be built into a new image to work.  I'm hoping to be able to distribute the .dll packaged in a CAB file that also adds the driver to the HKLM\Drivers\Builtin key.  Does anyone know if that would be a viable solution to the problem?
    Wednesday, July 21, 2010 9:46 PM
  • I didn't even think as far ahead as you describe.  Part of the reason I am posting this is to hear all ideas.  I'm sure I could try one or two things and find a "workable" solution, but I am hoping that if lots of people contribute to this post then we can all know the "best" solution.  Also, if the recipient is going to put it in platform builder, would it be suitable to just tell them what to add to the registry?  Or send them a .reg file and let them manually merge it with their current .reg file?

     

    Is your DLL a driver or a standard DLL?  I am actually thinking I will distribute two DLLs.  One is the driver itself, another would be for some interface wrapper functions I made.

     

     

    Wednesday, July 21, 2010 9:54 PM
  • If you are supplying a driver so your OEM customers can add it to their
    BSP and built an NK from it then I think the best way is to just ZIP it
    up (in binary form) like this:
     
    folder: DRIVERNAME\
     
    file: dirs
    DIRS=\
    PDK \
    SDK \
     
    file: driver.reg
    IF BSP_MYDRIVER
    [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\MyDriver]
    "Dll" = "mydriver.dll"
    "Prefix" = "DRV"
    "Index" =dword:1
    "Order" = dword:0
    "IClass"="{A32942B7-920C-486b-B0E6-92A702A99B35}"
    ENDIF
     
    folder: DRIVERNAME\PDK
     
    file: makefile (standard makefile)
     
    file: sources
    !IF "$(BSP_MYDRIVER)" == ""
    SKIPBUILD=1
    !ENDIF
     
    TARGETNAME=MYDRIVER
    TARGETTYPE=LIBRARY
    RELEASETYPE=PLATFORM
    SOURCES=
     
    FILE_VIEW_RESOURCE_FOLDER=\
    ...\driver.reg \
     
    WINCETARGETFILES=Binary.BINCOPY
     
    file: makefile.inc
    Binary.BINCOPY:
    xcopy /I /D /Q "target\$(WINCEDEBUG)\$(TARGETNAME).*"
    "$(_TARGETPLATROOT)\target\$(_CPUDEPPATH)\"
     
    folder: DRIVERNAME\PDK\target
    containing folders:
    DRIVERNAME\PDK\target\debug
    DRIVERNAME\PDK\target\retail
    containing the driver dll, map, pdb and rel files
     
    If you supply a driver binary for more than 1 architecture, you should
    use the proper CPUDEPPATH in the xcopy source as well and adjust the
    above folder structure.
     
     
    Now if you also supply an SDK file so users of your driver can easily
    interface with your driver (also by PInvoking from managed code), then
    also supply the following folder structure:
     
    folder: DRIVERNAME\SDK
     
    file: makefile (standard makefile)
    file: sources
    !IF "$(BSP_MYDRIVER)" == ""
    SKIPBUILD=1
    !ENDIF
     
    TARGETNAME=MYDRIVERSDK
    TARGETTYPE=LIBRARY
    RELEASETYPE=PLATFORM
    SOURCES=
     
    WINCETARGETFILES=Binary.BINCOPY
     
    file: makefile.inc
    Binary.BINCOPY:
    xcopy /I /D /Q "target\$(WINCEDEBUG)\$(TARGETNAME).*"
    "$(_TARGETPLATROOT)\target\$(_CPUDEPPATH)\"
    xcopy /I /D /Q "lib\$(TARGETNAME).H" "$(_PROJECTSDKROOT)\INC\"
    xcopy /I /D /Q "lib\$(WINCEDEBUG)\$(TARGETNAME).*"
    "$(_PROJECTSDKROOT)\LIB\$(_CPUINDPATH)\"
     
    folder: DRIVERNAME\SDK\target
    containing folders:
    DRIVERNAME\SDK\target\debug
    DRIVERNAME\SDK\target\retail
    containing the driver SDK dll, map, pdb and rel files
     
    and folder: DRIVERNAME\SDK\lib
    containing the SDK header file and the folders:
    DRIVERNAME\SDK\lib\debug
    DRIVERNAME\SDK\lib\retail
    containing the driver SDK lib and exp files
     
    Again, if you supply a driver SDK binary for more than 1 architecture,
    you should use the proper CPUDEPPATH in the xcopy source as well and
    adjust the above folder structure.
     
     
    To recap, your ZIP will contain the following folder/file structure:
     
    DRIVERNAME
    | dirs
    | driver.reg
    |
    +---PDK
    | | makefile
    | | makefile.inc
    | | sources
    | |
    | \---target
    | +---debug
    | | MYDRIVER.dll
    | | MYDRIVER.map
    | | MYDRIVER.pdb
    | | MYDRIVER.rel
    | |
    | \---retail
    | MYDRIVER.dll
    | MYDRIVER.map
    | MYDRIVER.pdb
    | MYDRIVER.rel
    |
    \---SDK
    | makefile
    | makefile.inc
    | sources
    |
    +---lib
    | | MYDRIVERSDK.h
    | |
    | +---debug
    | | MYDRIVERSDK.exp
    | | MYDRIVERSDK.lib
    | |
    | \---retail
    | MYDRIVERSDK.exp
    | MYDRIVERSDK.lib
    |
    \---target
    +---debug
    | MYDRIVERSDK.dll
    | MYDRIVERSDK.map
    | MYDRIVERSDK.pdb
    | MYDRIVERSDK.rel
    |
    \---retail
    MYDRIVERSDK.dll
    MYDRIVERSDK.map
    MYDRIVERSDK.pdb
    MYDRIVERSDK.rel
     
    If you follow all instructions above and supply this zip to your
    customer than all they have to do is expand the ZIP into their
    PLATFORM\BSP\SRC\DRIVERS folder and set BSP_MYDRIVER.
     
    The SDK files will automatically be included in the SDK your customer
    will roll and they don't have to worry about registry settings either.
     

    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.
    Wednesday, July 21, 2010 11:58 PM
    Moderator
  • Now if you also supply an SDK file so users of your driver can easily
    interface with your driver (also by PInvoking from managed code), then
    also supply the following folder structure:

    Thanks. This is exactly the type of thing I was looking to find out. One comment though related to the SDK concept: When testing my driver I wrote a subproject that was created as a "Hello World" exe using the Wizard. At first I just made calls to ReadFile and WriteFile from main(). Then I wrote my wrappers for these (there are special considerations for writing to this memory so the wrappers are definitely needed). So now the subproject is main() with two wrapper functions, all in the same source file. What I was thinking of doing was just making another DLL and putting the wrapper functions in there, then the exe subproject could invoke the DLL. Does this sound like a decent substitute for an SDK? Then I can just add the subproject1.cpp file (with just main()) to the zip file, letting it be an example of how to call my wrapper functions.
    Thursday, July 22, 2010 3:36 PM
  • Just put your wrapper functions in a DLL, supply a header file with the
    function definitions of the wrapper functions and follow the folder
    structure I showed in my previous email. If you don't do that (but just
    ship your wrapper DLL separate), your wrapper DLL (which is the SDK DLL)
    won't be rolled into the SDK, so end users won't be able to access your
    driver when using a device with the final NK flashed to it.
     
    As for your cpp file: Normally you would ship an example Visual Studio
    2008 project showing how to use your wrapper DLL (or a simple CPP file,
    but it's a bit more user friendly to ship something your end users can
    build straight away).
     

    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.
    Thursday, July 22, 2010 11:43 PM
    Moderator