¶Windows 95/98/ME and large amounts of memory
I still manage to find people that try running Windows 95/98/ME on modern systems. As a user, I understand that there is some software and hardware that only works on this OS series. As a programmer, I cannot wait for the day when users stop running it. The fortitude of Win9x as a protected-mode operating system ranks marginally higher than AmigaDOS and classic MacOS; it has process address space isolation, but the process databases are completely exposed at 64K-1MB and system DLLs and memory mapped files in the shared arena at 80000000-BFFFFFFF, so it's still easy to screw up the system by accident. In addition, there are a lot of useful features, such as full Unicode API support, that are only available on Windows NT based platforms. To be fair, the Windows 95 team had the Mission Impossiblesque task of bridging Win16 and Win32 on a 4MB 80386, and the success of Windows 95 had a great part in encouraging people to write Windows NT-compatible applications — but there is only so much room for duct tape in a code base.
In case you haven't heard me mention it before, those of you who have large amounts of memory (>512MB) and are still running Windows 98, 98SE, or ME may be interested an article in Microsoft's Knowledge Base called "'Out of Memory' Error Messages with Large Amounts of RAM Installed." Basically, the problem is that on a system with a lot of memory and an AGP video card, the dynamic disk cache and the AGP aperture may consume an unreasonable amount of kernel address space. Since there is only 1MB of it under Win9x, this can cause kernel space to become critically crowded. The solution is to add entries to SYSTEM.INI to limit the size of the disk cache, thus preventing the problem.
I once fielded a bug reported by a QA tester for a commercial product, claiming weird instability on a particular Windows 98 system that turned out to have 1GB of RAM installed. While blaming bug reports on the tester's system is ordinarily bad form and a really lousy way to keep your bug count down, it happened to be the right decision in this case. Reducing VCACHE's limit not only made the application bugs disappear, but also fixed some strange issues the tester had been having with his Recycle Bin. Pulling 512MB from the system had the same effect. Also, limiting VCACHE also has another benefit in that it reduces the dynamic disk cache's tendency to swap everything out of memory when a lot of files are read, even if those files aren't going to be read more than once. I thus highly recommend applying the [VCache] MaxFileCache=n change.
As a side note, a poster on the forum recently helped me track down an irritating bug in VirtualDub's draggable video frames that was causing some instability on Win9x platforms. It happened because of a code fragment that I adapted from the MSDN Library documentation for WM_NCPAINT that supposedly helps you draw custom window frames. Well, the code fragment as given doesn't work, because it lacks an essential flag. GetDCEx() simply returns NULL and leaves the error code as NO_ERROR. You need to add 0x10000, called "an undocumented flag which can magically make GetDCEx call succeed" in Feng Yuan's GDI book, or DCX_USESTYLE by WINE, for the function to actually return a usable DC. It turns out that there is an even worse problem with the code as given because it causes window regions to be doubly freed! On Win9x, this results in an occasional crash in 16-bit GDI. (This particular problem with the WM_NCPAINT example is also colorfully documented in comments in the WINE source code.) After I fixed this issue, the poster's problem went away. So if you are using a Win9x platform, expect some stability improvements in edit mode in 1.6.4.