RE: Catapult

[Russ <Russ . Cooper @ RC . Toronto . on . ca>]

Ken Hardy said...
>"Standard or not (it is), WinSock is an API (originating outside of MS,BTW),
not a protocol."

Russ replied...
"The Windows Sockets project had its origins in a Birds Of A Feather
session held at Interop '91 in San Jose on October 10, 1991. A committee
was established, and an intensive debate via email resulted in the
creation of a first draft specification, which was largely based on
submissions from JSB and NetManage. This draft, and issues arising from
it, were debated at a committee meeting hosted by Microsoft in Redmond,
WA on December 9, 1991. Following further email discussions, a working
group was established to develop the specification into its current
form." ... quoted from the Official Winsock 1.1 specification.

Of the 5 official copyright owners, 2 were/are Microsoft employees at
the time the specification was completed.

As an example of Microsoft's commitment to developer API's, NT 4.0
implements the Winsock 2.0 API, yet Catapult, which runs on NT 4.0, was
implemented with full Winsock 1.1 support (lowest common denominator). I
think its also unreasonable to use Microsoft's implementation of any
Winsock-based package as an example of their attempt to proprietize said
API. Given the amount of support that Microsoft have given to this
specification, and its wide-spread use throughout their OS environments,
clearly they have been supporting this "open" specifications for years
now.

Ken Hardy also said...
"If Catapult is offering something "Socks-like", but not socks, I'd like
to know what its advantages are.  Does it, e.g., work with non-IP
clients, as do various 3rd party ipx/ip gateways?"

Russ replied...
Yes, as you already pointed out, WinSock supports any underlying
transport protocol as long as a WinSock interface is available in the OS
(i.e. any protocol supported by a Microsoft Windows environment).
IPX/SPX clients, or NWLink clients in an NT world, are supported.

Ken Hardy finally said...
>"That would justify a proprietary implementation, perhaps, but would not be
>incompatible with parallel support for Standard Socks TCP clients."

Given that WinSock is specifically designed to implement BSD Sockets in
a Microsoft Windows environment, anything that Microsoft does to
implement the of remoting WinSock applications will be proprietary to
the Microsoft Windows environment due to the nature of the API in
question. So any statements about RWS being proprietary are completely
true, since WinSock is proprietary to the Microsoft Windows environment.
As long as Catapult fully supports the WinSock 1.1 API Specification,
the openness of the specification is preserved. How Microsoft does that
is irrelevant to API programmers (the security of this is a different
issue).

In other words Ken, beyond Microsoft bashing, what's your point??

Cheers,
Russ
...due to licensing restrictions, this message can only be read by 10
people within 10 minutes...
>