This is a proposed enhancement of Bill Paul's ndis emulator for running
WiFi 64-bit drivers for Windows on OpenIndiana.

It has only been tested with Broadcom drivers for Windows complying with
the NDIS5 interface. Drivers for the more recent NDIS6 interface will
not install.

Currently, only WEP encryption is available (no WPA support).

To build the driver and emulator, apply the procedure described in the
bcm4312.html file. You will however probably have to adjust it your specific
building tools.

Please report about the changes you have had to make for your own
configuration.

The driver has only been used by few people on few different computer
models, so bad behavior, and even system panic may still occur. If you
get into such situation, you may help by sending the register dump
and backtrace associated with the id and location of the driver. You
will find this in /var/adm/messages, with the id and location of the
driver looking like (both lines needed).

ndisapi Mar 17 2013 at 0xfffffffff88cb000, curSC at 0xffffffffc0339358          
bcmndis Mar 17 2013 at 0xfffffffff8db4000 ndis_m_callbacks at 0xffffffffc0282fb8

Thanks to all who helped, in particular to Jim Klimov who did the initial
testing and helped establishing the procedure.

Enjoy,

Jean-Pierre

===== rc1, Apr 22, 2013

The ndis emulator has been upgraded to meet the requirements for more
recent releases of the Broadcom Windows driver. The releases below are
known to work with at least one hardware model. You can get the vendor
and device identification of your wireless device by issuing the command
"scanpci -v" and looking for the device supporting "802.11".

Version 4.170.25.12, September 21, 2007
(from Dell R174291.exe)

Vendor 14E4 device 4311
Vendor 14E4 device 4312
Vendor 14E4 device 4315 (tested)
Vendor 14E4 device 4318
Vendor 14E4 device 4319
Vendor 14E4 device 4320 rev 03
Vendor 14E4 device 4324 rev 03
Vendor 14E4 device 4328

Version 4.170.77.3, March 22, 2008
(from HP sp39912.exe)

Same as above, plus :

Vendor 14E4 device 4307
Vendor 14E4 device 432B

Version 5.60.350.6, March 23, 2010
(from HP sp48616.exe)

Same as above, plus :

Vendor 14E4 device 4353
Vendor 14E4 device 4357
Vendor 14E4 device 4727 (tested)

===== beta6, Mar 26, 2013

This is based on ndis-1.2.6 and solves the issues below when running
on a 64-bit OpenIndiana kernel. Several minor issues were also fixed,
but there is no new feature.

- issue 1 : the Windows driver is linked at run-time
   The ndis emulator is linked at build-time with a binary image of the
   Windows driver. In order to create the links, the driver image was
   copied at run time to a zalloc'ed memory. As a consequence the copy
   needed to be executable, which AFAIK is sometimes not possible (at
   least for functions triggered by timers.)

   Work around : dissociate the driver code from its variables and only
   dynamically allocate the variables and the indirect pointers to
   external code (i.e. the ndis emulator). By dissociating code and
   variables, linking at build time became possible (along with type
   checking at compile time.)

- issue 2 : the Windows driver makes use of multimedia registers (xmm)
   The multimedia instructions "movaps" and "movdqu" were used to
   optimize memcpy(), but are not allowed in an OpenIndiana driver.

   Work around : patch the multimedia instructions at build time.

- issue 3 : a few emulation functions were called directly with a
   Windows ABI. This mostly happened for indirect calls, when a
   pointer to a function was set in a structure within the Windows
   driver.

   Work around : make a strict typing of emulation functions, detect
   the wrong ABIs at compile time, and fix them.

- issue 4 : a few generic Windows wrapper functions did not reserve 32
   bytes on the stack.
   When these 32 bytes are not needed to save arguments passed in registers,
   they can be used in the Windows driver for local variables, and if the
   space is not reserved, the return pointer is overwritten with obvious
   consequences.

- issue 5 : the layout of a few structures did not match the Windows
   driver ones.
   This was somewhat expected because the alignment rules are compiler
   and OS specific. More surprisingly, in at least one case, the Windows
   driver wanted a structure different from what is described on msdn.
   Maybe the structure has been shortened since it was used to compile
   the driver.

