In that case try 32 bit Server 2003 with PAE. That would essentially give you XP with multi CPU support. I don't remember how complicated, or not, it was to enable PAE, or if there was any noticeable performance loss with it.
You should also look into CPU affinity for games, because they usually suffer a performance hit when they are spread over multiple CPUs.
The shortcut that launches the game can be edited to set the CPU affinity, so task manager doesn't have to be involved every time.
@Van Darkholme, unless they are made to take advantage of more than one CPU core(Carmack made a patch for Q2 on a lark back in the day for dual socket Pentium Pro systems, Q3 might support it as well) they won't run better.
There's also the issue of modern Windows scheduling threads and where they should run so a game process might bounce around different cores without knowing it. This can become a huge problem depending on how they measure time between one frame completing and another one starting.
This is why this matters: In games, even when they lurch down to 5fps for a second or two, your character will cover the same distance in one second @5fps as they would in one second @60fps. How far something moving at 5 meters per second travels in 16ms(60fps) or 200ms(5fps) is not a tricky thing to calculate accurately, unless time becomes unreliable, maybe -279ms passed between frames, that would make the animations weird and movement would be super-jerky like a laggy online game.
RDTSC was an instruction that was often used, it returned the current cycle count of the CPU, it was very precise and fast. Upon startup the game polled the OS to get the clock speed of the CPU, that speed didn't change, then used ReaD Time Stamp Counter to determine exactly how much time passed between frames, if the CPU was 500mhz and 20 million hertz passed since the last check then the exact elapsed time between frames is known and that time value would be used for movement but also things like determining where in an animation cycle something is so it can be rendered correctly.
Even if thread scheduling isn't an issue modern CPUs have variable frequency, it clocks down to save energy and Windows will still present the CPU as so-and-so 3.6ghz but it might also boost above that, on one core or many cores at once. Counting cycles to determine time is no longer reliable for timing purposes.
It doesn't affect every game, not every game works like that, but if it is janky and weird it should be set be set to run on one core only, it usually works pretty well. PCGamingWiki also have patches for problems that isn't solved by that.
