Drugwash

Oh, my apologies - somehow I missed the fact that it is a laptop not a desktop, so installing a regular network card would not be possible. A PCMCIA card would do, but it has to be compatible in terms of drivers. Hopefully it will be. Apparently this time the installation of the XUSBSUPP package went fine, but just as a double-check, could you please verify the version numbers and dates in the driver files listed by Device Manager and compare them to those of the files included with the XUSBSUPP package? That would certify (or not) the succesful installation. One thing to mention is the device may require external power in order to be properly detected/operated. Some devices may work only with the power provided by the USB hub but that depends on many factors. One other thing is the device may be backwards compatible with USB 1.1 but not with 1.0 (if the laptop only has 1.0 USB then that may be the issue). Lone Crusader should know more about the drivers' compatibility with such external drives/enclosures.

Not to shift the topic or anything but until the USB issue gets fixed somehow wouldn't it be a good alternative networking the Win95 machine via cable with any nearest machine for this file transfer? An (old) network card could be found and installed (if not already present) along with its drivers - Realtek 80xx-81xx do have drivers for all OS versions starting with DOS, AFAIK - and the shared folder(s) or partition(s) could be read and written to by any other Windows version. This would also eliminate the wear of the USB devices and cut at least into half the transfer time. That said, in order to completely eliminate any driver that interferes with USB, you'd have to: - find out the exact VendorID and ProductID of the Intel 82371 AB/EB/MB UHCI controller by looking in the registry or using any device detecting tool (such as my HDDB - see signature below) - perform a search for the text VEN_xxxx&DEV_yyyy in the Windows INF folder and its subfolders (where xxxx and yyyy are the found VendorID and ProductID, respectively) - remove the found file(s) or change their extension(s) to something bogus like .000 - remove the unknown device(s) from Device Manager and follow the rest of the procedure as explained above by LoneCrusader Good luck!

Just trying to help when/if possible. Thinking deeper, a radio interference would most likely disturb reception with any other keyboard brand/model since the band allocated for bluetooth communications is essentially the same. Therefore I'd be inclined to believe that particular keyboard model/series may have a design fault (uneven pressure on PCB breaking or unsoldering connections/terminals) or may employ low quality components that changed characteristics in time (such as bad capacitors that dried out, out-of-specs quartz oscillator, bad silicon chip, bad silicon connector between keyboard foils and PCB and so on). If I were you, just out of curiosity I'd carefully dismantle the apparently dead keyboard looking for any visible signs of failure: tiny cracks in the PCB, oxidated contacts for batteries or at the foils+PCB contact zone, eroded tracks on the foils etc. I haven't dismantled such wireless keyboard before so I don't know how the transmitter block looks like but there may be something to look for in there too if it's not completely sealed - just don't move/bend components in there (especially coils, if any). Just don't blame me if you break anything.

Mikl, to rule out the possibility for the PS/2 port itself to be defective you should connect and test a true PS/2 keyboard. In fact you should always have one in the house - as a backup, for testing purposes, whatever. There may be other subtle issues that have not been mentioned: - BIOS behaving inconsistently due to (partial) incompatibility with the USB-to-PS/2 adapter, occasionally leading to faulty detection of the keyboard. - Loose contacts in either the motherboard PS/2 socket or the adapter's internals. - Voltage variations (or constant over/under-power) at the PS/2 port that affect either the adapter, the receiver or both. - Recent replacement or installation of home appliances that may produce radio interference (anything with wireless capabilities). - Outdoor installation of powerful wireless equipment near to your house/apartment. - The keyboards themselves having been programmed to self-destruct after a designated period of time. Anybody else please feel free to chime in with other possible reasons for that hardware setup to fail according to the description.

Yeah, we often assume people know the basics but sometimes they don't. Other times it's much more complicated although it appears to be extremely simple. Go figure!

Don't make me use the hammer on the remaining adapter. PS/2 works through +Vcc, GND, CLK, Data while USB works through +Vcc, GND, Data+, Data-. There has to be an active conversion of the signals, otherwise why bother to designate different sockets for same signals!? But yes, apparently the keyboard itself in this case is failing or maybe the batteries are bad or contacts are rusty.

Dunno, never had one and probably wouldn't have it for long because at the first sign of malfunction I'd smash it into pieces. I'm very happy with my three 20+ years old IBM Model M keyboards, they never miss a keypress and have veeeery long curled cords. B)

