The Pandora has an ARM chip, your desktop or laptop has an X86 chip. ARM is a simlar kind of chip to the one that is in your cellphone. The newest windows OS that you will be able to run on it will be something like windows CE (also not happening any time soon).
Chip architectures can only handle certain types of math problems that they are designed for. The PS2's chip for example has a large tolerance for huge floating point numbers. Our little chip can do cool stuff, but you need to redesign the software to be in the correct form (even if you do it may rely on things that aren't available on this kind of chip). This is only possible if you have the source code. Windows is not going to give you their source code even if you ask pretty please.
What do you need windows so badly for? What program do you want to work on the Pandora?
It's an issue of binary incompatibility between precompiled stuff. Basically a CPU is like a domestic telephone service and the phone numbers will go to the wrong people if it's not compiled to the proper assembly/binary code.
Windows 8 will be the first where the mainline will be compiled with ARM binaries in addition to x86 binaries, and Microsoft is encouraging an emphasis on crossover among its partners. It may be possible for Pandora to handle that, but I can pretty much insure there won't be a full driver stack insuring everything behaves.
This is largely untrue and not the issue. That ARM v7 and x86-32 Instruction Sets not using the same binary dial-a-logic-circuit codes is the issue. The issue is not that either can't express something it's that any conversation must go through a translator.
The PS2 used a "128-bit" MIPs processor but the FP section was unlikely to have made much use of it in the implied precision capacity instead as a SIMD engine for 32 & 64-bit instructions. That is how 128-bit SSE, which predates the PS2, has been handled and the Pandora wiki emphasizes the NEON SIMD works much the same way.
The above represents the level of precision in terms of defined states possible at a given bit width. The main reason to use larger bit widths is to combat round off error, as FP is in scientific notation by definition, which as you can see doesn't really justify itself for a game or most supercomputer cluster math problems for that matter.
Incidentally x86 will with this recent generation be moving to a 256-bit AVX (Advanced Vector eXtension) SIMD engine setup for handling floating point, and programmable GPGPU SIMD engines are being increasingly setup to accelerate processing of massively parallel loads ala the massive tables resulting from Finite Element Analysis techniques. RISC may finally lose it's long standing advantage in this area thanks to things on the x86 side finally being cleaned up enough. ARMH meanwhile appears to be sticking with 128-bit SIMDs through at least A15, albeit with fused instructions like those advertized with AVX.