挣的比民工都少

看的比谁都好，
几年后下岗谁都跑不了

中国程序员现状大揭秘

不知道赶上了没？

喂，过分了吧？有人还这么管的啊。

我也要抢。

NetBIOS Enhancements

The Windows implementation of NetBIOS is based on the NetBIOS 3.0 specification. However, the Windows implementation includes the following enhancements that are not part of the NetBIOS 3.0 specification:

NetBIOS emulator manages resources separately per process. For example, the network name numbers are assigned on a per-process basis. Therefore, if a process issues the NCBRESET command, the names, sessions, and outstanding NCBs allocated for that process are cleared, but those of other processes are not affected. Also, requests for the status of the local adapter retrieve only the names that were added by the process making the request.

The NetBIOS emulator supports 254 sessions per process, per LANA number

You can supply an event in the ncb_event member of the NCB structure. This is not a standard NetBIOS 3.0 NCB member. The event is set to the signaled state when NetBIOS completes an asynchronous command. This method of issuing asynchronous commands is faster than using post routines and it uses fewer system resources. The system creates an event and a worker thread for each command that uses a post routine.

A process can enable extensions to the transport interface by using the NCBACTION command in the ncb_command member of the NCB structure. This is not a standard NetBIOS 3.0 command.

A process can enumerate all available LAN adapters by using the NCBENUM command in the ncb_command member of the NCB structure. This is not a standard NetBIOS 3.0 command.

A process is required to issue the NCBRESET command on each LANA number before it can issue any other NetBIOS command on the LANA number, with the exception of NCBENUM.

The NetBIOS 3.0 specification allows LANA numbers 0 and 1. The Windows implementation allows additional LANA numbers.

The value 1 for the ncb_num member of the NCB structure is not exclusive when the NCBRESET command is issued. All MS-DOS and 16-bit Windows-based applications also share access to NAME_NUMBER_1.

This chapter provides a roadmap to the Network Drivers Design Guide. It indicates which parts of this guide you\'ll need to read, based on the type of kernel-mode network driver you\'ll be writing.

Microsoft? Windows? 2000 supports three basic types of kernel-mode network drivers:

Miniport NIC drivers
A miniport driver directly manages a network interface card (NIC) and provides an interface to higher-level drivers.

Intermediate drivers

An intermediate protocol driver interfaces between upper-level protocol drivers, such as a legacy transport driver, and a miniport. A typical reason for developing an intermediate protocol driver is to perform media translation between an existing legacy transport driver and a miniport that manages a NIC for a new media type unknown to the transport driver.

Protocol drivers
An upper level protocol driver implements a TDI interface, or possibly another application-specific interface at its upper-edge, to provide services to users of the network. At its lower edge, this type of driver provides a protocol interface to pass packets to and receive incoming packets from the next-lower driver.

Another type of protocol driver is a connection-oriented call manager. A call manager provides call setup and tear-down services for connection-oriented clients, which are also protocol drivers.