Ok, the 64-bit issue is officially fixed
You asked in PM how I fixed it, but I'll post it here since I know at least a few people who are gonna download this thing are nerds like me. In fact what I did was the simplest possible thing you can do. Nothing!
Lemme take a step back though. 64-bit Operating Systems (and CPUs) have a special mode called WOW64. And no, I don't mean World of Warcraft. A lot of people think that just because you get a 64-bit OS and a 64-bit CPU all your stuff is going to automatically be twice as awesome and run twice as fast. Unfortunately its' not true though. The code that executes on the CPU has to be specifically built for 64-bit platform. You can use the same source code for producing native 32-bit and native 64-bit code, but the compiler has to choose one or the other. In the case of native code, this (usually) means deciding at compile time which CPU you're going to target, and locking yourself into that decision forever.
When an application does not have that compiler switch flipped, it's just a normal 32-bit application. In this case, WOW64 kicks in. When WOW64 is active for an application, you are pretty much not seeing any performance gains at all over a 32-bit version of the same processor (this isn't
totally true, but it's pretty close). In fact, it's equivalent to a 32-bit app running on a 32-bit OS in every possible respect. The address space, the pointer sizes, everything is exactly the same.
FFXI is a 32-bit application. It didn't have that compiler switch flipped when it was built. So when I read the memory from the process, my code must be exactly the same as it is for the 32-bit OS case in every respect. Even though it's a 64-bit OS and a 64-bit CPU, since FFXI is a 32-bit application I must treat it as one. That was my fundamental flaw.
When you're compiling native code (e.g. C++) this is a non issue because if you want a 64-bit build you have to specifically tell the compiler to produce 64-bit code. If you choose the "Any CPU" compiler option for native code it just goes to the lowest common denominator (32-bit mode) and produces 32-bit code. In .NET it's different, because .NET is a
virtual runtime environment. You're not producing native code in the first place, you're producing something that is turned into native code when you run the program. So in .NET, if you choose the "Any CPU" option it behaves differently. Since the code isn't compiled until you run it, the runtime environment says "oh hey, this is a 64-bit OS, i'll produce 64-bit code". Now I'm using 64-bit code to attempt to read from the memory of FFXI, which treats FFXI as a 64-bit address space (which it clearly isn't), and everything goes to hell.
The solution was to flip a compiler switch when I build the parser. Instead of "Any CPU", I just changed it to "x86".