Well, there are a couple of reasons. The biggest reason for Win98 being game friendly is that it allows your games more direct access to hardware components and the drivers for Win98 are well developed. Win2K, on the other hand, puts up this protective barrier, a middleman of sorts, between your applications and the underlying hardware. All access to the hardware must go through this intermediary layer. Some games do not like having to talk to a middleman. The fact that frame rates are sometimes lower in Win2K could arise again from having this added middleman cost, as well as Win2K just itself being a more resource intensive operating system. Another reason might be that some of the drivers for win2k are not nearly as optimized as their counterparts for Win 98.
Well, not exactly. SFC runs pretty much at the same layer as most of your games. When I say layer what I really mean is levels of access. To better visuallize this, draw a small circle on a piece of paper, and label that as hardware. inside this circle resides all of the hardware components -- CDROMs, CPUs, RAM, HDs, etc.. Now draw another circle outside of that, and label it as the Hardware Abstraction Layer. This is the middleman. Outside of that, draw another concentric circle, and label it as Applications. This is the ring in which most of your apps will be running. This is a greatly simplified view of the actual number of layers involved. But it gives you a good idea.
The rules of this game are simple. A process in your system can communicate only with other processes that reside within the same ring as it self, and with rings adjacent to it. What this implies is that your user level application can talk with other user level applications, and can talk to processes/apps residing within the HAL ring. But, it cannot talk to the hardware directly. The HAL can talk to everyone. What the HAL does is to accept hardware access requests from the user level application and to pass those requests (assuming they are valid and not dangerous to system stability) to the hardware. The hardware then responds to the HAL and the HAL pases the response back up to the user level application.
Seems like alot of trouble to gain very little. But there are actually a few very good reasons for doing this. First, as I've already somewhat alluded to, it helps to improve system stability. By preventing arbitrary access to the hardware by any arbitrary set of user processes, the HAL effectively enforces a set of usage policies designed to ensure maximum stability and security for the system. Another advantage is portability. Suppose Microsoft decides to port Windows XP over to the SUN machines, or the Mac (like that'll ever happen). Without the HAL, a large amount of code in the operating system must be rewritten to communicate with the new set of hardware devices and talk to the processor and other system components in the language defined by that platform. However, if a HAL is present, then all we need to do is to reprogram the HAL to talk to the underlying hardware, and anything that uses the HAL can still talk to the HAL the same way it did before. It makes porting a lot easier to deal with.
I use Windows 98 SE, Windows 2000, and Windows XP Professional. With my old Pentium III-600 system, I've found that Windows 98 SE is far better for gaming, some older drivers actually working better than mmore recent versions. But I suspect it's mainly because drivers are now optimized to work with Windows 2000 and XP's Hardware Abstraction Layer (HAL), the middleman referred by Xinli. The HAL only functions correctly with fully ACPI (Advanced Configuration Power Interface)-compliant motherboards. My old 440 bx is only partially compliant, and Windows 2000 and XP Pro show in Device Manager as Standard PC vs. ACPI installations.
Look in Device Manager and double-click or expand Computer. If it shows as ACPI, then the latest drivers should work very well for you in a gaming environment, even with Windows 2000.