1. What is Windows Sockets?
Answer: The Windows Sockets specification defines a network programming
interface for Microsoft Windows which is based on the "socket" paradigm
popularized in the Berkeley Software Distribution (BSD) from the University
of California at Berkeley. It encompasses both familiar Berkeley socket
style routines and a set of Windows-specific extensions designed to allow
the programmer to take advantage of the message-driven nature of Windows.
The Windows Sockets Specification is intended to provide a single API to
which application developers can program and multiple network software
vendors can conform. Furthermore, in the context of a particular version
of Microsoft Windows, it defines a binary interface (ABI) such that an
application written to the Windows Sockets API can work with a conformant
protocol implementation from any network software vendor. This
specification thus defines the library calls and associated semantics to
which an application developer can program and which a network software
vendor can implement.
Network software which conforms to this Windows Sockets specification will
be considered "Windows Sockets Compliant". Suppliers of interfaces which
are "Windows Sockets Compliant" shall be referred to as "Windows Sockets
Suppliers". To be Windows Sockets Compliant, a vendor must implement 100%
of this Windows Sockets specification.
Applications which are capable of operating with any "Windows Sockets
Compliant" protocol implementation will be considered as having a "Windows
Sockets Interface" and will be referred to as "Windows Sockets
Applications".
4. Where can I get a/the WINSOCK.DLL?
Answer: You can most probably get one from the same place you got your
TCP/IP software from.
5. Why isn't there just one WINSOCK.DLL? Do I need a TCP/IP already
to use it?
Answer: The Windows Sockets specification defines the top level of the DLL,
the part which is called by user programs. The method a given WINSOCK.DLL
will use to access TCP/IP (or NetWare, or AppleTalk, or DECNet ...) depends
on the networking package you have installed, and therefore must vary. A
WINSOCK.DLL is therefore just an interface to whatever existing protocol
you already have installed. An illustration would help:
+---------------------------------+
| WinSock compliant application |
+---------------------------------+
+---------------------------------+ <--- WinSock API
| Windows Sockets DLL |
+---------------------------------+
+---------------------------------+ <--- Protocol Stack API
| Protocol Stack (e.g. TCP/IP) | (typically proprietary)
+---------------------------------+
+---------------------------------+ <--- Hardware Driver API
| Hardware Driver | (Packet Driver, NDIS, ODI,
+---------------------------------+ or proprietary)
+---------------------------------+ <--- Hardware Interface
| Network (hardware) Interface | (hardware specific)
+---------------------------------+
|
+----> network
6. Where can I contact Windows Sockets application and implementation
vendors? (include list of address, phone contacts)
Answer:
Date: Tue, 6 Apr 93 12:53:37 PDT
From: tang@documentum.com (Bill Tang)
To: winsock@Microdyne.COM
Subject: vendor list (long)
Thanks to all that responded to my previous inquiry of vendor
implementations. I am posing a summary and will keep the list updated
if I receive more information.
-------------------------------------------------------------------------
SUMMARY
-------------------------------------------------------------------------
(old list at 11/23/92)
Company BETA FINAL Update (4/6/93)
-------------------------------------------------------------------------
3Com Corp Q1'93 Q2'93 ?
Beame & Whiteside ? ? ?
Crucial Software Beta Q2'93, Final Q2 or Q3'93
Distinct Corp Q3'92 Shipping ?
FTP Software Q4'92 Shipping shipping v1.1 TCP/IP stack
with DLL; DLL
available on BBS or
anonymous-ftpable on
vax.ftp.com;
Development Kit being
updated to include
v1.1 Windows Sockets
support.
Frontier Tech Q3'92 Shipping ?
IBM Q4'92 Q1'92 ?
JSB Corporation Q4'92 Q4'92 ?
Lan Design Q4'92 Q1'93 ?
Lanera Corp Shipping v1.1 TCP/IP stack
Microdyne Q4'92 Q1'93 ?
Microsoft(W NT 32b) Q3'92 Q2'93 Win32 SDK March release
Microsoft(W NT 16b) Q4'92 Q2'93 Win32 SDK March release
Microsoft(W 3.x 16b) Q4'92 Q2'93 ?
NetManage Q4'92 Q4'92 shipping v1.1 DLL
Network Research ? ? ?
Novell ? ? ?
Spry (stack) supports Winsock v1.1
Sun Microsystems Q4'92 1stHalf'93 ?
Ungermann Bass ? ? v1.1 TCP/IP stack and DLL:
Beta Q1'93, Final Q2'93
Walker Richer Quinn Q4'92 Q1'93 ?
Wollongong Q4'92 Q1'93 ?
7. Where can I get sample applications and tests?
Answer: Files and information related to the Windows Sockets API are
available via FTP (user: "anonymous", password: your e-mail address) on the
host SunSite.UNC.EDU, in /pub/micro/pc-stuff/ms-windows/winsock, which is a
mirror of /pub/winsock on Microdyne.COM (SunSite has a much faster
connection to the Internet, so you are advised to use that). Note: if you
do not have FTP access to the Internet, send a message with the word "help"
in the body to either ftpmail@SunSite.UNC.Edu, or ftpmail@DECWRL.DEC.Com
(in the UK mail to ftpmail@doc.ic.ac.uk), to obtain information about the
FTP to Mail service there.
8. Will Windows Sockets be in _____?
8.1. Will Windows Sockets be in Windows NT?
Answer: Yes. In 16 and 32-bit versions.
8.2. Will Windows Sockets be in Windows for Workgroups?
Answer: Yes.
8.3. Will Windows Sockets be in DOS?
Answer: Paul Brooks of TurboSoft (paul@abccomp.oz.au) tells me:
As for a Windows Sockets for DOS - we have a library that is
pretty much complete. The goal was to produce a DOS library and
Binary API which would allow developers to code applications using
the Windows Sockets 1.1 spec. and have it run exactly the same
under DOS as Windows - blocking and non-blocking modes,
Asynchronous calls, the works. Apart from some AsyncGetXXXbyYYY
calls the rest works, although it is not possible to capture all
the Windows-specific semantics of some areas.
I am sure you can contact him for more information. JSB also has a
standardized Berkeley Sockets API for DOS which provides access to all
TCP/IP implementations.
8.4. Will Windows Sockets be in UNIX?
Answer: Well, since it came from BSD UNIX, there's not much need.
8.5. Will Windows Sockets be in Win32-S?
Answer: I think so.
9. What about standard APIs for ____?
9.1. What about standard APIs for FTP?
Answer: Not yet.
9.2 What about standard APIs for Telnet?
Answer: Not yet.
9.3 What about standard APIs for SNMP?
Answer: In the works. Send e-mail to winsnmp-request@Microdyne.COM to join
the list.
9.4 What about standard APIs for RPC?
Answer: Microsoft will be providing an implementation of DCE RPC. Also in
the works is the definition of a standard implementation of ONC RPC (known
as RPC for Windows) which will be made available by multiple vendors. To
contribute to the discussion, send email to rpc4win@wco.ftp.com.
9.5 What about standard APIs for TLI/XTI?
Answer: No, not yet. Vendors chose to do Windows Sockets because of the
sockets application and knowledge base, however anyone out there is free to
try a Windows TLI/XTI Specification.
10.1. Does Windows Sockets work over protocols other than TCP/IP?
Answer: Yes, it does. But we know of no vendors supplying one currently.
10.2. Will it?
Answer: Yes. Windows NT will include mechanisms for multiple protocol
support in Windows Sockets, both 32-bit and 16-bit.
11. Why no SOCK_RAW?
Answer: SOCK_RAW is optionally implemented by many major Windows Sockets
vendors. It is not mandated now because: 1) not every stack vendor can
supply a complete SOCK_RAW interface, and 2) we did not have time to define
the minimal subset every vendor could provide (e.g. maybe just ICMP).
12. Why isn't it possible to share sockets between tasks?
Answer: The real answer is that it wasn't considered sufficiently important
for 1.1, but is high on the list for inclusion in 2.0.
13.1. How do I get my IP address?
Answer: Do a gethostbyname() on the output from gethostname().
13.2. Why no SIOCGIFADDR?
Answer: It was not included because there were concerns it could not be
supported across platforms. It may be included in version 2.0 of the spec.
14. When should I use blocking vs. non-blocking sockets?
Answer: Try to use non-blocking sockets whenever possible; certainly if you
are coding a Windows application from scratch. Blocking sockets should
only be used when trying to maintain portability between UNIX/MS-DOS and
Windows.
15. What about other socket options that BSD supports? Ioctls?
Answer: Some vendors may support them. Do not rely on ones not explicitly
mentioned in the specification, however.
16. How can I get the local username?
Answer: No can do from Windows Sockets. Win32 (e.g. NT) has an API,
GetUserName(), for it, but there is no generic mechanism in Win 3.1.
17. Do I need to initialize the WSAData structure before calling
WSAStartup?
Answer: No, WSAStartup does not retrieve the contents of the WSAData
structure pointed to, it fills it in.
18. If I write a Windows Sockets program, will I be able to communicate
with a Sockets program on UNIX or any other non Windows platform?
Answer: This common question is the result of confusing protocols with the
APIs; communicating programs need not have been created with the same APIs,
as long as they are using the same (transport & network) protocols.
19. Is it possible to create sockets that map to a dll rather than an
application? I have tried a WSAStartup() as part of my LibMain, but the
sockets that are created are owned by the application, not by the DLL. It
would be desirable for me to have some of the sockets that are opened have
"A Global (DLL wide) Scope".
Answer: The way this situation has been dealt with by developers is to have
your DLL create a "helper process" which will perform all Windows Sockets
operations on behalf of your applications (thereby having all sockets owned
by the helper process' task).
20. A *Class* of questions that could be answered are related to porting
extant BSD applications to Windows Sockets: "How to I implement the xxxx
function call in my Windows Sockets application?" (e.g. fcntl(), readv(),
etc).
Answer: In general, you will have to code such functions yourself, although
it would not hurt to suggest them for the next revision of the
specification as well.
21. Is there a Pascal/Visual Basic/Visual Cobol header file for Windows
Sockets?
Answer: The Pascal form is already in the FTP archive. Look there for any
other header files that people may have developed so far.
Answer: The Windows Sockets specification defines a network programming
interface for Microsoft Windows which is based on the "socket" paradigm
popularized in the Berkeley Software Distribution (BSD) from the University
of California at Berkeley. It encompasses both familiar Berkeley socket
style routines and a set of Windows-specific extensions designed to allow
the programmer to take advantage of the message-driven nature of Windows.
The Windows Sockets Specification is intended to provide a single API to
which application developers can program and multiple network software
vendors can conform. Furthermore, in the context of a particular version
of Microsoft Windows, it defines a binary interface (ABI) such that an
application written to the Windows Sockets API can work with a conformant
protocol implementation from any network software vendor. This
specification thus defines the library calls and associated semantics to
which an application developer can program and which a network software
vendor can implement.
Network software which conforms to this Windows Sockets specification will
be considered "Windows Sockets Compliant". Suppliers of interfaces which
are "Windows Sockets Compliant" shall be referred to as "Windows Sockets
Suppliers". To be Windows Sockets Compliant, a vendor must implement 100%
of this Windows Sockets specification.
Applications which are capable of operating with any "Windows Sockets
Compliant" protocol implementation will be considered as having a "Windows
Sockets Interface" and will be referred to as "Windows Sockets
Applications".
4. Where can I get a/the WINSOCK.DLL?
Answer: You can most probably get one from the same place you got your
TCP/IP software from.
5. Why isn't there just one WINSOCK.DLL? Do I need a TCP/IP already
to use it?
Answer: The Windows Sockets specification defines the top level of the DLL,
the part which is called by user programs. The method a given WINSOCK.DLL
will use to access TCP/IP (or NetWare, or AppleTalk, or DECNet ...) depends
on the networking package you have installed, and therefore must vary. A
WINSOCK.DLL is therefore just an interface to whatever existing protocol
you already have installed. An illustration would help:
+---------------------------------+
| WinSock compliant application |
+---------------------------------+
+---------------------------------+ <--- WinSock API
| Windows Sockets DLL |
+---------------------------------+
+---------------------------------+ <--- Protocol Stack API
| Protocol Stack (e.g. TCP/IP) | (typically proprietary)
+---------------------------------+
+---------------------------------+ <--- Hardware Driver API
| Hardware Driver | (Packet Driver, NDIS, ODI,
+---------------------------------+ or proprietary)
+---------------------------------+ <--- Hardware Interface
| Network (hardware) Interface | (hardware specific)
+---------------------------------+
|
+----> network
6. Where can I contact Windows Sockets application and implementation
vendors? (include list of address, phone contacts)
Answer:
Date: Tue, 6 Apr 93 12:53:37 PDT
From: tang@documentum.com (Bill Tang)
To: winsock@Microdyne.COM
Subject: vendor list (long)
Thanks to all that responded to my previous inquiry of vendor
implementations. I am posing a summary and will keep the list updated
if I receive more information.
-------------------------------------------------------------------------
SUMMARY
-------------------------------------------------------------------------
(old list at 11/23/92)
Company BETA FINAL Update (4/6/93)
-------------------------------------------------------------------------
3Com Corp Q1'93 Q2'93 ?
Beame & Whiteside ? ? ?
Crucial Software Beta Q2'93, Final Q2 or Q3'93
Distinct Corp Q3'92 Shipping ?
FTP Software Q4'92 Shipping shipping v1.1 TCP/IP stack
with DLL; DLL
available on BBS or
anonymous-ftpable on
vax.ftp.com;
Development Kit being
updated to include
v1.1 Windows Sockets
support.
Frontier Tech Q3'92 Shipping ?
IBM Q4'92 Q1'92 ?
JSB Corporation Q4'92 Q4'92 ?
Lan Design Q4'92 Q1'93 ?
Lanera Corp Shipping v1.1 TCP/IP stack
Microdyne Q4'92 Q1'93 ?
Microsoft(W NT 32b) Q3'92 Q2'93 Win32 SDK March release
Microsoft(W NT 16b) Q4'92 Q2'93 Win32 SDK March release
Microsoft(W 3.x 16b) Q4'92 Q2'93 ?
NetManage Q4'92 Q4'92 shipping v1.1 DLL
Network Research ? ? ?
Novell ? ? ?
Spry (stack) supports Winsock v1.1
Sun Microsystems Q4'92 1stHalf'93 ?
Ungermann Bass ? ? v1.1 TCP/IP stack and DLL:
Beta Q1'93, Final Q2'93
Walker Richer Quinn Q4'92 Q1'93 ?
Wollongong Q4'92 Q1'93 ?
7. Where can I get sample applications and tests?
Answer: Files and information related to the Windows Sockets API are
available via FTP (user: "anonymous", password: your e-mail address) on the
host SunSite.UNC.EDU, in /pub/micro/pc-stuff/ms-windows/winsock, which is a
mirror of /pub/winsock on Microdyne.COM (SunSite has a much faster
connection to the Internet, so you are advised to use that). Note: if you
do not have FTP access to the Internet, send a message with the word "help"
in the body to either ftpmail@SunSite.UNC.Edu, or ftpmail@DECWRL.DEC.Com
(in the UK mail to ftpmail@doc.ic.ac.uk), to obtain information about the
FTP to Mail service there.
8. Will Windows Sockets be in _____?
8.1. Will Windows Sockets be in Windows NT?
Answer: Yes. In 16 and 32-bit versions.
8.2. Will Windows Sockets be in Windows for Workgroups?
Answer: Yes.
8.3. Will Windows Sockets be in DOS?
Answer: Paul Brooks of TurboSoft (paul@abccomp.oz.au) tells me:
As for a Windows Sockets for DOS - we have a library that is
pretty much complete. The goal was to produce a DOS library and
Binary API which would allow developers to code applications using
the Windows Sockets 1.1 spec. and have it run exactly the same
under DOS as Windows - blocking and non-blocking modes,
Asynchronous calls, the works. Apart from some AsyncGetXXXbyYYY
calls the rest works, although it is not possible to capture all
the Windows-specific semantics of some areas.
I am sure you can contact him for more information. JSB also has a
standardized Berkeley Sockets API for DOS which provides access to all
TCP/IP implementations.
8.4. Will Windows Sockets be in UNIX?
Answer: Well, since it came from BSD UNIX, there's not much need.
8.5. Will Windows Sockets be in Win32-S?
Answer: I think so.
9. What about standard APIs for ____?
9.1. What about standard APIs for FTP?
Answer: Not yet.
9.2 What about standard APIs for Telnet?
Answer: Not yet.
9.3 What about standard APIs for SNMP?
Answer: In the works. Send e-mail to winsnmp-request@Microdyne.COM to join
the list.
9.4 What about standard APIs for RPC?
Answer: Microsoft will be providing an implementation of DCE RPC. Also in
the works is the definition of a standard implementation of ONC RPC (known
as RPC for Windows) which will be made available by multiple vendors. To
contribute to the discussion, send email to rpc4win@wco.ftp.com.
9.5 What about standard APIs for TLI/XTI?
Answer: No, not yet. Vendors chose to do Windows Sockets because of the
sockets application and knowledge base, however anyone out there is free to
try a Windows TLI/XTI Specification.
10.1. Does Windows Sockets work over protocols other than TCP/IP?
Answer: Yes, it does. But we know of no vendors supplying one currently.
10.2. Will it?
Answer: Yes. Windows NT will include mechanisms for multiple protocol
support in Windows Sockets, both 32-bit and 16-bit.
11. Why no SOCK_RAW?
Answer: SOCK_RAW is optionally implemented by many major Windows Sockets
vendors. It is not mandated now because: 1) not every stack vendor can
supply a complete SOCK_RAW interface, and 2) we did not have time to define
the minimal subset every vendor could provide (e.g. maybe just ICMP).
12. Why isn't it possible to share sockets between tasks?
Answer: The real answer is that it wasn't considered sufficiently important
for 1.1, but is high on the list for inclusion in 2.0.
13.1. How do I get my IP address?
Answer: Do a gethostbyname() on the output from gethostname().
13.2. Why no SIOCGIFADDR?
Answer: It was not included because there were concerns it could not be
supported across platforms. It may be included in version 2.0 of the spec.
14. When should I use blocking vs. non-blocking sockets?
Answer: Try to use non-blocking sockets whenever possible; certainly if you
are coding a Windows application from scratch. Blocking sockets should
only be used when trying to maintain portability between UNIX/MS-DOS and
Windows.
15. What about other socket options that BSD supports? Ioctls?
Answer: Some vendors may support them. Do not rely on ones not explicitly
mentioned in the specification, however.
16. How can I get the local username?
Answer: No can do from Windows Sockets. Win32 (e.g. NT) has an API,
GetUserName(), for it, but there is no generic mechanism in Win 3.1.
17. Do I need to initialize the WSAData structure before calling
WSAStartup?
Answer: No, WSAStartup does not retrieve the contents of the WSAData
structure pointed to, it fills it in.
18. If I write a Windows Sockets program, will I be able to communicate
with a Sockets program on UNIX or any other non Windows platform?
Answer: This common question is the result of confusing protocols with the
APIs; communicating programs need not have been created with the same APIs,
as long as they are using the same (transport & network) protocols.
19. Is it possible to create sockets that map to a dll rather than an
application? I have tried a WSAStartup() as part of my LibMain, but the
sockets that are created are owned by the application, not by the DLL. It
would be desirable for me to have some of the sockets that are opened have
"A Global (DLL wide) Scope".
Answer: The way this situation has been dealt with by developers is to have
your DLL create a "helper process" which will perform all Windows Sockets
operations on behalf of your applications (thereby having all sockets owned
by the helper process' task).
20. A *Class* of questions that could be answered are related to porting
extant BSD applications to Windows Sockets: "How to I implement the xxxx
function call in my Windows Sockets application?" (e.g. fcntl(), readv(),
etc).
Answer: In general, you will have to code such functions yourself, although
it would not hurt to suggest them for the next revision of the
specification as well.
21. Is there a Pascal/Visual Basic/Visual Cobol header file for Windows
Sockets?
Answer: The Pascal form is already in the FTP archive. Look there for any
other header files that people may have developed so far.
Comments