Mail Archives: opendos/2001/06/03/11:22:28
> Actually can someone (Matthias?) explain to me why running the DOS drivers
> for PNW on the Win9x machine wouldn't work?
It's quite complicated, I think, and the real reasons are buried within the
Win9x networking layers. In fact, it's different on Win95 and 98 because MS
made some changes to Win98's networking system. But this is how I understand
it from discussions on Novell's Support fora:
On Win95, you can install the PNW client before or during Win95 setup and then
tell Win95 to use your existing Novell NetWare (or maybe ODI) stack. Then,
during boot, the ODI stack and VLMs load as they do on DOS, and Windows will
use the REDIR.VLM in the same way DOS does. I think it knows to use standard
NetWare calls to do stuff like map/unmap drives and so forth. You can't,
though, load the SERVER.EXE -- I think because once Windows enters protected
mode, it's no longer able to access the disk properly since Windows took over
the controller. Not sure on that reason though.
With Win98, though, MS changed something. The 'pass calls down to the
real-mode network' trick no longer works -- I don't think Win98 will use the
real-mode redirector interface for anything. The VLMs may load (not sure --
Client32 for DOS has problems under MS-DOS 7.1 certainly), but Windows installs
its own VREDIR.386 and networking system over the top of the existing stuff
during boot.
If you have the client installed before running SETUP, SETUP will comment out
the STARTNET.BAT call in AUTOEXEC.BAT and provides you with the option to use
your existing ODI driver, but no NetWare client. If you install the client
during or after SETUP, Windows can't see it when you tell it to use the
existing ODI installation.
> If it doesn't work, was an attempt made using LoadTop=0 in msdos.sys? This
> is added to solve problems with Novell Netware, and other programs.
Well, according to the MSDN docs I can find, it loads COMMAND.COM and
DRVSPACE.BIN into the top end of the 640Kb. I don't think the NetWare Client
OSI stack makes any assumptions about the layout of memory (otherwise it might
break on DR-DOS the same way compressed executables can do), but I'm not sure
about the old monolithic IPX.COM and NETX.COM. NETX might be making an
assumption about memory -- perhaps it's looking to find DOS's shell information
but not finding it in the right place -- might more likely is that NetWare
itself doesn't like having COMMAND.COM moved to the top end of memory, where
it'll overwrite it with the NetWare SERVER.NLM and then not be able to exit to
DOS properly or access the DOS partition; maybe it stops REMOVE DOS from
working. Perhaps. Not sure.
Regards,
Ben A L Jemmett.
(http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/)
- Raw text -