• PDD_AudioInitialize – setup the PCV100 hardware
• PDD_AudioGetInterrupt – handle the PCV100 interrupts
• PDD_AudioMessage – interpret the custom PCV100 hardware control messages

The most challenging part of the device driver development turned out to be the learning curve for Platform Builder. The actual device driver coding was straightforward by comparison.
In addition to the development of the PDD code, the device driver development required modification to three of the platform files:

• Config.bib – reserve a 64KB physical DMA buffer area below the kernel
• Platform.bib – include the pcv100.dll in the kernel image
• Platform.reg – insert registry entries so device.exe can find and load pcv100.dll

With Windows CE .NET version 4.0 the operating system supports specific service modules previously not supported. Historically, Windows CE services were software device drivers masquerading as services. This led to the current method for Windows CE .NET services which borrows greatly from the device driver model.

The almsrv service resides in the Services.exe slot the same way drivers do in the Devices.exe slot. In particular, the almsrv service creates a main alarm thread to wait on alarm events. When received a dialing routine cycles through the telephone list held in memory calling each number in turn. The list is cycled until DTMF confirmation is received.

The almsrv service also maintains the almConfig.ini file for configuration purposes and outputs to the almsrv.log file for monitoring alarm activity. Both files reside in the \Windows\ directory.

The almsrv service was based on the sample Tcksrv service. Most of the basic functions were left intact except for those regarding use of the Super Service that gives access to monitoring ports which of course had no use in this project. No significant problems were faced in the creation of the service. Most of my time was spent in vain trying to add Text-to-Speech support to augment the waveform playback. Despite the version 5.0 SAPI (Speech API) included with CE .NET 4.2, simple speech output was never achieved.

There were several methods tried for developing the GUI interface including:

• Visual Basic and C++ hybrid (VB GUI and C++ DLL)
• Pure C++
• Pure C#

The design started with the VB C++ hybrid and moved on to the pure C++ design because of problems and then again to C#. The problems encountered with each are listed below.

Visual Basic and C++ hybrid
• Visual Basic could not find the functions in the C++ DLL
• Could not figure out how to get an array of strings between the VB and C++

Pure C++
• Visual Studio .NET 2003 can not be setup to write applications in C++ for Windows CE. Wanted to use VS .NET because it has C++ GUI building tools.

Pure C#
• Found out that the .NET Compact Framework does not contain the functions necessary to interface with the service routine. Did not have time to figure out how to do it another way.

Finally the problems with the VB C++ hybrid design were solved and it was used. The first problem was solved by adding the “extern “C”” directive to each function header being exported in the DLL. This keeps the C++ compiler from adding decorations to the function names which was keeping the VB GUI from finding them. The second problem was solved by allowing the GUI to write the configuration INI file. If any changes are made to the configuration the GUI writes it to the file and then sends a command to the service telling it that the configuration has changed.