If you're using the DVI connection it's possible that the EDID is not correctly read or processed by 98SE. I've had a hard time getting a Hanns-G Hi221 monitor work at native resolution (1680x1050) even under XP-SP3 because of this and had to create custom resolutions in NVIDIA's control panel despite having installed the very-hard-to-find driver, so installing a driver may or may not work for you but you'll have to try this just to be sure. Just change signature to "$CHICAGO$", comment out the services sections as they don't exist in 9x and you're all set. I believe there are tools that can modify a monitor's EDID data through reflashing but it's a complicated and dangerous operation so I wouldn't advise to try that unless you can afford to lose the monitor.

Sorry for the late reply, timezone's fault (and my cat's too). I'm afraid you misunderstood the utility of the tool. It does not search the web for drivers - it merely reads the registry and displays the information found in there. It's possible that Win95 behaves a little differently than 98 and later. When devices are detected and no drivers are found for them, those devices should appear as 'Unknown device' in their corresponding sections. Their VID & PID or VEN & DEV, if known, will be displayed below as a hint for the user so they know what drivers to look for. When an Internet connection already exists, the application tries to silently download the current vendor and device ID database from www.pcidatabase.com (may not be the most up-to-date list though and behavior may change in subsequent application versions) in order to be able to provide the aforementioned feedback. If there is no Internet connection, the application will use an internal database or - if previously downloaded - the database (VendorID_DB.txt) found in application's folder. The USB_devices.txt database is not updated currently.

It's not much but you're welcome. I'd be curious if my tool works correctly (or at all) under Win95. I haven't tested it there. If you want to give it a try, it's in the cloud repository found in my signature below (look for the HDDB folder). Hope you have 7-zip installed to unpack the archive. If it works it should connect to the web for a database update then present you with the GUI. Select categories to the left - most important are PCI and USB - and look for 'Unknown device' in the right-hand list. Select them and you'll see registry details at the top while at the bottom in the VID/PID - VEN/DEV area there should be details on the selected item, if available. It still needs some work but it's quite useful as it is for the moment. Hope it works for you. There's a document on the web - ds511u.pdf - that lists the specs for this notebook but it's not much useful information in there. Hard to find a real manual or drivers nowadays - many sites promise everything and deliver nothing at best. Good luck!

I currently have one spare 98SE system but it's acting as storage target for web downloads (all my other HDDs are full up to the brim) and can't play much with it. But for some limited testing I guess I could bite the bullet. System HDD is an ancient 1.2GB Quantum and I shouldn't upset it too much. As for file versions they probably followed the golden rule "if it ain't broken, don't fix it" and just ported it over from 98Gold. Only that it kinda was broken but they didn't envision such heavy usage at the time.

That is good news! It's been a long weekend… However, how thoroughly have you tested the impact of replacing those libraries on the whole system? There is always a possibility that older applications/installers may not behave correctly if the new libraries contain more than bugfixes. My commctrl.dll is v4.10.1998 while setupx.dll is v4.10.2222. DRVIDX.BIN is only 1,320,970 bytes and this system is 9 (nine) years old. DRVDATA.BIN is 387,034 bytes. Both the above go hand in hand (wasn't it a much larger discussion on this?) Anyway, thanks for working on this and finding a fix.

You really need to narrow the issue down to either the adapter, the receiver or both. There may be intermitent failure due to overheating, over/under-power, momentary high current drain due to bad reception, bad components and so on. I know those adapters, incidentally I gave one away to a friend yesterday. I had two of them and they both have a tiny mouse embossed near the PS/2 side, which means there is a possiblity that a keyboard may not (correctly) function with such adapter. Try to look closely at all your adapters, see if they have different signs on them. if you find the right compatible HID drivers you may try to connect the receiver directly to an USB port, if available, see if it works reliably that way. It's possible that neither the adapter(s) nor the receiver(s) are bad but a momentary overcurrent due to bad reception could trigger a PS/2 port protection of some sort (probably built into BIOS) that would lead to the behavior you described.

According to my (incomplete) detection application HDDB: - 1002/4341 --> Advanced Micro Devices, Inc. (AMD) AC'97 Audio Controller (the SUBSYS part may futher indicate model or other details) - 104C/8201 --> Texas Instruments TI UltraMedia Firmware Loader Device (could be the 5-in-1 card reader) - 049F/0086 --> Compaq HP nx7000 (USB device, apparently) The laptop/notebook was designed for and shipped with XP-Home Edition. Best bet would be for you to get the whole set of XP drivers for it, unpack them and look inside the infs for any details (usually in the Strings sections) to find out exactly what all the devices are called and then hunt for any corresponding 95-compatible drivers if available. Prepare yourself to be dissapointed, however.

