ผมว่าต่างกันที่ native "word" กับ memory space
ยกตัวอย่างง่ายๆ ก็ pointer ใน C ถ้า 64-bit ก็ต้องเก็บข้อมูลมากกว่า 32-bit ถึงเท่าตัวทีเดียวครับ

Oakyman.com

ที่ผมเจอคือตัวแปรที่มันควรขยายเป็น 64 บิตมันไม่ขยายตามอย่างถูกต้อง เช่นพวก int long ฯลฯ

คนทำภาษา C/C++ ต้องเจอกับความต่างกันของคอมไพล์เลอร์อยู่ทุกวันครับทั้ง VC++, GCC, Intel C++, ฯลฯ พอพฤติกรรมต่าง หลายครั้งโค้ดก็คอมไพล์ไม่ผ่านเลย บางครั้งก็ผ่านแบบไปตายตอนรัน

C# หรือ Java ตลอดจน "Managed Code" อื่นๆ ไม่น่าจะมีปัญหาเยอะมากนัก (น้อยกว่า Native เยอะแน่ๆ) ปัญหาสำคัญคือ library หลายๆ ตัวซึ่งเป็น native มันวิ่งตามมาไม่ทัน เพราะทำยากกว่า ทำให้สุดท้ายซอฟต์แวร์ทั้งชุดไม่รองรับ 64 บิตอยู่ดี

LewCPE

พูดถึงใน Windows นะครับ
แบบ 32bit: pointer มีขนาด 32bit; int, long มีขนาด 32bit; long long มีขนาด 64bit
เวลาคำนวณ pointer สามารถแปลงเป็น int หรือ long แล้วแปลงกลับเป็น pointer ได้
แบบ 64bit: pointer มีขนาด 64bit; int, long มีขนาด 32bit; long long มีขนาด 64bit
ถ้าใช้ code เดิมๆ เวลาคำนวณ pointer แปลงเป็น int หรือ long แล้วแปลงกลับเป็น pointer ผลคือ มันจะตัดเหลือแค่ 32bit ส่วน bit ที่อยู่สูงๆ จะหายไปครับ แต่ถ้าแปลงเป็น long long แทน ก็ใช้ได้ไม่มีปัญหา
การเขียน code ให้ใช้ได้ทั้งใน 32bit และ 64bit ง่ายๆ เวลาคำนวณเกี่ยวกับ pointer โดยใช้เลขจำนวนเต็ม ก็ใช้ LONG_PTR, ULONG_PTR แทนที่จะใช้ int หรือ long หรือ long long
อีกอย่างคือ struct ที่มีสมาชิกเป็น long long หรือ pointer เวลาคอมไพล์แบบ 32bit กับ 64bit จะมี alignment และขนาดแตกต่างกัน ทำให้โปรแกรม 32bit กับ 64bit ใช้ struct ร่วมกันไม่ได้ นอกจากจะวางแผนไว้ให้มันเหมือนกันทั้งใน 32bit และ 64bit

1. Compiler option ต้องเปลี่ยนใหม่
2. ถ้าใช้ 3rd party library ต้องไปหาว่ามีเวอร์ชั่น 64-bits ไหม
3. อาจต้องเปลี่ยน data type บางตัวใหม่เพราะมันอาจมีขนาดเพิ่มขึ้น 2 เท่าได้เช่น ใช้ int pointer ต่าง ๆ จาก 4 byte กลายเป็น 8 byte แอปพลิเคชั่นเราอาจกินแรมเพิ่ม 2 เท่า!
4. โค้ดที่ทำงานโดยคำนวณ data size ต่าง ๆ ต้อง revise ใหม่ เพราะอาจทำงานผิด
5. พวก bit-wise operator ต้อง check ดี ๆ
6. etc.