Re: NOS for DJGPP...
- To: TCP-Group@ucsd.edu
- Subject: Re: NOS for DJGPP...
- From: email@example.com (Mike Bilow)
- Date: Wed, 26 Apr 95 22:47:00 -0000
- 29: 25 -0700
- Reply-to: firstname.lastname@example.org
Russell Nelson wrote in a message to Mike Bilow:
RN> No, I'm serious Mike. I bought the software from Clarkson,
RN> and they asked me not to call them the Clarkson Packet
RN> Drivers. They've already threatened to sue other people
RN> infringing on the Clarkson trademark, so I'm sure they're
RN> serious about it.
RN> They're the Crynwr Packet Driver Collection.
I did not know the history. I was aware of the change, but I was unaware of
the circumstances. I'll be careful on this in the future. I guess I just got
used to saying "Clarkson." I still say "kilocycles" on occasion, too.
RN> DJGPP has packet driver support already built into its DOS
RN> extender. The Crynwr packet drivers work just fine with DJGPP.
RN> My understanding was that this imposes constraints of some
RN> kind on the packet driver, and that it must be written so that
RN> it will work with Windows, DJGPP, or some DPMI system running
RN> on top of it. In other words, my understanding is that some
RN> packet drivers will work, but others may not. Is this wrong?
RN> Yes, this is wrong. Anything that goes through DPMI to
RN> access packet drivers (which DJGPP will do) will work over
RN> any packet driver.
That's interesting. Why do some packet drivers require a special argument to
support running Windows above them? So the packet driver need not be able to
respond to multiplex broadcasts using Int 2Fh?