Interface unit descriptor vs. device unit descriptor

Question

In NI-488.2 Function Reference Manual for Windows (321038g) the description of ibfind() says in its last Note that ibfind() is deprecated for use in finding device descriptors. It doesn't say if ibfind() should still be used in new applications to find interface descriptors but I think it seems to be necessary. The description of ibdev() says that ibdev() only opens device descriptors so it seems to be useless for part of my needs.
However, ibfind() is still capable of finding device descriptors despite being deprecated for that purpose. I downloaded the example of two computers from ftp://ftp.ni.com/contrib/epd/B45EACE3DD1C56A4E034080020E74861/two_computers.zip
In the example, both the controller and the non-controller call ilfind() which calls ibfind(). The controller calls ibfind("GPIB0") and I think it gets an interface unit descriptor. The controller calls ibfind("DEV1") and I think it gets a device unit descriptor with a connection to the non-controller. But the non-controller calls the same ibfind("GPIB0") and it gets a device descriptor with a connection to the controller!
How does ibfind() know whether the caller wants an interface unit descriptor or a device unit descriptor? As far as I can tell, ibfind() seems to be reading the programmer's mind. How can I be sure it will read my mind correctly?
Also, what happens if there are three computers? When the controller calls ibfind() three times, ibfind() might magically figure out which call to return an interface unit descriptor and which two calls to return device unit descriptors. But how will the "DEV1" and "DEV2" calls be matched up against the correct non-controllers? The controller needs some way to know which device is which.
I see how to set a primary address on a unit descriptor, but this doesn't solve anything. If the unit descriptor has magically been opened as an interface unit descriptor then great, I can set my own board's address. If the unit descriptor has magically been opened to a device unit descriptor connected to a random choice of non-controller device, then I can set the unknown device's address, but I still don't know which device it is.
I think I need to make each computer open its own interface and set the primary address of its own interface, and next I need to make the controller open each device at a known address for each device, but I can't find any way to achieve the necessary detail of control for any part of this.

Answer 1

I think this part of your answer really answers my first question:
> ibfind will open a interface unit descriptor if the
> name used is GPIB where id is the interface
> number (GPIB0, GPIB1, ...).
May I suggest that the description of ibfind() in the NI-488.2 Function Reference Manual for Windows (321038g) would really benefit from the addition of this information.
It also still seems that ibfind() is not deprecated for this purpose because ibdev() cannot open an interface. ibfind() is deprecated in the case of opening a device only, because ibdev() is more flexible for devices, but this has no bearing on the necessity of ibfind() for interfaces.
By the way, if suggestions are permitted: If there were an ibint() function then ibfind() c
ould be deprecated completely. Programmers could see immediately if a call was opening an interface through ibint() vs. a device through ibdev().
Regarding the two computers example, the comment in the non-controller code really confused me. The comment implies that ibfind() is opening a device descriptor there. Now I understand that the non-controller isn't directly opening a device connection to the controller, the non-controller is only opening its own interface because ibfind() gives special treatment to strings of the form "GPIB". (Of course the designer knows that this device will be the target of the controller, but that's not under the control of the non-controller's call to ibfind().)
Now I'm off to search for GpibConf.exe. I guess this utility is newer than the September 2000 driver disk.
(I remember once upon a time when devices weren't powerful enough to run a program like GpibConf.exe, but in my current application the target devices are running Windows 2
000. Maybe the next generation of voltmeters will crash frequently :-) Does LabView accurately display the instruments' Blue Screens of Death :-?)