Consider first the hardware-management approach presented in article Q10105. The reason that the DAP devices end up with different identification on different systems is that Windows detects its bus slots and ports in a different sequence on the two hardware systems. Perhaps you can solve the problem by swapping the physical locations of the DAP devices, using the approach described there.

But that approach sometimes isn't feasible because of physical constraints. There is another option: perform an "on-the-fly" substitution of device addresses in the DAPtools "client-side" software (the part that interacts with the application software and supports the DAPIO32 interface).

To use this option, your application programs must refer to DAP devices using artificial path names rather than actual UNC addresses, for example, something like the following.

      hDAP0_MessagesIn = DapHandleOpen("DAP0\\$SysOut", DAPOPEN_READ);
  

In the syntax of C++, the two backslash characters represent the value of one backslash character in the string. The address DAP0\$SysOut is a perfectly valid string, but not a normal UNC path. Under ordinary conditions, the function call would fail when DAPtools "client-side software" (the DAPIO32 programming interface) sends an invalid device address to the DAPtools "server-side" software (which controls devices). However, the "client-side" software first takes each device address and compares it to a local look-up table saved in the registry. If it finds an artificial path string matching the one that the application used, it substitutes the actual device address from the lookup table. Knowledge base article Q10087 describes how to configure the UNC mapping lookup table for the DAPtools software.

There are some potential hazards from using these "on-the-fly" adjustments. The DAPcell installation must be adjusted for each machine, and the configuration could be lost during various software upgrades. Another hazard is that any adjustments in the DAPcell configuration will apply to all applications that run on that system, so all DAP applications on the host system would need to use re-mapped device names consistently.