The following sections describe differences in network drivers between Windows 95 and Windows for Workgroups.
If your media access control driver will have both an Windows NT and Windows 95 version, it is best to develop and perfect the Windows NT version first. Code written for Windows NT easily translates to Windows 95, but the reverse is not necessarily true. Maintaining a common source base for both environments is painless and encouraged. Of course, the easiest course of action is to write an NDIS miniport that will run the same binary on both platforms.
NDIS 3.1 drivers (not miniports) have changed extensions, from .386 to .vxd (for example, ne2000.386 is now ne2000.vxd). The Ndis.mk file included in this DDK will automatically build with this extension. The change is cosmetic, and the functionality has not changed. You could change the file names by using a simple file rename command at the command prompt. Make sure that your .inf files reflect this new naming convention. The reason for the naming convention is to distinguish Win95 drivers from Windows for Workgroups version 3.11 drivers.
Windows 95 drivers built by using Visual C++ version 2.0 may have problems with page faults under stress. By default Visual C++ version 2.0 places all code in the .text code segment which is Win32 pageable code. (Previous versions of the compiler placed code in the locked _LTEXT segment by default.) If the ISR, DPC, or other code is pageable and this code gets swapped under heavy stress, calls to these routines are lost. To lock down code that is not pageable, you can place a single pragma "LCODE" line in front of all .C files that do not already have a pragma "PCODE" or pragma "ICODE" in place. Always check the .map file for the driver to make sure the .text segment does not contain code that should be locked.
Interrupt 2 is the same as interrupt 9 in computers. For Windows 95, this is being enforced as a requirement of Configuration Manager. Unfortunately, most users don't know these two interrupts are the same, and many drivers require a 2 in the UI. We have added a flag that allows the system to carry a 9 internally, but it passes a 2 to Protocol.ini (for ndis2 drivers) and to NDIS 3.1 drivers. To make this work, you need to change all occurrences of interrupt 2 in your LogConfig sections (IRQConfig) to interrupt 9, then add the flag 0x40 to your interrupt keyword. The following is an example:
HKR,NDI\params\Interrupt,resc,1,04,00,00,00 HKR,NDI\params\Interrupt,ParamDesc,,"Interrupt Level" HKR,NDI\params\Interrupt,flag,1,50,00,00,00 ;0x40 - IRQ2/9 && 0x10 - NDIS 2 only
The ISAPNP, EISA, PCI, PCMCIA and MCA bus types are enumerated explicitly by Configuration Manager. (MicroChannel is not hardware enumerated at this time, but it is in this list in case this is added in future releases.) Because of this characteristic, Setup needs to handle manual installations of these cards differently than legacy ISA cards. Ideally, these cards should be installed by simply plugging the card in and turning the computer on. The system automatically detects the card and its configuration, and installs it. However, it is possible to manually install the device through the New Hardware or Net Setup Control Panel. Special code was added to handle this situation. In order to invoke this code, a keyword needs to be added to the .inf file for these cards. The keyword is CardType, and the options are PCMCIA, EISA, PCI, ISAPNP, or MCA. The following example illustrates it's use:
HKR,NDI,CardType,,"PCMCIA"
Look at the .inf files that are included with Windows 95 to get an idea of where you want to place this line.
From a Netcard driver perspective, there is no difference between a well-written NDIS 3.0 driver and an NDIS 3.1 driver. Sources from a driver compiled to run under Windows for Workgroups 3.11 can simply be recompiled under the Windows 95 DDK to take advantage of NDIS 3.1 functionality. There are no new driver functions in NDIS 3.1.
NDIS 3.1, for Windows 95, means the following:
If your NDIS 3.0 driver uses standard macro definitions from the samples, these macros have been redefined to fit the NDIS 3.1 dynamic loading/unloading scenario.
You should make all noncritical code pageable (typically Init and Removal/Unload code).
In NDIS 3.0, the protocol loads first, and all adapters are bound to the protocols. In Windows 95, the adapter is detected and opened by the Configuration Manager and the Wrapper first, and protocols are bound to the available adapters. As a result, OpenAdapter is no longer called from within the AddAdapter procedure. So, make sure no local variables are used to pass data between these two procedures.
The .inf file format is described elsewhere in this DDK. For network adapters, it is best to use the .inf files that ship with Windows 95 as samples (most files beginning with Netxxx.inf are for network adapters)
The following flags are defined for use in Windows 95 (similar to their definition in Windows for Workgroups 3.11):
0x08 | Query By Default (forces the UI to ask the user to choose a value) |
0x10 | NDIS 2 only |
0x20 | NDIS 3.1 only |
0x30 | Both NDIS 2 and NDIS 3.1 |
Example:
HKR,NDI\params\ RINGSPEED,flag,1,38,00,00,00 ; 0x10 = NDIS 2
; 0x20 = NDIS 3.1
; 0x08 = Query by default
Optional parameters remain unwritten to the registry or the Protocol.ini until they are selected by the user, and are defined like the following example:
HKR,NDI\params\RXBUFFERSIZE,optional,,1
Because of a need to be consistent with Windows NT guidelines, Memory Base Addresses should be absolute (not paragraph) addresses. This is a change from Windows for Workgroups 3.11 guidelines, mandated specifically because Configuration Manager for Windows 95 maintains only absolute addresses.
Example:
IOBASE=0xD0000 (not 0xD000)
If the NDIS 2 driver requires paragraph addresses, the following line may be added to the .inf file, and is only used for values written to the Protocol.ini:
HKR,NDI\params\RamAddress,paragraph,,1
Example:
HKR,NDI\params\RamAddress,resc,1,01,00,00,00 HKR,NDI\params\RamAddress,ParamDesc,,"Memory Base Address" HKR,NDI\params\RamAddress,paragraph,,1
In this sample, RamAddress would equal 0xD0000 in the registry, and would equal 0xD000 in the Protocol.ini