Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Re: ntfsd digest: February 24, 2000

OSR_Community_UserOSR_Community_User Member Posts: 110,217
>What kind of object does ObReferenceObjectByHandle on a socket give me?

I'm not very familiar with sockets or Windows sockets, but...

MSDN says:
"A socket handle can optionally be a file handle in Windows Sockets 2. It is
possible to use socket handles with ReadFile, WriteFile, ReadFileEx,
WriteFileEx, DuplicateHandle, and other Win32 functions. Not all transport
service providers support this option. For an application to run over the
widest possible number of service providers, it should not assume that
socket handles are file handles."

and
"Socket Data Type
A new data type, SOCKET, has been defined. This is needed because a Windows
Sockets application cannot assume that socket descriptors are equivalent to
file descriptors as they are in UNIX."

so it sounds like if a SOCKET is a handle at all, it is a handle to a
FILE_OBJECT. How widely valid is this assumption? For at least TCP/IP
sockets on Win9x and NT4+?

- Jay

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    AFD is the file system (on Windows NT/2000) that supports sockets. Thus,
    you will get back a file object from a socket handle (if you get anything.)
    For TCP/IP you will get back a file object.

    Regards,

    Tony

    Tony Mason
    Consulting Partner
    OSR Open Systems Resources, Inc.
    http://www.osr.com


    -----Original Message-----
    From: Jay Krell [mailto:[email protected]]
    Sent: Friday, February 25, 2000 3:28 AM
    To: File Systems Developers Interest List
    Subject: [ntfsd] Re: ntfsd digest: February 24, 2000


    >What kind of object does ObReferenceObjectByHandle on a socket give me?

    I'm not very familiar with sockets or Windows sockets, but...

    MSDN says:
    "A socket handle can optionally be a file handle in Windows Sockets 2. It is
    possible to use socket handles with ReadFile, WriteFile, ReadFileEx,
    WriteFileEx, DuplicateHandle, and other Win32 functions. Not all transport
    service providers support this option. For an application to run over the
    widest possible number of service providers, it should not assume that
    socket handles are file handles."

    and
    "Socket Data Type
    A new data type, SOCKET, has been defined. This is needed because a Windows
    Sockets application cannot assume that socket descriptors are equivalent to
    file descriptors as they are in UNIX."

    so it sounds like if a SOCKET is a handle at all, it is a handle to a
    FILE_OBJECT. How widely valid is this assumption? For at least TCP/IP
    sockets on Win9x and NT4+?

    - Jay
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    The MS implimentation of sockets for tcp /ip / udp are represented by a
    FILE_OBJECT, therefore you can use the ReadFile, WriteFile api's. Other
    partys that impliment their own transport providers do not have to
    follow this model.

    APN

    -----Original Message-----
    From: [email protected]
    [mailto:[email protected]]On Behalf Of Jay Krell
    Sent: Friday, February 25, 2000 3:28 AM
    To: File Systems Developers Interest List
    Subject: [ntfsd] Re: ntfsd digest: February 24, 2000


    >What kind of object does ObReferenceObjectByHandle on a socket give me?

    I'm not very familiar with sockets or Windows sockets, but...

    MSDN says:
    "A socket handle can optionally be a file handle in Windows Sockets 2.
    It is
    possible to use socket handles with ReadFile, WriteFile, ReadFileEx,
    WriteFileEx, DuplicateHandle, and other Win32 functions. Not all
    transport
    service providers support this option. For an application to run over
    the
    widest possible number of service providers, it should not assume that
    socket handles are file handles."

    and
    "Socket Data Type
    A new data type, SOCKET, has been defined. This is needed because a
    Windows
    Sockets application cannot assume that socket descriptors are equivalent
    to
    file descriptors as they are in UNIX."

    so it sounds like if a SOCKET is a handle at all, it is a handle to a
    FILE_OBJECT. How widely valid is this assumption? For at least TCP/IP
    sockets on Win9x and NT4+?

    - Jay


    ---
    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • Mark_S._EdwardsMark_S._Edwards Member Posts: 475
    At 08:49 AM 2/25/2000 -0500, you wrote:
    >-----Original Message-----
    >From: Jay Krell [mailto:[email protected]]
    >Sent: Friday, February 25, 2000 3:28 AM
    >To: File Systems Developers Interest List
    >Subject: [ntfsd] Re: ntfsd digest: February 24, 2000
    >
    >
    > >What kind of object does ObReferenceObjectByHandle on a socket give me?
    >
    >I'm not very familiar with sockets or Windows sockets, but...
    >
    >MSDN says:
    >"A socket handle can optionally be a file handle in Windows Sockets 2. It is
    >possible to use socket handles with ReadFile, WriteFile, ReadFileEx,
    >WriteFileEx, DuplicateHandle, and other Win32 functions. Not all transport
    >service providers support this option. For an application to run over the
    >widest possible number of service providers, it should not assume that
    >socket handles are file handles."
    >
    >and
    >"Socket Data Type
    >A new data type, SOCKET, has been defined. This is needed because a Windows
    >Sockets application cannot assume that socket descriptors are equivalent to
    >file descriptors as they are in UNIX."
    >
    >so it sounds like if a SOCKET is a handle at all, it is a handle to a
    >FILE_OBJECT. How widely valid is this assumption? For at least TCP/IP
    >sockets on Win9x and NT4+?
    >
    > - Jay


    The first implementation of the data type SOCKET or socket handle in
    windows was in Windows 3.x. On this platform these were just whatever
    numbers the underlying stack vendor decided to give to them.

    When Microsoft added TCP/IP to NT, they created their stack to be part of
    the o/s and to use the same o/s objects as any other file system in
    NT. What they forgot about were that there were other vendors out there,
    not just of TCP/IP but of other protocols too.

    Most of the problems occur on Win95/98, but are present on pre-SP4 versions
    of NT 4. The Winsock 2 spec allows for providers to create sockets that
    are either IFS objects or non-IFS objects. Obviously, the Microsoft stack
    provides IFS objects and as such functions like WriteFile and
    DuplicateHandle will generally work.

    These functions will fail if the socket handle is not an IFS handle. One
    really ought to look in the protocol_info structure about the protocol in
    use before attempting to use some of the functions that Microsoft lists as
    available to socket handle that aren't in the Winsock spec.

    One might assume that the vast majority of machines will be running the
    Microsoft stack and that you will never encounter a non-IFS handle. This
    is not the case. The Winsock spec allows for the use of layered providers
    that can add functionality over a base provider such as the MS
    stack. Because layered providers are implemented in user mode, the handles
    that they provide are de fact non-ifs handles. Just installing the sample
    layered provider from MSDN, which actually adds no functionality is enough
    to kill pre-SP4 versions of NT where some system components, notably RPC,
    assume that all socket handles are IFS handles. e.g. Calling
    Read/WriteFile bypasses the Winsock layers and goes direct to the device,
    if the socket handle is non-IFS there is no device, but Read/WriteFile
    don't know that.

    The fix in SP4 was to add a new driver that could turn non-IFS handles in
    to IFS handles. This driver has the added effect of catching all calls
    made to Read/WriteFile, throwing them back to user mode where they are
    re-issued as WSARecv/Send calls.

    If you are using Read/WriteFile on socket handles, you're doing twice as
    many ring transitions as you think you are.

    The assumption that a socket is a handle to a FILE_OBJECT is more unlikely
    under Win9x where there are still multiple vendors supplying that
    market. For NT it can only be assumed to be true after SP4.

    HTH,

    Mark.
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > A new data type, SOCKET, has been defined. This is needed because a
    Windows
    > Sockets application cannot assume that socket descriptors are equivalent
    to
    > file descriptors as they are in UNIX."

    MS got rid of it in some SP to NT4. (SP4?)
    They added a driver called ws2ifsl.sys (Winsock IFS Layer) to the OS to
    emulate file handles for WinSock providers for which socket handle != file
    handle.
    Anyway:
    - the default Winsock provider used by all MS stacks - afd.sys + msafd.dll
    (which is in fact a brigde between Winsock and kernel-modeTDI interface) -
    gurantees that sockets are file handles.
    - nonMS network stacks on NT are very, very rare.

    Max
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 9-13 Sept 2024 Live, Online
Developing Minifilters 15-19 July 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online