jb@TWG.ARPA.UUCP (10/30/87)
John Romkey's response to my posting about supporting TCP/IP on PS/2 came as a surprise. I only wanted to say that a microchannel driver was in the works and I certainly didn't mean to offend anyone. I'm sorry it went out like it did; it was my first posting on the net ever and the mailer got away from me. I hope I have better luck with this one. However, since John raised the point, I would like to clarify the relationship between Wollongong's WIN/PC product and PC/IP. Our first release back in 1985 was basicly a subset of PC/IP's applications with some user interface enhancements. Our current offering (version 3.0) is a mix of code and concepts developed here, taken from Berkeley Unix 4.2, and inherited from it's PC/IP roots. The Stanford code that was in our 2.0 release has been entirerly replaced. As we have replaced or reworked the various layers over the years we have preserved the interfaces between layers wherever possible to avoid having to rewite everything at once. This has resulted in a programming interface that looks very much like a superset of PC/IP's even though the underlying TCP was totally rewritten here by me over a year ago. Please don't let the apparent similarity to PC/IP mislead you into thinking it is PC/IP. Some aspects of WIN/PC's internal design survive virtually unchanged from PC/IP, such as the tasking package and the queueing system. Others, such as the packet buffer managment, have been sustantially enhanced for performance. Still others have been entirely replaced. An example of this last catagory is the interface to the hardware drivers. WIN/PC's applications are hardware independant executables which find and hook to driver code at runtime; due to recent interest on the net in this topic I will have more to say about it soon. Portions of some network layers or applications from PC/IP also survive in WIN/PC. Off the top of my head I can think of the customizer, parts of telnet (the actual telnet protocol code and handling of the F10 key & 25th line) and much of the internet layer. The PC/IP UDP code needed only to be ported to a DOS C compiler. However the FTP we sell is a port of Berkely 4.2 FTP to our own TCP layer. Our R-series applications are our own work based on Berkeley's designs. Our telnet features a Wollongong written vt100 emulator. All of our other applications use a programmable keyboard handler we designed. The SMTP mailer was entirly written here. All our device drivers (with the exception of parts of the 3COM 3c500) were written here with occaisional help from the Hardware manufacturers. The manual is a PC standard package and was written from scratch in-house; also the development environment is 100% DOS. Thus I think it's more accurate to say WIN/PC is a descendant of PC/IP than to say it IS PC/IP. I would also like to point out another major distinguishing feature of PC TCP products, both PC/IP-derived and otherwise: The throughput varies widely. While evaluating our FTP against the competition last spring I noticed some vendors' products were up to four times faster than others on the same hardware. (6Mz PC- AT clone w/3COM 3c501 and hard disk to/from a Sun III.) I would encourage users for whom speed is a concern to evaluate several products (including WIN/PC, of course) in their own environment. Lastly, I should mention that I would agree with John that most of the PC/IP descendants haven't really outreached their roots yet. However with lots of us working on memory resident code, Netbios, and sharable device drivers we are rapidly getting there. ------------------- John Bartas Project Leader, Software Engineering The Wollongong Group ------
ddl@HARVISR.HARVARD.EDU.UUCP (10/30/87)
As long as you brought this up, what exactly is necessary in order to legally port and distribute Berkeley network software to non-unix sites? What license must be obtained from Berkeley and at what cost and what must be done to convince AT&T that Berkeley code is not unix-derived? There are constant rumors that this code is freely distributable, but since Berkeley distributes only to unix source sites I can't quite see how... Dan Lanciani ddl@harvard.*