No and yes.

The only 'penalty' is that you won't be using your CPU to its full potential. Aside from being able to use more (virtual) memory, 64-bit mode also gives you twice as many registers, which allows for more efficient code. Of course that requires code that is compiled for 64-bit. But even in the Vista/XP era, that was already the case. Far Cry was the first game I played in 64-bit mode back in the day, on XP x64.

Basically, I'd put a 64-bit OS on a machine like that. Because that's exactly what I did. I had XP x64, and then moved to Vista x64.
I had a multiboot installation, so I also had Windows 98SE and 32-bit XP available, but didn't really need them. All games from 2001-2009 should work fine on 64-bit OSes.

Scali wrote:

The only 'penalty' is that you won't be using your CPU to its full potential.

You never really do. MS-DOS on a 386/486/Pentium is more a less the same, a 16-bit OS on a 32-bit CPU. The CPU doesn't care, nor will the OS.

64-bit is just an extension anyway, not a fundamentally different CPU design.

If you want to use all the RAM there's also the PAE hack. You will need drivers that can deal with it though, not all are fond of more than 4GB of memory.

derSammler wrote:

You never really do. MS-DOS on a 386/486/Pentium is more a less the same, a 16-bit OS on a 32-bit CPU. The CPU doesn't care, nor will the OS.

Read again what I said: 64-bit applications can be faster than their 32-bit counterparts.
The same goes for 32-bit vs 16-bit, which is why DOS extenders became common in the early 90s.
In the mentioned period (2001-2009), various games had a 64-bit version, which gave better performance on the same hardware.
If you use a 32-bit OS, you lock yourself out of the 64-bit versions. I see no good reason for doing that.

Scali wrote:

Read again what I said: 64-bit applications can be faster than their 32-bit counterparts.

Of course. Didn't you notice that my statement agreed with that? The point is that we do this all the time anyway when e.g. using DOS on 32-bit systems. It's perfectly fine, the CPU is just not fully used. Similar to running non-MMX software on an MMX CPU, etc.

data9791 wrote:

Does anyone know of any issues I am going to run into using a primarily 64bit CPU with a 32bit XP OS?

Personally, no, I haven't' faced any issues with XP on x86-64 CPUs yet.
However, I heard some rumours of Windows 3.11 having issues with early 64-Bit PCs (native installation, no VM).
Running Windows 3.10 (non-WfW) in Standard-Mode was mentioned as a workaround.
Anyway, I never experienced issues like that on the 64-Bit PCs that I had myself in the past.

derSammler wrote:

Of course. Didn't you notice that my statement agreed with that?

