Drugwash

I like this phrasing. Looks like Microsoft are already dead but they don't know it yet. Why don't we help them cross over 'Ghost whisperer' style…? JorgeA above has a point, for one.

I've got usbccgp.sys v5.1.2600.5585 on my trusty old 98SE machine. There's also usbport.sys v5.0.2195.5652 and usbehci.sys v5.0.2195.6882. The hub driver is usbhub.sys v4.90.3002.1. Related may also be usbntmap.sys 4.90.3000, usbstor v4.90.3000.1, usbd.sys v4.90.3000.1, usbauth.sys v4.90.3000.1 and a shady usbu2a.sys v1.42. Used to have MS usbhub20.sys v5.0.2195.6891 which I recently replaced with VIA's 4.90.3000.11. They both work(ed) fine with the built-in VIA Tech 3038 USB 1.1 controller and the VIA VT6202 USB 2.0 add-in card. But maybe my SOYO SY-6VBA133 motherboard is more resiliant to drivers than other boards, especially the new ones.

Guess this topic could be nicknamed The (Windows) X files.

Someone at their high quarters must definitely be a Highlander series fan: "There can be only One!!!" Of them all above, OneShot seems the most appropriate for Micro$oft. In the head!

No. The motivation was and is seamless integration of advertising into everything, confusing users and luring them into clicking at random, thus rising the chances of getting more revenue by means of click count, referred purchases or whatever. Why does Windows 10 need constant updates? Because the advertising elements embedded in the code have to be replaced every now and then. Simple! It's all about the money, it has always been about the money. The user doesn't count for sh.. in this equation.

You're welcome!

Now we're talkin'! There's one particular quote în the last link's article that I'd like to emphasize: Considering in this particular situation Win98SE can do that resolution I'd say we're out of the woods regarding a bad video BIOS, but for anyone else having a similar issue with another chipset/video this may be useful information. That article has a lot of technical information that's quite hard to hack together even by a knowledgeable person. I wonder what happened to old-school programmers that had the WinAPI at the tip of their fingers…

I wouldn't call them very clever as long as they use .NET, but that's just a personal opinion. The image in the 7-zip archive is clearly 1400x1050. So definitely something interfered with the image size attached to the board but that's not even important anymore. Problem was and remains making XP allow a non-standard resolution of 1400x1050 in full screen, which requires manually overriding the EDID. The tool referred to by jaclaz may do the job but I, for one, wouldn't install .NET just to run that thing. To each their own though. Good luck!

Well, I'm sure something tampered with your first screenshot because what I saved here on my HDD is 93,538 bytes while the size seen in one of your later screenshots (in MS Paint) shows 132,886 bytes. If the board software does this automatically, this is very bad. OK, now that we figured this out and also seeing the EDID report, I can say that Win98SE is much more tolerant with respect to unsupported resolutions, while XP is strict to a T and will not allow any unsupported resolution other than in pan-and-scan mode. So I guess you'll have to find an XP driver that can force a non-standard full screen resolution. Unfortunately I have no experience with Intel drivers so can't help here. Hopefully someone else can.

There's a multiple-model manual here containing technical details towards the end. Not of much use, in my opinion. 1400 x1050 reported by the control panel is a clean 4/3 ratio. 1200 x 900 of the real screenshot is also a clean 4/3 ratio. The fact that the control panel reports a resolution while in reality it is a different one could be anybody's fault but I'm inclined to point to the drivers who may use a built-in flat panel scaling capability that I've seen in NVIDIA's drivers. If such option exists, it should be set to use display's built-in scaling, not driver's.

The picture you uploaded is 1200 x 900, despite the control panel reporting 1400 x 1050. Hm, this is getting weird. According to the manual, the monitor has both DVI and D-SUB input - which one are you actually using? Regardless, try the other video output/input if your videocard allows. If you have DVI-out on the motherboard you may also try using an adapter with a D-SUB cable to connect to monitor's VGA input. Please make sure the video cables are in perfect shape - if possible, replace them at least temporarily. All this is to test if any of your monitor's inputs fails to report the correct EDID data to the driver. There's been some talk about the EDID issue even recently, you may search the board. There's also at least a free application that can build an inf from the monitor's EDID. The inf can then be manually edited if anything's wrong. Of course, there's always the possibility that some fault lies in the video BIOS If the motherboard has an AGP or PCI-e slot you may try with an external videocard. If it works then you know it's the built-in video's fault. Let's not forget the drivers - both 98 and XP ones - which may be the latest but not the best fit. Try older driver versions, if possible.

I've been into electronics for about 37 years. At this point I'd rather replace the microswitches a dozen times than replace my favorite mice. Which are all ball-based, with Logitech chips. One of them is my first ever mouse, more than 15 years old and it's got a twin brother: model M-S35. Wouldn't trade them for golden mice the same weight. Just sayin'.

I just got proof that, after all, we still are human… Glad things got sorted out in the end. And… enjoy your favorite music!

You may be right, I just looked at the Activex/OCX tab offered by the FileInfo plug-in in Total Commander, without actually checking whether registration is available. My bad! However, I see: dispinterface ITextDocument dispinterface ITextRange dispinterface ITextSelection dispinterface ITextFont dispinterface ITextPara dispinterface ITextStoryRanges as references and typedefs for a tom library, that would suggest a COM interface. I'm not familiar with COM though.

