Drugwash

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.

Another undocumented offset? The patcher is not meant as an in-depth analyser but the code that reads the VI from LE files can be ported over and enhanced. But first things first.

You forgot about Shutdown Patcher which can read VersionInfo from VXDs equally well. Ahem, almost equally well because I did stumble into that duplicate label issue and left it as is (since none of the nvcore drivers suffer from it). But with a little help from my friends I could fix it and maybe port the code to a standalone GUI application. B)

Thank your for continued testing and feedback! Problem with empty selection is yet a mystery - either a bug in the AHK interpretor or a misunderstanding of the behavior on my part. Thing is, if the corresponding entry in the ini is blank, the default value that should be automatically substituted by the script doesn't kick in. So I have to double-check if the entry is empty and force a default value again. Plus the usage of a variable that was reinitialized after being set. No big deal but still disturbing as I know it used to work. Version 1.5.1.0 was not announced due to a few display issues under Win95 which I'm trying to solve at the moment. Everything should work fine under 98 and later though. Sorry for the ME bug, it was a tiny but critical overlook when copy/pasting code between sections. Glad it works for you now. A new version will be announced as soon as I sort these 95-related problems out.

Tihiy, maybe to make everyone happy you could add a suboption to the update notifier, something like: [_] Also notify of beta/RC/minor updates It will then be people's choice whether to follow and install such versions, reagrdless of whether they already are on beta/minor channel or not.

They must've adjusted the compatibility list sometime these days - I'm 99% positive I saw 98/ME up there when downloading 5.4 following your announcement above. In that case there's nothing we can do. Another one bites the dust…

Glad you got things sorted out. And of course, to each their own so if this application pleases you then everything's fine. BTW, I created a VC6 language project from the VS2013 one using prjconverter but for building a working language library the respective translated .rc file is required. It may still need some tweaking (output is 164kB compared to original 151kB). If anyone wants the .dsp/.dsw files just wave your hand or whistle.

Since many years ago I have something against that application. Can't say what it is - maybe the ugly icon, maybe something else. I've installed it now though, to test in regard to your problem. First thing that caught my eye was a default plug-in, the first one listed in the plug-ins window: ANSI2UNICODE.DLL. That one may have to be checked/uninstalled when testing under 9x. Second thing was the checkbox saying "Load Unicode PlugIn at program start [...]" when opening the Language item in Properties (Main Menu > Options > Change language). Now, apparently the main app can't load the respective German language file even in Default compatibility mode, regardless of the state of the aforementioned checkbox. Disabling kernel extensions had an immediate negative effect on the toolbar icons, corrupting them. German language library still can't be loaded. Changind compatibility mode to Windows 98SE allowed the German language to load, but the icons were much more corrupted than before. First half of them illegible - luckily there are tooltips. In Windows2000 compatibility language file is loaded and toolbar icons appear correctly. Functionality untested. Loading Romanian translation with KernelEx extensions disabled was succesful, but icons are still corrupted. Language file is old 4.37 version. Changing KernelEx to Default compatibility mode fixed the icons issue and language is still loaded. I would conclude that the language SDK for the current version may need some tweaking or at least a VC6-compatible project be derived from the current VS2013 project and language files be compiled under Win9x and VC6 for full ANSI compatibility. But that has to be done on the user side. P.S. I still hate IrfanView and I still don't know why... (I can't live without typos…)