Mail Archives: opendos/2005/01/12/18:28:02
Well, the FRAME-type stuff is still a bit of a mystery to me,
however, this isn't the problem, as you will see below.
As for Client32, this is the 32-bit DOS (and MSW, I think)
client we used with our former Novell 4 network. It ran on
top of 16-bit DOS, in extended memory, allowing plenty
of conventional and UMB memory available for other DOS
requirements. An excellent client, by stark contrast to
the flaky, bloated MonoSoft client we now have to use
with our flaky MonoSoft SMB network. If this client were
compatible with PNW (my interpretation of Ben's posting
is that it isn't, only the 16 bit VLM client is), then I would
definitely use this, because it of the major benefits it gives
for DOS memory availability.
Anyway, last night, as a hunch, I attached a 27 ohm
resistor to the BNC connector of the network card,
on the PC I am experimenting with. I figure this would
approximate the two terminators that would normally
be fitted if the network were completed. Viola! The
VLM ODI NE2000 driver loaded!
So, it seems there is a bug (actually, two bugs, as you
will see) with the VLM ODI NE2000 driver. It performs
some sort of test to check if the network is correctly
terminated, but then misinterprets this as a hardware
configuration conflict. Furthermore (and this is the second
bug I alluded to), it then neglects to restore the interrupt
vector for the card's IRQ, even though it isn't loading. As
a result, attaching a cable or terminating resistor to the
card's BNC connector will subsequently invoke a call to
this interrupt vector, resulting in a hung PC - nasty!
Note that the NE2000 packet driver does not exhibit this
behaviour, nor the Client32 driver, just the VLM NE2000
driver does. Additionally, the VLM NE1000 driver (with
the 8-bit card, of course) does not exhibit this behaviour
in the same situation.
So, now that I know the nature of the VLM ODI NE2000
driver's problem, I can "work around" it (ie. if I boot without
a proper network connection, I must switch off the PC
before making this connection, else the PC will hang).
However, if it were possible to use the Client32 drivers
instead with PNW, that would not only avoid these bugs,
it would give me more free memory for DOS stuff. Unless
someone says otherwise, I'll work on the basis that the
Client32 drivers won't work with PNW.
Joe.
> -----Original Message-----
> From: Gary Welles [SMTP:gary AT wellesway DOT com]
> Sent: Tuesday, January 11, 2005 11:56 PM
> To: OpenDos
> Subject: Re: PNW vs Netware (and NE2000 drivers)
>
> > 1) Can anyone confirm (or otherwise) that Novell's VLM ODI NE2000
> > driver is broken, when using an original (early 90's) Novell card?
>
> I'm under the illusion that only the ODI driver sees the
> hardware and that the VLM may be asking something of it that
> it's not configured for. You mentioned INT 5 and PORT 300,
> but not FRAME type. Perhaps the VLM's default differs from
> that of the ODI driver.
>
> > 2) Have I correctly interpreted Ben's posting, which to me says that
> > the Client32 drivers are incompatible with PNW?
>
> He appears to have referred to incompatiblity between
> machines one running PNW, the other Netware. I also expect
> the "32" in Client32 refers to Win32 and not the underlying
> 16-bit DOS.
>
> My experience has been to get something to work and then
> experiment. I use only the IPX transport with DESQview/X's
> X-server providing TCP/IP network services:
>
> E32C - E464 4.8K Used (LSL)
> E465 - E581 4.4K Used (E200P)
> E582 - E75F 7.4K Used (IPXODI)
>
> It's another set of configuration issues, but DV/X is both
> client and server. At a minimum it could be an FTP server to
> other machines on your network.
>
> NAME=DESQview
> URL=http://www.chsoft.com/dv.html
>
> -- Gary Welles
-------------------------------------------------------------------------------------------------------
This email (including any attachment) is confidential. If you are not the intended recipient,
you must not disclose or use this email or the information contained herein for any purpose.
If you have received this email in error, please immediately advise us by reply and delete this email.
This email may not be altered, forwarded or re-issued without our consent. AMPY Email Metering is
not responsible for any changes made to this email or the effect of any changes on the email’s meaning.
It is the responsibility of the recipient to scan this email for viruses and faults prior to processing.
AMPY Email Metering shall not be liable for any loss or damage caused by this email from transmission,
viruses, faults or the use of data accompanying this message. AMPY Email Metering reserves all its
rights, including copyright,in this email.
- Raw text -