Conference jamin::pathworks32

317.0. "should we be moving away from DNETW.DLL?" by DECALP::KLAVINS (Ed Klavins, RTR Engineering) Tue May 27 1997 08:48

    [Follow-on from 134.5, but thought new thread was better...]
    
>    As for the real issue... Winsock 1.1 is fully supported in a Winsock
>    2.0 environment, and has the added value of not forcing you to make
>    code changes.  If the DECnet service provider, and Winsock 2.0 is added
>    to Windows 95, the code you have that works on PATHWORKS 32 for NT
>    v4.0, will work on Windows 95 (unless it requires NT specific
>    functions, outside of the Winsock space).
    
    I had more or less come to that conclusion and am now building to see
    if it really works;')
    
    My remaining question has to do with the phrase: "unless it requires NT 
    specific functions, outside of the Winsock space". The NT v4.0 code
    uses a few of the functions from DNETW.DLL (dnet_addr, etc.). I've
    checked that all these extended functions are ones that are supported
    in the PW32 DNETW. So, our code should work ok, is my understanding.
    (correct?)
    
    But, should we be looking to modify our code to use the extended
    functions via WSAIoctl() (i.e. thru Winsock2 directly, without DNETW)?
    I ask, because I couldn't find anywhere in the online help that this is 
    what should be done, and just came across this by looking at the DECnet 
    appendix/addendum (whatever it is) to the Winsock2 spec. 
    
    ed

The DNETW functions are available, however... they ARE NOT THREAD SAFE, 
converting to the Winsock 2.0 extended functions is a better idea, however
THEY ARE NOT THREAD SAFE.

You must supply the thread safeness that you need in your application, so
the better thing to do is break the calls to either DNETW or the extended
functions out into your own functions that perform what ever mechanism you want
for making the calls thread safe, and ... making the calls.

We are looking into extending support into name spaces, thus more standard
functions would also work (gethosedbyname) ;-)

Jeff