martino@logitek.co.uk (Martin O'Nions) (02/27/91)
There's been a couple of posts recently relating to the use of alternative
LAN driver schemes for use with Novell's NetWare; so far as I am aware, the
current position is as follows.
NetWare servers will only use Novell's own driver scheme - the operating
system runs in protected mode on the 286/386/486 chip, with its own conventions
for call mechanisms, multi-tasking etc., and consequently DOS based schemes
will not work.
The packet driver scheme can be used on DOS workstations, because of the
provision of an IPX driver stage which talks to the packet interface, rather
than directly to the card hardware. This allows ready interoperation of IPX
and TCP/IP or other protocols.
This technique is not directly compatible with Novell's ODI standard,
introduced with 3.0 NetWare, as the driver stage is different to that supported
by the packet IPX, but this does not restrict access to NetWare 386 servers -
it merely means that some of the new driver features are unavailable.
Novell have stated a number of times that they regard ODI as the way ahead,
and refuse to make use of the NDIS specification in their standard releases.
It is possible that this rule may be compromised by the forthcoming NetWare
over OS/2, but I have no information on this issue at this time.
There are however manufacturers who are producing IPX->NDIS drivers in much
the same vein as that available for the packet drivers. Typical of these is
3Com, with the Connectivity for NetWare product, designed for multiprotocol
workstations, and now bundled with their TCP/IP product.
If anyone out there would like to expand on this, I'm always interested in
new info. (or corrections........).
Martin
P.S. Novell's comment on the one-sided NFS release is that it is designed
to permit Unix client access, and is consequently more like the Macintosh
support, where the server mimics the client's native networking system,
than a full integration tool. Roll on phase II.
--
DISCLAIMER: All My Own Work (Unless stated otherwise)
--------------------------------------------------------------------------
Martin O'Nions Logitek Group Support martino@logitek.co.uk
--------------------------------------------------------------------------
Auntie did you feel no pain / Falling from that willow tree?
Could you do it, please again / 'Cos my friend here didn't see.
(Harry Graham - Ruthless Rhymes for Heartless Homes)keith@ca.excelan.com (Keith Brown) (03/06/91)
The News Manager) Nntp-Posting-Host: ca Reply-To: keith@ca.excelan.com (Keith Brown) Organization: Novell, Inc. San Jose, California References: <martino.667648784@krypton> Distribution: comp Date: Tue, 5 Mar 1991 23:09:10 GMT In article <martino.667648784@krypton> martino@logitek.co.uk (Martin O'Nions) writes: >This [the packet driver] technique is not directly compatible with Novell's >ODI standard, Although it is not directly incompatible with it either! The ODI is more of a "true" link layer API than either the PD or NDIS/APIs. It understands link encapsulation protocols and does a very good job of concealing them from overlying protocol implementations. A good example of the value provided by an interface such as the ODI can be found in our new version of The LAN WorkPlace for DOS (our TCPIP product for DOS PCs, which uses the ODI). It contains a single binary TCPIP.EXE TSR which is capable of running over Ethernet, Token Ring and Arcnet medias. All you have to do is switch the underlying ODI driver to support the hardware/media combination that you have. There is no overhead in the TCPIP.EXE to support all these medias. The media support is down in the ODI driver. This is in contrast to DOS TCPIPs that use the packet drivers. They have to ship different TCPIP TSRs for each media that they support (thats how they avoid overhead). I'm not implying one way is better than the other of course. It really amounts to two different ways of accomplishing the same end. Personally, I leave my own prayer mat in a locker at the temple of the ODI. Some leave theirs in the temple of the Packet Driver across the street. The vast majority of our customers don't go to church, they just want to get useful work done! >by the packet IPX, but this does not restrict access to NetWare 386 servers - >it merely means that some of the new driver features are unavailable. Specifically, the packet drivers don't allow you to use IPX over a couple of encapsulations that we support through the ODI. Packet driver users tend to run IPX on Ethernet II ("ECONFIG"d in NetWare 286 parlence). The support for "traditional" IPX on raw 802.3 is a little untidy within the PDs. In fact Russ Nelson, the Arch Deacon at the temple of the Packet Driver, forgot to lower his undercarriage while trying to land the IPX/802.3 support in release 8.0 of the things. I believe he's rushing for the fire extinguishers even as I type. > >Novell have stated a number of times that they regard ODI as the way ahead, >and refuse to make use of the NDIS specification in their standard releases. As I've stated in previous postings, an ODI driver for the NDIS "board" isn't a completely stupid idea. Niether is one for the PDs. The ODI adds value on top of both of these pieces of software and so an ODI driver for NDIS would in fact be more than a worthless converter "kludge" sitting taking up memory. Maximum performance would usually be obtained via a "straight to the metal" ODI driver, but producing ODI drivers for NDIS and the PDs might appease worshippers at the other temples and prevent a holy war breaking out. > >If anyone out there would like to expand on this, I'm always interested in >new info. (or corrections........). Are you joking? This is one of my favorite subjects! >P.S. Novell's comment on the one-sided NFS release is that it is designed >to permit Unix client access, and is consequently more like the Macintosh >support, where the server mimics the client's native networking system, >than a full integration tool. Roll on phase II. We already have two ways of providing transparent file services from DOS PC's to UNIX systems. One is called Portable NetWare and the other is to use the LAN WorkPlace for DOS in conjunction with Beame and Whitesides NFS client software for our transports. You want another? Jees, some people are never happy :-) Keith - Keith Brown Phone: (408) 473 8308 Novell San Jose Development Centre Fax: (408) 433 0775 2180 Fortune Dr, San Jose, California 95131 Net: keith@novell.COM