dencorso

This is an old hardware issue, but one that remains with us. Most manufacturers (at least Microsoft, Logitech and Razer, but probably most others, too), if not all, use Omron D2FC-F-7N microswitches in their mouses, at least for the two classical upper buttons, and usually for all buttons in many-buttoned mice. So the Omron D2FC-F-7N became a de-facto standard (for instance, see the pic collection here). This is a good and sensitive microswitch, based on a single-piece copper-plated steel leaf-spring, which, however wears out due to material fatigue, and starts to behave unreliably. Since it's, by far, *the* most used mouse button, the left upper button is usually the one in which the problem manifests itself, causing double-clicks to occur when one tries to single-click. There are various solutions around the net for this problem, assuming one does not want to replace the mouse: 1) Of course, the definitive one is to substitute the misbehaving microswitch. Since the Omron D2FC-F-7N microswitches are available on e-Bay for under US$5 a pair, that's the solution I favor, and have used to keep my three Intellimouse Optical v 1.1 mice working (I have already substituted the left upper button microswitch twice in each of them, and still have not seen the problem happen with any of the other buttons). 2) Then, there is the leaf-spring remove-retension-reinstall solution, which is pretty well described here (how to fix the 'double-click' problem on your G7 mouse), but which I was never able to do (all I accomplished was to make the already bad microswitch completely unresponsive). If one manages to perform it correctly, it should prolong the life of the microswitch somewhat. 3) Finally, there's an interim software solution, which really helps overcome the double-clicking on single-clicking issue, in its initial stages, although it gets innefective as the spring gets worse. This is the freeware program MouseFix (direct download), by Daniel Jackson. His MouseFix page (please scroll way down) is worthy of reading, and also offers the program's source code. The usual way of running MouseFix is simply to add a link it to the Startup folder in the Start Menu... however, since MouseFix hooks one of the mouse events, this leads to the cursor becoming unresponsive at times, due to it being run at Normal priority. My solution is to set it to High or, even better, RealTime priority. To do this automatically on startup, edit the Target field in the link to MouseFix, so that it becomes: C:\WINDOWS\system32\cmd.exe /c start "" /B /REALTIME "C:\Program Files\MouseFix\MouseFix.exe"if your copy of MouseFix is at C:\Program Files\MouseFix\, or adjust the drive and path as needed, and set the Run field to Minimized. This'll start MouseFix with RealTime priority, eliminating all unresponsiveness. BTW, there's KB266738 (and its 2003 version), but IMO that MS document induces one to check many things pointlessly, inspiring false hopes, before coming round to realize it, in fact, is a hardware problem. There's also a still open thead, from 2005, at neowin about it, and I cite it here as one of sources of part of the info above, and for its historical value.

While increasing the VCache up to 384MiB actually improves the overall system performance, it seems to improve no more, by increasing it beyond 384MiB. This is the result of tests I've done in my own machine and in those others is serviced (now there is only one besides mine, but once they were 12). I'd have to dig into very old records to find actual data to show you. Those machines had up to 1 GiB RAM, besides my own which began with 512 MiB and now has 3 GiB. Gape reached the same conclusion independently, and added that tweak to his uSP (v. 2.1a), although he seems to have removed it in later versions. RLoew patches VCache.VxD to allow for a maximum of 512 MiB (instead of the MS default valuer of 800 MiB, which does cause problems). Yet, I think sticking to 384 MiB preserves precious system arena memory for other uses. One good test of how full your system arena is, is how many DOS boxes can you open: if you can open all 64 and get the expected BSOD (Page Fault) on trying to open the 65th, then you've got plenty of space, but if not, you'll not get a BSOD, but instead of it a "There is not enough memory available to run this program" message. Of course, all this is a bit academic, since I cannot envisage any use for, say 16 DOS boxes open at the same time, let alone 64. Now, what is not academic is the need for Usher's fix for safe mode even with Win ME... be sure to edit your SYSTEM.CB accordingly, and while you're at it you might as well add Tihiy's 800x600 driver for safe mode (that's whence Usher got the idea for his fix), for which there's a pointer in Usher's first post.

Added under "Supported Software, Games + Hardware": * Asus Eee PC and Windows 9x: http://www.msfn.org/board/index.php?showtopic=122401 More than 6 months had elapsed without a new post, so I moved it here.

