Making Win98 work on the internet

98 Guy wrote in :

If you have a motherboard based on the Intel 845 chipset (and possibly
other 8xx chips) then look he

http://www.tacktech.com/news.cfm?sub...orangeware-int
elreg-usb-2.0-enhanced-host-controller-driver

10.07.2002 - OrangeWare/Intel® USB 2.0 Enhanced Host Controller driver

Under the Driver File Details for the Intel USB 2.0 Enhanced Host
Controller on my win-98 system, I have 3 files listed:

- iusbehci.sys (USB 2.0 enhanced host controller driver, Orangeware)
- iusb2hub.sys (USB 2.0 hub driver, Orangeware Corp, version 1.1.0.2)


That last one might alwo work renamed as USBHUB20.sys in NUSB, for wider
local support, when using that chipset. I don't know whether the other file
is needed in that transplant, but if so, the name stays unchanged apart from
omitting the 'i'. (NUSB might support that chipset natively for all I know,
but that's something to can try if it doesn't).

"Bill in Co" wrote in
news
2. The universal USB driver, often called NUSB. There are several
iterations - probably go for the latest for a first try, but some people
have found earlier ones work better for them. The instructions for it
say to remove any other USB drivers you may have before installing it;

(at least for the newer, 3.x versions, although it may have been
"recommended" for the older versions too - see my comments below):


I think it should always go in a clean install. Conflicts with other drivers
should always yield to core sysfiles (except where they are specifically
known not to work), which is basically what NUSB is. It's a hybrid of W2K and
WME core USB support, transplanted to W9X. Most of anything it could conflict
with is very specific proprietary support. The common exception is the
USBHUB20.SYS file, which may need replacing with mainboard-specific support
from a file (often with some variant name) supplied by the mainboard maker.
Whatever that file is, it should be named USBHUB20.SYS for NUSB to use.

My post just now applies to v3.3, so likely to most if not all other
versions.

"Bill in Co" wrote in
news
In just checking over my notes, I seem to recall that if you stuck with
the older 2.x nusb versions (like nusb23e.exe), instead of the newer 3.x
versions, you just may be able to get away with NOT having to uninstall
all the USB drivers first. And that's what I did on my old Win98SE
system - I used the older nusb23e driver, and did NOT uninstall all the
USB drivers first (as is now strongly recommended, or perhaps even
required, in the later versions). And it worked fine for me!

It may be that NUSB later included a lot more INF file details for specific
devices. Core support alone should not bork so long as the new core is as
consistent as it should be, with the OS and what remains of the old. I think
the reason that newer NUSB changes so much, is to make sure that there is no
'old' to be inconsistent with. In which case, logically, any conflicts seem
to arise from specific INF details added by proprietary drivers added to the
OS later. So in either case, it is best to uninstall those first just to
reduce risk and annoyance. It's easier than auditing the OS's INF stash, and
that of NUSB also.

"J. P. Gilliver (John)" wrote in
:

Good analogy!


Better than my last. I used to describe it as a car crashing no buffer
rails at the side of a road tunnel. It was clumsier..

When I said "net access" I was being sloppy - I meant anything that
involves getting something over the internet, not just browser use. If
you're playing an XviD file from a remote source, even if via ftp,
streaming, or similar, I'd agree. (Ideally you'd need a way of telling
the player to buffer a large proportion of the file before it starts
playing, but many players don't have that option, or it isn't obvious
anyway. Or just download the whole file before starting, but that may
conceivably not always be possible.)


I think this is what browser flash players do, loading, buffering before
playback. They're just lousy at it, especially on erratic lines. Some sites
specifically advise pausing to allow more download, then resuming playback.