No I didn't, because you can't compare DOS with Windows.
DOS is such a bare-bones OS that you can easily run a 32-bit DOS extender on top (or 64-bit in theory, although I don't think those exist). Likewise, you can use MMX or SSE just fine in DOS, even though the OS does not support it.

Windows is a full multitasking OS with virtualization and such. So you can't use any kind of extenders. If you run a 32-bit Windows, the 64-bit is out of the question. Just like if you run a non-SSE OS, then SSE is out of the question (with the exception of some hacks/limitations that were discussed in another topic earlier).

Makes me wonder, though, how more advanced DOS systems react to a recent 64-Bit CPU.
Like PC-MOS/386, Wendlin DOS, Real-32, Digital Research's line of multitasking-DOSes etc.

Since they were programmed for the bare metal, they could trigger unwanted effects with exception handling,
undocumented opcodes, reserved registers etc.

What worries me is the fact, that Intel's recent documents lack detailed explanation of rather obscure aspects of early CPU designs (286 and before).
These docs could cause Intel and others (AMD, VIA) to release new CPUs with wrong implementations of early CPU functions.
Such as Real-Mode, 16-Bit Protected-Mode, V86 etc.

Scali wrote:

Basically, I'd put a 64-bit OS on a machine like that. Because that's exactly what I did. I had XP x64, and then moved to Vista x64.
I had a multiboot installation, so I also had Windows 98SE and 32-bit XP available, but didn't really need them. All games from 2001-2009 should work fine on 64-bit OSes.

Ahh. I had heard the XP x64 was buggy and games would crash more often and wouldn't work as well.

You could say that for any OS. XP x64 is fine as long as you have drivers for it.

DosFreak wrote:

You could say that for any OS. XP x64 is fine as long as you have drivers for it.

Indeed. I ran it on some Pentium 4/D and Core2 Duo systems back in the day. Never had an issue. They all had Intel chipsets, which were supported just fine. Same with NV or AMD GPUs.
Ironically enough, Microsoft didn't have an x64 version of their mouse and keyboard software and drivers until somewhat later. The mice and keyboards still worked of course, but just as standard generic USB devices.

I think Vista was the first one where the x64 version was actually used by a significant portion of the market, so that's when all the driver and application issues were ironed out. As in: it became standard for any hardware vendor to supply both 32-bit and 64-bit drivers. And more and more applications would also become available in 64-bit.
(Makes me wonder why XP x64 has such a bad rap, considering that hardly anyone actually used it, so they aren't talking from hands-on experience)

As I said, Far Cry was the first 64-bit game afaik. Crysis also shipped with an x64 version. In both cases, the 64-bit version worked like a charm. With these huge open-world games, the extra memory meant an overall smoother experience, because the came could cache more than 2 GB of level data. Especially with high detail mode in DX10, you'd quickly run into those limits in 32-bit.
There was a 64-bit version of the Source engine, and various games using it, such as HL2 and L4D. But Valve had no clue how to optimize it, so they eventually dropped the x64 version, because they could never get it as fast as the 32-bit one. Afaik their games are still 32-bit to this day.

Scali wrote:

Windows is a full multitasking OS with virtualization and such. So you can't use any kind of extenders. If you run a 32-bit Windows, the 64-bit is out of the question.

Wrong. DOS extenders work under windows' DPMI.
You can run 64-bit guest OS under 32-bit host OS. This gives you an advantage of utilizing supported hardware and/or 32-bit host OS software.

derSammler wrote:

64-bit is just an extension anyway, not a fundamentally different CPU design.

Wrong. Can you use 64-bit code in real mode? New modes mean different CPU design. Oh, yes, it is a CPU, not something fundamentally different.

Wat. AMD literally called it's 64 bit design for x86 an extension. Intel was busy at the time creating a brand new 64 bit design with HP that flopped (itanium). Ans intel ultimately adopted amds extensions.

And 64 bit code can be slower due to 64 bit pointers and data taking up too much cache.

Ans dos extenders were about accessing more ram not cpu performance. 16bit code needes to use memory segmentation to access reasonable amounts of ram, and then ems to break out of 1mb. 32bit code running in protected mode could access all memory in a flat 4gb address space.

If you are gaming in winxp the way to do it is 32bit xp on a core2duo which is a 64bit processor, maybe dual booting with win7 64 bit for compatibility with certain emulators/gog titles that demand win7. That's how I go bout it anyway.

georgel wrote:

Wrong. DOS extenders work under windows' DPMI.

Uhh, DPMI is the "DOS Protected Mode Interface". Guess why it exists?
When an OS already has the CPU in some kind of 386+ mode, then a DOS extender can't natively 'take over' the way it does in DOS.
So instead, DPMI was introduced as a way for DOS applications to communicate with the underlying OS, and become a client of that OS' 386+ extensions.
This way a DOS-environment running under a 386+ OS can still run in a 32-bit environment. However, unlike a true DOS extender, you are not extending the guest OS, you are merely making use of its built-in functionality.

kolderman wrote:

And 64 bit code can be slower due to 64 bit pointers and data taking up too much cache.

It can be, that's why you have to optimize your code in a slightly different way.
Just recompiling your code in 64-bit mode is not necessarily as fast, let alone faster.
However, if you take away those bottlenecks (which is usually trivial if you know what you're doing... eg instead of having functions with many arguments, creating a large stackframe, you create a single struct that holds all arguments, and pass that as a single argument. And in most cases, you are working with data buffers that are less than 4 GB, so instead of using pointers, you could use a base address and 32-bit offsets to that data), then you can take advantage of the fact that 64-bit has twice the amount of registers, so you can keep more data resident, requiring less accesses to cache/memory.
In which case 64-bit code is usually a few % faster.

kolderman wrote:

Ans dos extenders were about accessing more ram not cpu performance. 16bit code needes to use memory segmentation to access reasonable amounts of ram, and then ems to break out of 1mb. 32bit code running in protected mode could access all memory in a flat 4gb address space.

It was about both.
32-bit mode on a 386 also changes the addressing mode, allowing free use of all registers, where real mode had only a select few combinations... Eg: [bx+si]/[bx+di], but not any other registers such as ax, cx or dx.
Obviously, the fact that all registers were now 32-bit (without having to use an extra prefix byte on every instruction) was also a performance gain.
Not to mention that even within the 1mb limit it is more efficient to have linear addressing than having to use 64k segment + offsets, and switching them around all the time.

Scali wrote:

Uhh, DPMI is the "DOS Protected Mode Interface". Guess why it exists? When an OS already has the CPU in some kind of 386+ mode, […]
Show full quote

georgel wrote:

Wrong. DOS extenders work under windows' DPMI.

Uhh, DPMI is the "DOS Protected Mode Interface". Guess why it exists?
When an OS already has the CPU in some kind of 386+ mode, then a DOS extender can't natively 'take over' the way it does in DOS.
So instead, DPMI was introduced as a way for DOS applications to communicate with the underlying OS, and become a client of that OS' 386+ extensions.
This way a DOS-environment running under a 386+ OS can still run in a 32-bit environment. However, unlike a true DOS extender, you are not extending the guest OS, you are merely making use of its built-in functionality.

I thought DPMI simply standardized the interface used by DOS extenders, i.e. basically how they make system calls back to DOS. Win95s VDMs provided a DPMI compatible interface so programs requiring extenders could run, although it did not simply pass the calls back to DOS, but Win95 itself could handle them.

kolderman wrote:

I thought DPMI simply standardized the interface used by DOS extenders, i.e. basically how they make system calls back to DOS. Win95s VDMs provided a DPMI compatible interface so programs requiring extenders could run, although it did not simply pass the calls back to DOS, but Win95 itself could handle them.

There's two sides to DPMI.
One side is the DPMI provider/host (which in this case is Windows), the other side is the DPMI client (which would be your DOS program).

The problem with DPMI is that it got conflated when DOS Extenders started supporting DPMI so they could co-exist with Windows.
Windows itself is a 'DOS Extender' basically, because it takes over from DOS and switches the CPU in 32-bit mode. If you then start a DOS session from Windows, it will not run in true realmode, but in v86 mode.
In fact, you don't even need full Windows for that. Just loading EMM386 will already switch your DOS to a v86-session, because EMM386 will virtualize some of your system to perform its memory management tasks (so technically EMM386 is a DOS Extender as well).

A 'pure' DOS extender simply switches the CPU to 32-bit mode and takes over the system. That works fine in pure DOS, but not from a v86 environment.
So, DPMI was invented as an interface for programs in a v86 environment to let the host (the one that put you in the v86 environment) manage the CPU and memory for you in a way that your application can run in 32-bit mode anyway.
Many DOS extenders are 'dual mode': if you have not loaded EMM386, Windows or anything else that creates a v86 session, it will create its own environment and will manage CPU state and memory itself. I don't think DOS Extenders would actually use DPMI in this case.
If you are already in some kind of virtual environment, it will try to use DPMI services to run. So it is the DPMI client (so technically it is not the DOS Extender, it is just using the API of the DOS Extender, it's a facade pattern). EMM386, Windows or whatever will be the DPMI provider.

Not all DOS extender environments support DPMI, so they won't work from a v86 session.

So yes, it sorta standardized the interface used by DOS extenders, but it is only required when your DOS extender needs to talk to another environment.
It's not something the developer of a 32-bit application normally has to bother with. They just link the DOS extender to their program, and the compiler will just generate the correct calls, regardless of what interface is used.