I'll check the code out tomorrow.
As for the 32 vs 64 debate, it's a can of worms in itself.
The only reason I mentioned was in case you thought you must ship both kinds because exe must match system bitness or there is some sort of a problem. Shipping 32 bit is a safe bet to make sure it works on both 32 and 64 bit windowses.
On 32 bit the pointers take less space and 32 bit exes work both on 32 and 64 bit windows.
On 64 bit you have more memory address space and more registers which leads to better optimizations of compiler generated or hand written asm.
Downside to shipping both is a tiny bit more work and uploading (since the game zips include all the resources they have to be uploaded twice despite lack of changes since requiring downloading resources and exe itself separate would look silly and be tedious) and explaining to do (no 'this is the windows pack', the user has to choose although the only possible bad choice is 32 bit user taking 64 bit exe pack).
Downside to shipping just 64 bit is excluding a very tiny percentage of 32 bit users and issues with some unusual stuffs like LuaJIT memory limit due to internal use of 32 bit pointers and worse cache usage (highly theoretical/niche problem).
Downside to shipping just 32 bit is loss of potential performance and memory benefits (which are also highly theoretical/niche).
The debate is also highly pointless and continues to matter less. 64 bit is nice to have for performance, it's nice to have well written code that works on both, etc. but unless you are doing something really performance and/or memory intensive like compression, video decoding, web browsers, etc. it just doesn't matter.
The pointer size issue comes up in a few serious and niche places in various ways:
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#compressedOophttps://en.wikipedia.org/wiki/X32_ABIhttps://github.com/LuaJIT/LuaJIT/blob/master/src/lj_alloc.c#L255Many games like Payday and Stalker series actually ship only 32 bit exes and it's okay-ish (although it'd be a nice to have for performance to have them as 64 bit, they are intensive 3D FPS games). TDM GCC also ships 32 bit compilers (they can compile to 32 and 64 bit but themselves they are 32 bit exes):
http://tdm-gcc.tdragon.net/quirksAnother things is that everyone who has over 3.5 gigs of ram (very common nowdays) has 64 bit windows too...
Pascal compiler I use does 64 bit by default and I gave a few people the exe of my program and no one complained.. 64 bit has crazy high penetration already too.
And you get news like:
http://www.tgdaily.com/mobility-features/32079-no-more-32-bit-operating-systems-%E2%80%93-microsoftBut you can still see 5% of 32 bit machines on
http://store.steampowered.com/hwsurvey/ despite the fact that 32 bit is kinda rare and on the way out so it might be best to support it still for the third world and since it's usually people with older computers and less ram that play indies games and such anyway.
Some people are purists about it and will argue for matching system bitness just for the sake of it, even if it's a premature optimization (which should be avoided).
Knowing/learning how to avoid 32 -> 64 code porting pitfalls, not relying on types' and pointers' sizes, writing future proof, 64 bit proof code, etc. are all good and should be done though, even if you don't ship the resulting 64 bit exes.
On linux it's also a bit different because most people don't have 32 bit libraries installed to running a 32 bit exe on 64 bit linux is more of a hassle but then again - 32 bit systems are becoming less common nowdays, the only 32 bit linux I ever seen was my own old one.
