|
|
Rawether for Windows V5.5.17.00
|
|
Over 30 new 802.11 support functions added to Rawether DLL. | |
|
New NDIScope 802.11 property and control pages. These pages illustrate using the new 802.11 functions exported by the Rawether DLL. |
This release adds support for Windows XP 64-Bit Edition for 64-Bit Extended Systems (AMD64). Rawether supports both 32-bit and 64-bit applications on AMD64. In fact, the same 32-bit Rawether application can run on all Windows platforms from Windows 95 through Windows XP 64-bit Edition.
Rawether does NOT currently support
Intel ia64 (Itanium) 64-bit platforms.
As part of this release the Rawether DLL has been fairly extensively overhauled. Redundant and deprecated code has been removed and important warnings uncovered by the more recent compilers have been addressed. Additional DLL modifications were made, including:
|
Added 802.11 Helper Functions - As mentioned above. | |
|
Added Service Control Manager (SCM) Support Functions - Used to control Rawether drivers and the Microsoft Wireless Zero Configuration (WZC) service. | |
|
Changed DLL Export Conventions from _cdecl to WINAPI - Simplifies interfacing the Win32 NDIS API to C#, Visual Basic .NET and certain Borland languages. As a consequence the Rawether VBW32N_XYZ API family is no longer needed and has been eliminated. |
Including some small changes that may improve the efficiency of the multi-packet read driver. Improved reference counting associated with handling NDIS requests.
Some improvements in detecting shutdown situations have been added to the packet collection application samples.
Of course, one of the more noticeable changes associated with this release is the changes in the stock names of the Rawether runtime components. Click here to see the V5.5 component names.
These name changes can also be seen in the Rawether V5.5 simplified block diagram.
With this release Rawether finally abandons the legacy Microsoft Visual C++ 6.0 development environment and moves to Microsoft Visual Studio .NET 2003. There is some work involved in making this transition because the more recent compilers catch errors that went unnoticed in the older environment. PCAUSA had to systematically resolve a few new warnings. If you haven't made this move yourself, then the newer compiler will probably uncover some previously undiscovered problems in your own code.
Mailing Lists ·
PCAUSA Newsletter
·
PCAUSA Discussion List
|