Soo... Bryan, here's a cooked download: http://frantisek.rysanek.sweb.cz/FD_NET.zip Download the ZIP and try to read your way through the readme files included.
Note that a copy of this message goes to the mailing list. I am hereby guilty of redistributing binaries from a couple different sources - if anyone feels offended, please complain to me and I will withdraw that ZIP immediately. Over the last few days, I've found a few moments to play with the MS Network Client, E1000.dos from Intel, the dis_pkt.dos v1.11 and mTCP. I ended up trying it all in a VirtualBox, where the emulated Intel Pro 1000 actually has the same PCI device ID :-) as Bryan's physical PC... I did that in a physical LAN where I have access to a Linux machine running Samba, configured to support the ancient version of the SMB protocol and a handful of DOS-related configuration features. I have "structured" the results of my effort into two directories: 1) one geared for "the way of the pure CRYNWR packet driver", prepared for mTCP. You can try sending something to your printer using "NC", but I doubt that the GDI thing would respond to e.g. plain ASCII. 2) another directory, centered around the MS Network Client (which can optionally have the packet driver shim loaded too). This should allow you to map a local LPT device in DOS to a MS Network shared printer (served by Samba on a Linux box). Which looks transparent to well-behaved DOS apps, and can be leveraged for a further on-the-fly processing of the print job in software on the Linux machine. Either variant allows you to learn the IP addresses obtained by the DHCP client and to ping other machines in the local network - which is a good starting point / introductory lesson into TCP/IP networking on your DOS machine :-) For the MS network client, I have taken "major inspiration" from the NetBootDisk 6.5. I've toyed with this before, and today I have just unpacked its ramdisk onto my virtual C drive, let it boot, and took the resulting system.ini and protocol.ini that the set of scripts produced :-) Also the sequence of loading the various binaries comes from the NBD. I just minimized the set of binaries required and de-modularized the original flexible "loading sequence" of the NBD. I have managed to get a plain ASCII text file printed on a decade old multifunction LaserJet (1522 if memory serves), through my "printing infrastructure". The hand-over point from DOS to the first downstream print queue is "LPT2:" mapped by "net use ..." to a queue advertised by Samba on Debian 9. Samba takes the queue definitions from a local /etc/printcap, and some LPR follows up from there. I believe the plain ASCII file has reached the printer without any modification. In your use case Bryan, my "package of canned DOS drivers" is just a first half of the needed configuration. Next up, we need to configure Samba and CUPS to transport and transform your print jobs :-) It would be easiest for me to just log into your Linux box, but that has some non-trivial prerequisites, such as a mapped port from your router's NAT outside (or a TeamViewer install on the Ubuntu box) and a fair bit of trust between the two of us, because letting me in your living room is a hefty security hole. Details should better be discussed in private messages, for security reasons. Alternatively, I can try sending you a minimal smb.conf and some instructions on how to install Samba on Ubuntu. That, for a start. Then we'd need to figure out the queueing magic in CUPS. I don't have much experience with advanced CUPS sorcery, but in the older days I've read about automagical "queue filters" that could auto-detect the data format of the print job being supplied by the client, and transform the job accordingly to suit the printer... I dare not hope for all that intelligence in this case, but I mean to say that various magical things are theoretically possible :-) Frank _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