(It may not help that in an effort to make a file small enough to stream
cheaply and efficiently, the CPU overhead needed to PLAY it on arrival is so
great that nothing is gained, for the end user anyway. Turing machines (all
computers we can afford) all do one instruction at a time, and every response
to incoming data arriving after a wait is time not spent on hungry playback
demands, and vice versa. So in practise streaming is nonsense. They might as
well provide direct downloads and standalone players! The 'experience' would
be better that way.

Lostgallifreyan wrote:
"Bill in Co" wrote in
news
In just checking over my notes, I seem to recall that if you stuck with
the older 2.x nusb versions (like nusb23e.exe), instead of the newer 3.x
versions, you just may be able to get away with NOT having to uninstall
all the USB drivers first. And that's what I did on my old Win98SE
system - I used the older nusb23e driver, and did NOT uninstall all the
USB drivers first (as is now strongly recommended, or perhaps even
required, in the later versions). And it worked fine for me!

It may be that NUSB later included a lot more INF file details for
specific
devices.

But how would that allow for the older version to be stable w/o uninstalling
all the old usb drivers, but not the newer versions (3.x)?

BTW, I may be misremembering this, but I think when just the old 2.x nusb
version came out, that strong cautionary note wasn't there, but when 3.x
came out, it was there, or at least for the 3.x versions. Which is what
prompted me to install the old 2.x version at the time, and it worked great
(w/o going thru the hassle of uninstalling all existing USB stuff first, and
then trying to get it all reinstalled again, assuming I even knew where the
drivers were anymore)

Core support alone should not bork so long as the new core is as
consistent as it should be, with the OS and what remains of the old.

I'm not sure I follow. Are you comparing the core support in the 2.x to
the 3.x versions, and what is already installed, or what?.

I think
the reason that newer NUSB changes so much, is to make sure that there is
no
'old' to be inconsistent with. In which case, logically, any conflicts
seem
to arise from specific INF details added by proprietary drivers added to
the
OS later. So in either case, it is best to uninstall those first just to
reduce risk and annoyance. It's easier than auditing the OS's INF stash,
and
that of NUSB also.

"Bill in Co" wrote in
m:

It may be that NUSB later included a lot more INF file details for
specific devices.

But how would that allow for the older version to be stable w/o
uninstalling all the old usb drivers, but not the newer versions (3.x)?


Lack of conflict. Can't conflict with what isn't there in one of the
instances.

"Bill in Co" wrote in
m:

Core support alone should not bork so long as the new core is as
consistent as it should be, with the OS and what remains of the old.

I'm not sure I follow. Are you comparing the core support in the 2.x to
the 3.x versions, and what is already installed, or what?.


Both. USB is a subsystem. (My X98 work shows me that W98 is far more modular
than M$ wanted us to beleive). My main concern when first trying NUSB was
that it replaced so many files. It seemed unwise, over-dominating, until I
understood that it was an entire subsystem replacement. The roots of any
conflict is has aren't so likely the files, but the INF data contained for
lots of devices. There are two ways to handle that: either stay small and
specific, which is what singular device manufacurers try to do, or go big and
general, as NUSB had to do. Once NUSB had got to the point where it had to do
this, it became important to have as clean a starting base as possible.

Lostgallifreyan wrote:
"Bill in Co" wrote in
m:

Core support alone should not bork so long as the new core is as
consistent as it should be, with the OS and what remains of the old.

I'm not sure I follow. Are you comparing the core support in the 2.x to
the 3.x versions, and what is already installed, or what?.


Both. USB is a subsystem. (My X98 work shows me that W98 is far more
modular
than M$ wanted us to beleive). My main concern when first trying NUSB was
that it replaced so many files.

I wonder if the newer versions of nusb replace MORE files than the older
versions, and that's part of the problem here (unless you do a clean
install). More below.

It seemed unwise, over-dominating, until I
understood that it was an entire subsystem replacement. The roots of any
conflict is has aren't so likely the files, but the INF data contained for
lots of devices. There are two ways to handle that: either stay small and
specific, which is what singular device manufacurers try to do, or go big
and
general, as NUSB had to do. Once NUSB had got to the point where it had to
do this, it became important to have as clean a starting base as possible.

I guess that may be implying that the old versions of nusb won't or can't
handle as many devices as the new ones can, too. OR that the old versions
were so limited in what they added that there were no potential conflicts.
But I'm still not sure I'm getting it.

"Bill in Co" wrote in
m:

I wonder if the newer versions of nusb replace MORE files than the older
versions, and that's part of the problem here (unless you do a clean
install).

But that's exactly what I said it did. While I don't know enough exact file-
countage to prove it, it's clear that NUSB is aimed at reliable replacement
of the whole subsystem. It's safe to assume (human logic being what it is)
that originally it set out to do no more than it had to, then found it had to
do more.

Once they got to that point it would be easier to go for broke, all in, try
to do everything a USB subsystem should be doing. Ergo, more files, more
data.