It makes sense. And unclutters the system arena, at the same time. So now I think that 32 MiB of AGP aperture and MaxFileCache=393216 (= 384MiB) ought to be the optimal setting for your system. I hadn't stopped to reflect upon values for the AGP aperture in a long time... thanks for the opportunity to do it now: things seem much clearer to me at this point. You rock!

For old cards with much less memory, that was the bottom line for good performance: the aperture should not be less than onboard memory. However, lots of discussions in various forums over time conviced me that more than the same amount of RAM onboard is rarely used. In fact 128 MiB seems to me to be the best value for >= 128 MiB of onboard RAM (which really means 128 MiB and 256 MiB, since I've no personal experience with boards having more than 128 MiB, up to now). I use an aperture of 64 MiB with a 32 MiB GeForce2, while Dave-H uses 32 MiB with a 256 MiB board, without problems, so it seems the aperture is really needed less and less, as the board has more and more RAM onboard... You may be right. In any case, if used, the aperture will use up memory in the system arena, so that the less you set for it, the less it can take out, if and when actually used.

Possibly. Let's test it further: return VCache and the AGP aperture to their previous values and lets see what happens... It all remains normal it was gearaspi.vxd all right, and you've nailed it. After that's settled, I'd recommend keeping the aperture 128 MiB (that is: equal to the amount of RAM in the video board, up to 128 MiB or, as in your case, 128 MiB regardless, if you have more than 128 MiB) but reducing VCache to 393216 (= 384MiB). Gape found it first, but I've tested it for a long time, and never found a situation where more is proven to be needed.

Too big a VCache, too many open DOS Boxes, too big an AGP aperture, or a big (> 512 MiB) XMS ramdisk being filled are the most probable reasons for depletion of the system arena,as well as any combination of the above factors. Igor Leyko's article, the "Maximum Number of DOS Boxes retired MSKB article and RLoew's posts included in the noteworthy posts list, all of them in the in the 1st post of the > 1GiB thread are references worthy of reading and musing about, in relation to this issue. Do you, perchance, use Frank Uberto's XMSDSK or any other ramdisk that relies on XMS?

It may. Go to any flash content and right-click on it, then select "Settings" and disable Display hardware acceleration, on the set-up that's crashing. That may solve it. BTW, 10.3.181.14 is out, already.

So many questions. [scanty an answer]... You remind me of Brecht's "Questions from a Reading Worker"... Now, that said... @LudwigVCK: submix8c is right on the mark! So, please do provide *detailed* specifics. Without them, no help is possible. And all our crystall balls are out for maintenance, so don't count on them, either.

Of course there is a way... I can consolidate the previous threads into one. But that would create a huge thread. So I don't know for sure whether it's such a good idea. Do please post a list of previous threads you think would fit in. Then we can decide what's the best course to adopt.

So, getting the "legitcheck.hta" is not really necessary? Great!

Version 12 is useless for 9x/ME, but sure one can download it. Read this.

jaclaz already pointed you to the correct solution: Whether you'll use it or not is up to you, and you alone (and if you do, you'll do it on your sole responsibility, not because any of us said so!).

That's gora (жора, in Russian), and he's a MSFN member, too. He's been doing a great work!

And use Anolis Resourcer to do it. It's way more reliable than ResHacker.

A new antenna won't help but a Wireless Booster shall.

Thanks to jaclaz, who found it (why do you think he's known as "The Finder"?), here's the first publish, still little tested or untested procedure for 7200.12 not detected by the BIOS. PS: Yes, this is a merged and heavily cleansed up collection of threads, consolidated in one... I did my best to remove the irrelevant materials to make it less long winded and more to the point.

Asia - Only Time Will Tell

How come you forgot to include our very own Unofficial ClamWin patch for Win98SE by aru? I'm begining to think the best way to get something totally unnoticed is to stickify it! That said, thanks for your hard work! You rock!

Yeah. But it works like clockwork.

Sorry for chiming in so late. Which are you using? Romexsoft or Dataram? In any case, both work for 32-bits and are free, but only Dataram is free for 64-bits. Yet another option is the Gavotte Ramdisk, which is free, too, both in the 32-bits and 64-bits version, and will use more than 4 GiB, besides letting you set the drive letter, although it's a little less easy to set up.

This being the case, cannie's tutorials may be of interest to you: How to install Windows 98 in modern motherboards using more than 1 GB How to create easily a second Win98/XP in the same computer Optimize your HDD, duplicate Windows 7 into it using KNOPPIX

Ditto!