wjm 27-may-1997: NDFP V5.4.3 NDFP, the Network DOS File Protocol is intended to make a PC running DOS (or the like) into a file & disk (etc.) server. Featuring My Own Ethernet Protocol (MOEP) ... :-) Pieces included: - stand-alone PC server program sources [.PC], written in Borland Turbo PASCAL V6 - VMS client library & utility sources [.VMS...], written in C and very little MACRO Legal: Like any piece of software not marked otherwise, NDFP is implicitly copyrighted by its author. Seeing the paranoia (as it seems to me) that people have about PC software, I went into the trouble of including explicit copyright notes into all of [.PC]*.PAS, viz. Copyright (C) 1997 Wolfgang J Moeller. All rights reserved. NO WARRANTY! Nonetheless, this is a fun project, and not intended as a commercial offering, so for the time being, "License is granted to everyone to evaluate, modify, and use for non-commercial purposes the software contained within this ("NDFP") package. Non-commercial re-distribution permitted, provided it contains all of the original files, including the above copyright notice." If there's sufficient interest, I intend to put all of my material under the GPL, so keep telling me about your experiences & enhancements ... All of the files in the [.VMS.GCE-*] subdirectories, plus [.VMS]FQHOST-ND.MAR, are exempt from this conditions, being (mostly) the work of Glenn C Everhart; maybe they even are in the "public domain". Disclaimer: "Wolfgang J Moeller ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF HIS SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY Wolfgang J Moeller" In fact, there's pretty little such equipment :-) So far, my employer (GWDG), hereby acknowledged for permitting me to beta-test & distribute my software via their facilities, has little to do with NDFP, which is all "home-grown" in my spare time. Features: LAN-wide access to most of DOS's I/O facilities (files, directories, disks, pseudo-files like PRN), and the DOS system clock. Theoretically, an unlimited number of client nodes, with up to 255 client connections per node - the current implementation, however, imposes some much smaller (arbitrary & modifiable) limits. Virtually state-less server operation: the server program can be (orderly) terminated any time, and re-started later, without causing harm to clients. Optional access list protection, restricting access to the (PC) server to client computers with specified LAN addresses (*not* user-specific). All "synchronous" (non-overlapped) I/O. Moderate throughput - a Vs2000 talking to a 16 MHz 80386 will rarely reach 100 kb/sec; more recent hardware has been seen to attain more than 300 kb/sec ... Hardware requirements: "IBM compatible" PC with at least several hundred kilobytes of memory. Some PC "network card" with "DOS packet driver" support. Ethernet (or equivalent). One or more operational VMS systems with ethernet interface (or equivalent). Software requirements: A reasonably recent version of DOS (so far, I know nothing but MS-DOS 6.22 :-) DOS "packet driver" for the PC's network card. VMS V5 or later (approximately; VAX V5.3 .. AXP V6.2 have been tested). For building the PC software: Borland Turbo PASCAL for DOS, minimum of V6 ((anyone around with V7?)) For building the VMS software: C compiler as appropriate (VAX C V3.2, GNU C V2.7.1, DEC C) VMS "program development" subset :-) Optional hardware: PC floppy disks (maximum of 2) PC hard disks (maximum of 24 [?]) PC CD-ROM drives (maximum of ???) PC printer, ... VMS diskette drive (for duplicating floppies across the network :-) Optional software: SMARTDRV, Windows 3.x (plus WINPKT.COM), ... VMS virtual disks & tapes (cf. [.VMS...]000README.WJM) Installation & use: PC: Somehow transfer the .PAS sources in the [.PC] subdirectory to a PC with Turbo PASCAL V6 (a later version might work, but I haven't seen one yet) and compile them, e.g. by running MAKE5.BAT, resulting in ETHNDS5.EXE (in fact, you might find this executable already contained within the kit). In order to enable access list protection, edit PERMIT.XMP to contain the LAN addresses of permitted client machines; save by any name (e.g. C:\PERMIT.NDS), and have the DOS environment variable NDS_PERMIT point to it, e.g. SET NDS_PERMIT=C:\PERMIT.NDS If NDS_PERMIT isn't set, access will be completely "open". ETHNDS5 won't start while NDS_PERMIT points to an invalid or non-existing file. On the target PC(s), load the packet driver appropriate to their network card, and invoke ETHNDS5.EXE, like e.g. NE2000 0x78 ETHNDS5 Note: ETHNDS5 isn't a TSR. Sorry. In return, it uses the PC console (in fact, its standard output) to log some messages about files opened/closed, errors, etc. ETHNDS5 automatically locates the packet driver (just like KERMIT), provided the packet driver interrupt is in the "standard" range 0x60..0x7F. Terminate the server program (any time) by hitting the space bar (currently, any key not mentioned below will also do). Hit to have some packet driver statistics displayed, or hit "L" to enable/disable a comprehensive "transaction" logging. That's it! In case you want to try ETHNDS5 under Windows 3.x (it _seems_ to work there, but not much testing has been done), find WINPKT.COM somewhere (part of the "Crynwr packet driver collection" PKTD*.ZIP), and load it after the packet driver, prior to starting Windows, like NE2000 0x78 WINPKT 0x78 WIN Note: WINPKT seems to be unforgiving in that loading it twice makes the packet driver un-usable until next boot. I'm not aware of any "installation check" :-( ((anybody seen the source code of this beast???)) BTW, this is quite analogous to the setup required for running Trumpet Winsock TCP/IP over Ethernet. Maybe the two can even co-exist ... VMS: Compile the sources in [.VMS] via @MAKE-SHR @MAKE-UTIL resulting in NDFP_SHR.EXE (shareable "access" library) and a lot of ND_*.EXE executables. Define logical names NDFP_SHR (preferably system-wide), optionally NDFP_ETH_DEVICE (also system-wide), and NDFP_SERVER (any way you like), plus maybe DCL symbols for the execuatbles. See [.VMS]SETUP.COM for an example. Find some more information, plus some more things that you can "MAKE", in [.VMS...]000README.WJM . Somehow get hold of SYSLCK privilege - the programs will not run without it! See you system manager :-) Beginner's example: $ define NDFP_SHR dev:[dir]NDFP_SHR.EXE $ define NDFP_ETH_DEVICE ESA0: ! name of ethernet device ... $ set process/priv=SYSLCK ... $ define NDFP_SERVER 00-11-22-33-44-55 ! PC's LAN address $ mcr dev:[dir]ND_DIR-R C: Limitations etc.: - This version of NDFP uses Ethernet protocol type 60-06 ("reserved to DEC customers"). It seems that a private protocol type is hard to come by these days, although only a very small fraction of the ~60k possible types are generally known to be used. Donations welcome! BTW, if you have to, locate & modify "($60,$06)" in [.PC]ND_CONST.PAS "0x6006" in [.VMS]NDFP_PROTO.H - there are NO provisions made for file sharing among clients of a NDFP server, and nothing in the software is aware of the fact that all of DOS files, disks, and "drives" in fact refer to the same set of data. BE CAREFUL! (Non-overlapping disks and logical drives can be shared, *provided* clients synchronize accesses among themselves. I'm experimenting with 5.5-2 VAXcluster disk sharing - seems to work with slightly modified pseudo-disk drivers. Contact me for details) - access control based on LAN addresses alone isn't exactly optimum. User-based security via encryption (or so) would be nice - if it wasn't for my SLOW home machines, I might even have started thinking about it... - probably more that I'm not aware of (still waiting for BETA test reports!). Wolfgang J Moeller, (preferred), and also