Before moving/renaming riched20.dll you probably should've unregistered it (regsvr32 /u riched20.dll at a command prompt in C:\WINDOWS\SYSTEM). If you decide to put back the originals don't forget to manually register the original riched20.dll. A reboot may also be in order after unregistering/moving/registering the files but it's only a hunch.

Might be an incompatible LOGFONT structure being passed to CreateFont().

Well, what's the actual aim (pun intended): communicate over a certain IM network or just have a certain software work?

On my system there's: riched.dll 4.00.834.839 (240,955 bytes, 2000.06.08) riched32.dll 5.0.1461.82 (212,992 bytes, 2000.06.08, apparently from MS Exchange SP4) riched20.dll 5.30.23.1230 (433,664 bytes, 2008.04.14 - last one I know in the 3.0 series, unknown source). usp10.dll 1.0420.2600.5512 (406,016 bytes, 2008.04.14, XP-SP3). Of them all, only riched20.dll appears to be an ActiveX control which needs to be registered. The only variant of 5.30.23.1200 I have is the 421,888 bytes one. The versions that come with Office (2003 and later) are v5.0 (5.50.xxx.xxx) and may not be suitable for system-wide usage.

I just connected to AIM using an older version of Miranda IM (0.10.15.0) on 98SE. Not sure if it still works in Win95 but it's worth a check. Possibly an even older (in the 0.9 or 0.8 version series) might work. I lost contact with the development years ago so can't tell anything for sure. Links for executables and sources: version 0.7.19, versions 0.8.0 to 0.8.27, versions 0.9.0 to 0.9.52, versions 0.10.0 to 0.10.14: http://code.google.com/p/miranda/downloads/list?can=1&q= versions 0.10.15 to 0.10.24: http://files.miranda-im.org/stable/ versions 0.10.24 to 0.10.39: http://sourceforge.net/projects/miranda/files/miranda-im/

Sounds like you wanna do everything by the book. I haven't checked the inf in the package but it's possible it may abort installation either if any of the current files' version is equal or greater than the ones in package or if any of the target files is missing. At least the former seems to be true, according to your report above. So unless you really need that update to be present in the updates list, a manual update may be the easiest route. Riched32.dll can be updated in place by overwriting it manually with the one from the update package (make sure no applications are running that may have it loaded or the overwite will fail). You may manually update all three files if you suspect they may have been tampered with or may otherwise be unsafe. Of course it's best to have all three current files backed up beforehand, just for safety.

This riched20.dll issue is a can of worms. Some years ago I performed a few limited, empirical tests and found out certain versions to behave erroneously in certain situations. Can't remember if I ever found the best of them all, but in the mean time more versions came up. Right now I have about 17 versions all in all, of which two may or may not be identical copies from different sources. Version numbers vary from 5.0.152.0 to 5.50.99.2014. No idea if they're all official, issued by MS or there's any mod of some kind. Also no idea which one is best and safest overall. As a rule of thumb, the second group of digits represents the RichEdit version. The 5.0.xxx.xxx is a RichEdit v2.0. From then on, 5.30.xxx.xxx is RichEdit v3.0, 5.31.xxx.xxx is RichEdit v3.1, 5.40.xxx.xxx is RichEdit v4.0 and so on. Also please note that there is a special version of the control named MSFTEDIT.DLL which is a sort of RichEdit v4.1, found in XP Media Center Edition, XP-SP2 and later. This version may be called by recent applications. So to sum it up, it doesn't matter what updates you install on your system, whether they are official or not, whether they come from an OS-specific update, another OS version or an Office version - all that matters it that it behaves correctly with most/all of your applications. And that's true for any other system files out there. Of course, whatever you do is entirely your choice.

I've been carefully reading everything in this topic so far. Even though I have not and will never be downloading and installing this POS called 'Windows 10', judging by all the comments in this topic and all other places linked to by various users, I can't help but ask myself a single burning question: WHY THE HELL DOES MICROSOFT STILL EXIST??? Sorry for shouting but this has to be yelled from the bottom of every sane people's lungs.

All the 9x-compatible "toys" that I've built are compressed with UPX and the Unicode ones are compressed with MPRESS (see the repository in my signature). My connection is metered and HDD free space is getting scarce. What now? And if I may ask, just out of curiosity: why is this Flash so important to you people that most discussions here revolve around it? I've kept it disabled on all my computers for years because I consider it one of the most dangerous technologies. Never missed it for a second. If I want access to a YouTube video I just download it through Firefox -> FlashGot -> FlashGet as MP4 and watch it offline in GOM Player. And if web designers are so limited that they can't offer regular menus/elements when no Flash is available then those pages will get blacklisted forever. Simple as that!

The more reason to shoot Microsoft in the head without trial.

Why would you be surprised? Do you think hardware manufacturers stopped providind Win9x/2000/XP drivers for newer hardware simply on a whim? They always are in agreement and they never care about the end user as long as they know there will be income. Microsoft has to go, forever. Or there will be no more computing for the average user.