Author |
Topic |
|
vta
14 Posts |
Posted - 28 Feb 2005 : 11:17:17
|
On the AGX platform, changing from 4.20.09 to 4.20.12 renders WZC non-operational. The WZC dlls are still present. 4.20.09 apparently allowed the use of either driver, as we used wzc with it, but your OS release notes state that wzc was replaced by Cisco. Our app relies on wzc. We don't want to have to check the registry to know when we're in network. How can we start the WZC service and use that API instead of the Cisco API? |
|
ctacke
877 Posts |
Posted - 28 Feb 2005 : 11:26:59
|
We've had issues with different customers having different needs. The biggest problem with the WZC driver is that when a card is inserted it automatically pops up the SSID selection dialog (though lack of card-specific features has also been an issue). As you can imagine that's not too useful with a headless system. We're in the process of finding a way to allow users to choose (likely via a registry setting) which driver will be available after boot, as well as the behavior of the WZC dialog.
We hope to have something in the near future that will support the OEM card drivers as well as the WZC APIs (though not at the same time). |
|
|
vta
14 Posts |
Posted - 28 Feb 2005 : 12:12:55
|
But with 4.20.12 is there a way to start the WZC service and use that API instead of the Cisco API? If not, then what's the alternative? Can we revert to 4.20.10 to get wzc along with the latest CAN driver, or must we go back to 4.20.09 (where the CAN driver never decrements lpNumberOfBytesRead and it's thread thus chews up infinite bandwidth)?
Our system is headless and we use the wzc programmatically, so it would seem irrelevant that the network dialog pops up. We've tried using the Cisco api **programmatically** and couldn't find enough documentation on usage. This left the choice of obtaining signal strength by checking the registry. That's much less efficient than our wzc usage. |
Edited by - vta on 02 Mar 2005 10:46:12 |
|
|
akidder
1519 Posts |
Posted - 02 Mar 2005 : 12:12:41
|
Neither the Cisco driver nor the Microsoft driver seems to address everyone's needs. We're working on a solution. Stay tuned. |
|
|
vta
14 Posts |
Posted - 02 Mar 2005 : 13:06:53
|
Were happy to use the Cisco driver if there is an API defined. Do you know where that's documented? Without definitions for the IOCTL calls, your customers can't run the client programmatically. For example, you will only know you're in network, by checking signal strength in the registry. If I'm missing something then please let me know, but we do need an embedded solution. |
|
|
akidder
1519 Posts |
Posted - 03 Mar 2005 : 16:10:40
|
We're actively working on figuring out a way to include both wireless drivers in a single build. It would be great if we had more information about how to drill into these drivers, but we don't. We are doing the best we can to find a solution that will work for all our customers.
If you need accelerated work on this project for your application, check with our sales group. Otherwise, we hope to start rolling out a solution (when we find it) on our platforms within the month.
|
|
|
|
Topic |
|