Wireless keyboard? That has nothing to do with the PS/2 keyboard controller unless the receiver connects to the PS/2 port, something I've never heard of yet. So you should look into the (most likely) USB receiver, replace it if possible (at least temporarily). Now, if by chance the receiver does connect to the PS/2 port, first of all try to completely power off the machine and pull the power cord off (or toggle the power switch on the PSU if there is one). Let it rest for a minute or two, then power it back on. In the mean time replace the batteries on the keyboard(s), make sure they are fully charged and contacts are not rusty. If it still exhibits the unwanted behavior, then it is possible that the keyboard controller is bad. You may try a BIOS reset if you like, just make sure you type down all the current settings and after reset you set them back as they were, otherwise resources may be assigned differently and the OS may not like it. If you suspect there may have been a virus, you may also try to reflash the BIOS if you have a 100% guaranteed working BIOS image for that board and all the needed tools. But be extremely careful - I flashed the wrong image on a board (although it was original but for a different RTC on same mobo version) and bricked it. You've been warned!

You mean a large and heavy hammer…

You may have to edit and install the drivers provided by Dell. And while at that, tell the id!ots at Dell that "installation" (in Source Disk Names section) has two As so they should better revise their inf files in the package. Honestly, I wouldn't buy Dell - all my experience with such hardware was at least frustrating but mostly aggravating. And limiting a MONITOR (!!!) usage to a narrow range of operating systems is simply moronic.

Yeah, but they're not remotely controlled and forced to do that against their will. But then again, when the refrigerator or coffee machine get their own will, we humans are screwed.

Wait until your own house gets mad at you for some reason and refuses to cook you breakfast, make coffee, do the laundry and so on and so forth! Pretty eloquent example in some episodes of "Eureka" when S.A.R.A.H. the smart house gets offended or - worse - IT virus-infected. Smart people will then flee to the third-world countries where everything gets done manually and you have total control over what happens. But will there still be any such countries by then, or everything everywhere will be digitally controlled…?

Well, M$ as always have been trying to minimalize things (and Intel follows suit). At the time, I was trying to update the video driver for my card in order to be able to play one of the 'Tomb raider' series games and that game was unable to detect available resolutions/color depth and other video-related options because of misfit drivers. So the driver does matter a lot. Anyway, I offered this personal example more on the lines of "if that visible issue happened, who knows what other hidden issues may arise with a misfit driver". Mouse lag included. So certain tests are required in order to narrow down or pinpoint the issue. Nonetheless, thank you for taking the time to search and publish the links above. (fingers pressing buttons when brains are not there…)

Maybe related or maybe not: what brand exactly is your videocard? I'm asking because I have such card myself, the Ti4200 AGP8X model made by MSI and the latest driver I could use is the MSI-provided 45.32 from their site. Any official NVIDIA driver later than that would completely disable AGP texture (check in DxDiag if yours is enabled). It's possible that this particular card model and/or particular manufacturers may require specific drivers to function properly. Therefore my advice would be for you to check if there are any manufacturer-specific drivers for your card model at the manufacturer's site and perform a test with those. Or if you have the original drivers CD you could try those too, if only to rule out this possible issue. I'm using my card with the MSI 45.32 drivers on an 667MHz Pentium III (+KernelEx 4.5.2, AutoPatcher98 with updated DirectX 9.0c, RP9.7.2 and many other updates) on a Yakumo 17XF8 TFT monitor and there is no lag whatsoever, the cursor is stuck where it should be when dragging windows around. Granted it's a VGA connection, not DVI.

Which driver version is installed on the faulty machine? This info is needed so I can adjust the code in the ini. Would that be the same code in sections 8b (98SE wide) of the patcher? I've just released v1.5.2.2 which fixes a regression in the ini related to Win95 versions (code was erroneously moved from section 6a to 4a for driver v81.98). I've also uploaded a separate test ini for Mikl. The code is in the Generic section. In the patcher select 'Private' from the dropdown, it should work.

There's a new version up: 1.5.2.1. Hopefully the logo color issue in Win95 is fixed and now there's a safety net for systems that don't have Tahoma installed (does anyone know other free font that looks legible at 6-7pt?) No changes to the patch code since 1.5.1.0. Some improvements in OS version/type detection and automatic selection. Minor improvements to main GUI information text, Win95 version range and system path. Enjoy!

Thanks both for the tip, I'll grab that header for a read as soon as I get some rest and fix the issues with the patcher.