Re: Help with SQLNet on NT client?

Chris Gadsby wrote in message ...
>I have a setup which includes some legacy applications namely a dos app
>using SQLNet v1 to talk to an Oracle 7.1 server running on Novell
>fileserver via SPX. Also we have a 16bit windows app talking to the same
>database via SQLNetv2. This all works fine on win 3.1 machine and Win95
 but
>not NT4 workstations. If I have the MS Client for Netware installed the
 dos
>system works fine but the oracle windows software (eg TNSPing) looks for
>NWcallls.dll ir NWIPXSPX.dll which are there. If I install the Novell
>Intranetware client for NT instead the windows stuff works fine but the dos
>not won't connect!

The NT NetWare software you've is 32bit. The old legacy DOS app is 16bit. What's missing from this config is something to translate (or thunk) the 16bit DOS SPX calls to the 32bit SPX NT driver.

Unlike Windows'95 you can not run 16bit networking protocol stacks on NT. They use direct hardware access which is a no-no under NT. This means you have to make use of 32bit NT protocol stacks. In order to "hook" (translate) 16bit software into the 32bit protocol stack, the 16bit calls are thunked to 32bit calls by the NT kernel.

How's thunking handled? 16bit Windows software uses the Win16 API set. The NT operating automatically "changes" these 16bit calls into 32bit calls when running a 16bit app (which explains why 16bit apps runs slower on NT than for example on Win3.1 and Win95/98).

With me so far? (not very good at explaining this without a whiteboard and plenty of coloured whiteboard pens! :-)

Now the 16bit DOS software does not use an API. They "talk" the plain old "DOS kernel" language. These calls are serviced (both on '95 and NT) via the DOS Virtual Machine (VM). Which is why "normal" DOS programs (not talking about DOS programs using TSRs or special DOS drivers) work both on NT and on '95. The DOS VM understands this "DOS kernel language" and can translate that into the appropriate 32bit instructions required for the NT kernel to execute them.

Now how are the DOS SPX calls then handled? In DOS, you used to load a TSR (e.g. IPXODI.COM) to provide DOS with a SPX "API" (in fact the TSR was SPX service, similar in some ways to an NT service).

In NT, that is a problem. The DOS VM does not know the SPX TSR "language" and can therefore not translate DOS SPX calls into 32bit NT calls. And given the number, variety and versions of the DOS TSRs and device drivers, it make sense for the NT DOS VM not to even attempt doing this.

Thus, DOS SPX calls are not understood by the DOS VM. Neither is TCP/IP DOS calls understood. What about FTP and PING? Well, they are not DOS programs, but 32bit NT character/console programs. Try and run them on a DOS 6.x PC and they won't work. There's a caveat to this though - the DOS VM does support some old DOS device drivers we used to load in CONFIG.SYS. You can for example load a DOS fossil driver (used for providing a serial port/modem services ) in a DOS VM and run old DOS software that uses the fossil service. However, it's very "iffy" whether a DOS device driver will work or not under NT's DOS VM. Ditto for TSRs.

Why does your configuration work under '95? Well, almost -anything- can work on that bastardise operating system! :-) As I said earlier, Win95 allows you to load and use 16bit DOS device drivers and TSRs. The '95 kernel loads "over" these drivers/TSRs. Which explains why Win95 is a bit of a "bastard". It's suppose to a 32bit operating system -AND- support (read, run on top of) native 16bit DOS operating system drivers. A huge conflict. Which is why Win95 is not really a 32bit operating system at all. However, NT is.

Hope you understand my babbling! :-)

regards,
Billy Received on Wed Dec 23 1998 - 00:00:00 CST