--
Please read http://dts-l.org/goodpost.htm on how to post messages to NG's
Windows support http://www.aumha.org
"alice" <al...@discussions.microsoft.com> wrote in message
news:15809311-00F0-4AC9...@microsoft.com...
> I have a VGi 1GB usb flash memory stick which works on my WIN XP machine
but
> not on WIN 98E as WIN98E doesn't support mass storage device and requires
a
> driver to operate. My problem is I cannot find a vendor (VGi) download
for
> this device as I googled and cannot find the vendor site. Is there a site
USB is either v.1 (supported by Win98 original) or
v.2 (supported by Win98SE). If your memory stick
is new it is probably USB v.2 -- i.e. not supported
by original or first edition Win98. (You may be lucky:
it appears some USB v.1 drivers operate some v.2
devices. All you can do is cross fingers and try.)
--
Don Phillipson
Carlsbad Springs
(Ottawa, Canada)
They generally install via an InstallShield route, which is the more
difficult to adapt to your needs, but it can usually be done.
The other sort that is easiest to use, not using InstallShield, just has a
package (usually zipped) which contains .INF files for the installation of
the drivers, and the drivers, two of them, usually a .PDR file, and a .SYS
file, and the only trick is to use an editor to modify the .INF to use the
HardwareIDs for your flash drive.
To find what the HdwIDs are, go to an XP machine. Mine is currently dead,
the frequent state of XP in my experience, so I can only give you directions
on this from a combination of unreliable memory and what seems reasonable
from W98.
There are two or three subkeys in the registry under HKLM which will be
affected by the fd, but the problem lies in finding which entry corresponds
to your fd, especially if there are other brands of fd installed on the
machine.
Since I only have W98se at hand, the registry entries I mention are from it,
and they are different in XP, but there is enough similarity, I was able to
find what I needed.
There are generally entries under the registry keys HKLM\Enum\USB which
will be in the form: VID_05DC&PID_A400 . . . with other stuff following to
name each subkey. The Vendor ID (VID) in this example is VID_05DC and
Process ID (PID) A400 strung together make up the HardwareID and that is
what you need, but for *your* fd, since they are never so kind as to give it
to you. The Enum\USB key is the harder one to use to tell what you want, but
the data is there.
If you go to HKLM\Enum\SCSI, you'll find subkeys with VIDs and PIDs which
also embed the names of the USB devices, and from there you can find which
is the one you want.
The other key that is useful is
HKLM\System\CurrentControlSet\Services\Class\hdc, under which the fds will
be located, and if you expand each subkey, you'll be able to read the device
name, manufacturer, as well as the HardwareID.
Now, when you have the HdwID, what you now need to do is modify the .INF
file in the package you downloaded (I originally got mine from the PNY site
for their Attache flash drives, but the one I now have on my machine is from
the Kinston site, the result of much experimentation, which disclosed that
most, but not all, W98 drivers are generic in origin, and take little
modification to work generally. In this package, you should find one .INF
file, but I have seen those with more, and they can pose difficulties. Try
the ones with only one .INF first. What you want to do is replace the HdwID
string under the 'Manufacturer's Names Section. The format of the file is
much like the old Win.ini files, or like any of a number of other MS script
files:
[Version]
Signature="$CHICAGO$"
Class=HDC
provider=%VENDOR%
[Manufacturer]
%MfgName%=USBDRV
[USBDRV]
%USB\VID_0D7D&PID_0153.DeviceDesc%=usbdrv.Dev,USB\VID_0D7D&PID_0153
%USB\VID_0D7D&PID_1320.DeviceDesc%=usbdrv.Dev,USB\VID_0D7D&PID_1320
%USB\VID_0D7D&PID_1321.DeviceDesc%=usbdrv.Dev,USB\VID_0D7D&PID_1321
%USB\VID_0D7D&PID_1324.DeviceDesc%=usbdrv.Dev,USB\VID_0D7D&PID_1324
%USB\VID_0D7D&PID_1420.DeviceDesc%=usbdrv.Dev,USB\VID_0D7D&PID_1420
. . . . .
Using the example above, one could modify the last string to be:
%USB\VID_0D7D&PID_1420.DeviceDesc%=usbdrv.Dev,USB\VID_05DC&PID_A400
The initial part of the string, between the % signs is an identifier, and
refers to a string in the [Strings] section at the end of the file, and
doesn't require a change for functionality.
Now, when you install this package, in just the way you normally would if
you were using the fd of whichever manufacturer's package you've downloaded,
*without the fd plugged in*, the software will install, and then, once that
is done, you may need to reboot, but not usually. Then, plugging in your fd
will bring up a series of dialog boxes about new hardware, and finding the
driver, etc., all of which is automatic, and will complete without
intervention.
If you start with an InstallShield package, or other packaged installer, in
which you cannot see the .INF file to be modified, it is usually possible to
modify the IS configuration file to make it do what you want, but it is
easier, perhaps to explain that you can just do the InstallShield thing,
*making certain you don't plug in the fd*, copy all the files it unpacks,
which should include an .INF file, uninstall the package, modify the .INF as
above, and then execute the setup.exe program in the unpacked files.
Hope this is not too long--
Joe
"alice" <al...@discussions.microsoft.com> wrote in message
news:15809311-00F0-4AC9...@microsoft.com...
>To find what the HdwIDs are, go to an XP machine.
On the Win98 CD you will find a utility called "usbview.exe". It
should identify your USB ports and devices without the need for
drivers.
This is the report for my USB memory stick:
Device Descriptor:
bcdUSB: 0x0200
bDeviceClass: 0x00
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x40 (64)
idVendor: 0x0EA0 <----------- Vendor
idProduct: 0x2168 <----------- Product
bcdDevice: 0x0200
iManufacturer: 0x01
iProduct: 0x02
iSerialNumber: 0x03
bNumConfigurations: 0x01
ConnectionStatus: DeviceConnected
Current Config Value: 0x01
Device Bus Speed: Full
Device Address: 0x02
Open Pipes: 3
Endpoint Descriptor:
bEndpointAddress: 0x81
Transfer Type: Bulk
wMaxPacketSize: 0x0040 (64)
bInterval: 0x00
Endpoint Descriptor:
bEndpointAddress: 0x00
Transfer Type: Control
wMaxPacketSize: 0x0507 (1287)
wInterval: 0x0202
bSyncAddress: 0x40
Endpoint Descriptor:
bEndpointAddress: 0x00
Transfer Type: Control
wMaxPacketSize: 0x0040 (64)
wInterval: 0x0000
bSyncAddress: 0x07
- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.
Joe
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:rudds15t7br1bh65h...@4ax.com...
This is claimed to be a generic USB mass storage driver for W98SE (by
LexarMedia):
http://www-user.tu-chemnitz.de/~heha/hs_freeware/USB%20Mass%20Storage.zip
Thanks,
Joe
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:r3sis1pobob3m7iau...@4ax.com...
Thanks, Frank.
On a win98se system I replaced two different drivers (usb memorystick,
cardreader) which interfered with each other, with the one you mention.
Now 1 driver is running twice, doing both jobs without interference.
I've seen and tested more drivers which claim to be universal.
Most of them do change more than just adding a sys and a pdr.
The one you mention just adds sys-files and pdr-files, makes the proper
changes in the registry, and voila, it works.
Grtz,
TR
Thanks Franc.
On a win98se system I replaced two different drivers (usb memorystick,
cardreader) which interfered with each other, with the one you mention.
Now 1 driver is running twice, doing both jobs without interference.
I've tested more drivers which claim to be universal.
I got started on this when I bought a PNY fd which wouldn't work with the
drivers they had on their site at the time (they have since fixed that).
I then kept going to see if I could find a driver that would work for all
three brands I had, but would also provide some sort of disconnect security,
such as the 'eject' selection on the context menu in Explorer, or XP's icon
in the tray, but have had no luck on this last part. Such as do provide it
do so in a proprietary way, so far as I have been able to tell.
Joe
"alice" <al...@discussions.microsoft.com> wrote in message
news:4D393490-507E-4F68...@microsoft.com...
>"Franc Zabkar" <fza...@iinternode.on.net> schreef in bericht
Just out of curiosity I wanted to find out what it was about the
generic .inf file that did the trick, so I compared it against my own.
I think these lines contain the principal difference:
Generic:
[LexarMedia]
%DeviceDesc%=jd.install,USB\Class_08&SubClass_06&Prot_50
Mine:
[USTORAGE]
%UF1.DeviceDesc%=UF.install,USB\VID_0EA0&PID_2168
It appears that the generic .inf file looks for devices that satisfy a
particular class, subclass, and protocol ID (a particular device
category?), whereas mine looks for a specific vendor and product ID.
I normally use usbview.exe (on the Win98 CD) to identify USB devices.
Unfortunately both my USB stick and my Canon USB laser printer have
zeroes in the abovementioned class and protocol fields.
Device Descriptor:
bDeviceClass: 0x00
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
idVendor: 0x0EA0
idProduct: 0x2168
I suspect this is a bug because the registry contains the expected
numbers:
HKEY_LOCAL_MACHINE\Enum\USB\VID_0EA0&PID_2168\23076040F6223357
"CompatibleIDs"="USB\CLASS_08&SUBCLASS_06&PROT_50,USB\CLASS_08&SUBCLASS_06,USB\CLASS_08"
I haven't tried loading the generic driver on my system as I'm loathe
to meddle with a working configuration, but I suspect that
"CompatibleIDs" may be the key to getting a vendor specific driver to
install as a generic one.
Joe
"Franc Zabkar" <fza...@iinternode.on.net> wrote in message
news:poaps1d809vq6i8n9...@4ax.com...
>Just out of curiosity I wanted to find out what it was about the
>generic .inf file that did the trick, so I compared it against my own.
>
>I think these lines contain the principal difference:
>
>Generic:
>
> [LexarMedia]
> %DeviceDesc%=jd.install,USB\Class_08&SubClass_06&Prot_50
>
>Mine:
>
> [USTORAGE]
> %UF1.DeviceDesc%=UF.install,USB\VID_0EA0&PID_2168
>
>It appears that the generic .inf file looks for devices that satisfy a
>particular class, subclass, and protocol ID (a particular device
>category?), whereas mine looks for a specific vendor and product ID.
My Canon USB MFC370 printer/scanner/copier has a built-in card reader.
The registry entry for this device uses the same class, subclass, and
protocol numbers as above. I believe this explains why TR was able to
use the one generic driver for both a flash drive and a card reader.
http://www.msfn.org/board/index.php?showtopic=43605
I have successfully implemented it in my PC with Win98SE.
Now I do not have to install extra driver for each USB storage device I
connect.
Joe
"Wijono Hadikusumo" <WijonoHa...@discussions.microsoft.com> wrote in
message news:8BF20EB9-9C19-4D84...@microsoft.com...