I am not confused, but I think you are.
If a 32bit apps is not compiled with /largeaddressaware, then it can't use more than 2 gb of memory, which is known as the soft cap. 32 bit application can exceed 4Gb of memory usage even with /largeaddressaware due to the 32 bit limitation. The 4gb limitation is aka the hard cap. No 32bit apps can use 4 gb in a 32bit OS because the OS must reserve some for kernel, 3gb at max. A 32bit app that is compiled with /largeaddressaware can fully use 4gb under 64bit OS.
64 bit OS can run 32 bit apps, but not the other way around. It will be better to write apps that run on both 32/64bit OS as the market is a max of 32/64bit OS. So instead of creating 64 bit apps, which does not run on 32 bit OS, it is better to write them in 32 bit. The problem is, 32 bit apps don't utilize more than 4gb, which is the key to the problem. Hypothetically speaking, If apps are engineered correctly, it can run as 1 32 bit thread on 32 bit OS and as multiple 32 bit threads while in 64 bit OS.
First you cannot just make up terms such as "2 gb soft cap" and "4 gb hard cap" and expect knowledgeable people to have any idea of WTF you are talking about. If you mean the 2GB/2GB user/kernel split, just say so! Seriously, Google search for "2 gb soft cap" and see if you get ANY sort of relevant result. I was able to infer your meaning, but that doesn't mean others will. If you search for "2GB/2GB user/kernel split", then you will get plenty of relevant results. A bit of advice, if you want to play with the big boys, at least be able to competently use the terminology.
Regarding /largeaddressaware, and increasing the user/kernel split to 3GB. Those are both hacks and you (should) know it. What's the point of having a single binary that behaves differently under 32-bit and 64-bit OSes? You would be better off just shipped 32-bit and 64-bit binaries and having your stub loader detect the bitness of the system and then exec the appropriate binary.
Using the /3GB switch to changes the user and kernel address partitions is even worse. The 32-bit kernel was designed to have 2GB of address space and you're playing with fire when you change that.
You keep using the word thread. It doesn't mean what you think it means. Threads of a given process share the same memory address space. PERIOD. That's the whole point of using them, you know. Threads are all about having multiple CPUs executing on the same data. Frankly, I'm not sure where you got the idea that running multiple threads gives you more addressable space.
One additional thing, when software is properly designed for portability, it is not difficult to create both 32 and 64 bit binaries from the same source code. Look at the majority of FOSS software. I can grab the source and build it either 32-bit or 64-bit if I want to.
Last edited: