The following sections describe differences between network drivers for Windows 95 and Windows NT versions 3.0 and 3.5.
Windows 95 does not handle large integer math. Do not call a large integer function, such as RtlConvertUlongToLargeInteger, in your Windows 95 driver.
Windows 95 cannot handle any Windows NT kernel calls, so avoid their use.
Spinlocks are nonfunctional in Windows 95. In debug builds, they are equivalent to an ASSERT, so they are useful as debug flags. In retail builds, spinlocks are completely ignored by the compiler.
Windows NT and Windows 95 handle EISA and MCA cards differently at initialization. The Windows NT registry handles all card IDs and slot registration. In Windows 95, the driver must contain the actual MCA card ID.
If your Windows 95 driver supports more than one type of MCA card, list the ID for each card in your source code. See the NE2000 or the IBMTOK samples for examples of MCA cards. Lists of EISA cards are no longer required.
For Windows 95, SLOTNUMBER is not needed within the Protocol.ini file. For EISA cards, Windows 95 relies on the Configuration Manager to tell NDIS what slot the card is in. For MCA cards, NDIS will scan all the slots looking for an ID that matches. SLOTNUMBER may be used for MCA cards if more than one of a given card is used in a computer and a way to differentiate the two is needed.
Windows 95 NDIS 3.1 drivers and miniports should be keyword compatible with existing equivalent NDIS 2 drivers. This is a change from the Windows NT model that is required for backwards compatibility with real mode (NDIS 2) drivers that may be running on the same Windows 95 computer.
In the Windows 95 model, it is possible to use two different keywords to refer to the same value (because the NDIS 2 keywords are written to the Protocol.ini, and the NDIS 3.1 keywords will be written to the registry). In practice, this should be avoided if possible, and (for purposes of maintaining compatibility with Windows NT NDIS miniport keywords) should only be used for the four resource types maintained by the system (InterruptNumber, IoBaseAddress, MemoryBaseAddress, and DMAChannel). In any case where the keywords are different, the values the keyword may take must be the same for both drivers.
Example from NETEE16..inf:
; Resources HKR,,InterruptNumber,1,04,00,00,00 HKR,NDI\params\InterruptNumber,resc,1,04,00,00,00 HKR,NDI\params\InterruptNumber,ParamDesc,,"Interrupt Level" HKR,NDI\params\InterruptNumber,flag,1,20,00,00,00 ; 0x20 = NDIS 3.1 only ;ndis2 HKR,NDI\params\ IRQ,resc,1,04,00,00,00 HKR,Ndi\params\ IRQ,ParamDesc,,"Interrupt Level" HKR,NDI\params\ IRQ,flag,1,10,00,00,00 ; 0x10 = NDIS 2 only
In this example, the resource is tied to the keyword InterruptNumber, which shows up only in the registry. The keyword IRQ will get written to the Protocol.ini. This sample would not work if the values for each keyword were different (for example, one looks for a hexadecimal number, the other looks for a string).
It is possible for either driver to have different, unique keywords (such as MAXMULTICAST), as long as this keyword is explicitly tagged as being NDIS 2 or NDIS 3.1 only.
When a keyword requires a parameter that is a small number (such as DMA channel or IRQ number), use decimal, not hexadecimal, numbers. An exception to this rule would be if an NDIS 2 driver uses hexadecimal, then the NDIS 3.1 driver must as well.
Use of this function is highly encouraged. For Windows 95, calls to this function provide users with a dialog box notifying them that an error occurred. In addition, information provided as part of the NdisWriteErrorLogEntry function is written to an error log file called Ndislog.txt.
Any troubleshooting documentation provided with the driver should list all error codes passed to this function. Because it is possible to uniquely number each call to NdisWriteErrorLogEntry, it should be relatively easy to design errors that isolate specific common installation and hardware problems.
It is mandatory that this function be used only in initialization code. Use of this function at any other time may cause unexpected results.
Due to limitations in NdisStallExecution, it is possible that calls to this function of greater than 100 microseconds could cause slower background serial data transmissions to drop characters. For calls of 10 milliseconds or less, Ndis.386 will suspend interrupts on the card by default, regardless of whether or not interrupts were explicitly turned off prior to the call.
Because of these characteristics, do not call this function longer than 100 microseconds. If a wait for a longer period of time is desired, create a timer loop with an NdisStallExecution(100) within the loop.
This functionality will be reevaluated in future versions of Windows 95. Using this technique will guarantee compatibility with any changes in the future.
To install the NDIS Netcard Driver Tester (TestProt), copy Nettpdrv.inf to the Inf subdirectory of your Windows directory, and copy the appropriate Tpdrvr.386 and Tpdrvr.sym to the System subdirectory of your Windows directory. Start Windows, and from the Network Control Panel, add the Microsoft NDIS Netcard Tester to your protocol list, binding it to the network card under test. Restart Windows, and Testprot will be ready to run.
This version of Testprot has been modified to meet the NDIS 3.1 addendum to the NDIS 3.0 spec, specifically to support the dynamic loading and unloading of media access control drivers. From the media access control developer's perspective, nothing has changed. This is a simple recompile of existing NDIS 3.0 sources with the new header files in this DDK. In addition, all NDIS function calls now use the standard calling convention, which is faster and allows binary compatibility with Windows NT 3.5 NDIS miniport drivers. The correct compiler flag to create standard calling convention components is included in the new Ndis.mk file.
The TestProt provided in this DDK may not fully support Arcnet or FDDI. The code is in, but has not been tested. TestProt also does not support QueryStatistics (which calls MacQueryGlobalStatistics). The test scripts included in this release contain support for this, but this support is disabled. This functionality will be provided in a future release.
For Token Ring testing, a cyclical test will require the packetsize variable be submitted as well. Current test functionality starts sending with packets set at the minimum packetsize, incrementing size by one up to packetsize. For Token Ring, packetsize is variable. Current scripts use 2028 as the max_frame_size, which is the minimum for the original IBM(r) 4MB Token Ring card. If the card under test has a different maximum packet size, set the max_frame_size accordingly. The corresponding log files will differ as well.
On Ethernet, one cyclical test will consist of 1459 packets. On Token Ring, one cyclical test will consist of 1987 packets (assuming a max_frame_size of 2028).
Stress testing in the TestProt environment can cause Windows 95 to do many strange things that are not real world. When running a test suite on a very fast computer, it is possible to get TestProt into a state that mimics driver failure. In any case where a script fails, rerun the specific failing script (for example, \1\2\3\1\5.tps) by itself after power cycling the computer. If the failure reproduces, then there is a genuine bug. In general, if TestProt crashes, Testprot.log and the Script.log files will probably be crosslinked. In these cases, run chkdsk to recover.
There is a new type of packetmakeup - ONE Buffer. A set of scripts can be created to add to the suite (window both on and off) that uses this, in order generate maximum stress on the card. For an example, using just such a stress test, the Ne3200.386 driver was able to peak out the theoretical maximum for Ethernet: 1000 packets/sec of 1514 bytes/packet.
When a stress test runs without the window on, the probability that one card may overflow the second card in the test increases. Use good judgment in choosing a set of cards for a given test. They should be matched for reasonably similar expected performance. If one card has a significant inherent architectural speed advantage, the other card in the test will be flooded and will not exercise good send/receive interaction. This is not poor design if the intent is to see how well a card performs under overwhelming stress. When packets are used from a pool, the throughput will increase as well. These factors will have an effect on the logs created, and they should be kept in mind when comparisons are drawn with the master logs.
Many of the speed differences between the Windows NT version of TestProt and the Windows 95 version are related to the Windows 95 version doing no memory allocations during the test if possible. Memory allocations are very expensive in Windows environments.
Because of the potentially large differences in expected and actual throughputs achieved by a card under test, the BETWEEN_VALUES parameters in the tps scripts may need to be modified. In general, for two evenly matched cards running without the window on and with packets from the pool, the second card (server in the stress test) should receive and echo back about 25 percent of all packets sent by the client. Likewise, when running the Acknowledgment (Ack) stress tests, the BETWEEN_VALUES may need to be examined to be sure that they are reasonable.