Searching infos about multi-tasking API on "32-bits" and "64-bits" MS-Windows

[devEric69]

Hello,

Do you know if the Microsoft Windows 32-bits multi-threading API is the same as the Microsoft 64-bits API (in Windows 7, 8, 9,...)? In other words, is Microsoft updating their 32-bits multi-threading API in parallel with their 64-bits code multi-threading API before releasing it?

Which one (if any) of the Microsoft's Windows "32-bits" versus "64-bits" APIs multi-threading API would be flooded under a same overflow of incoming data, given equal processors and cores (with the same cross-compiled software, and same used hardware)? The one with multi-threaded background calculations, or the GDI one to display\invalidate the multi-threaded data regions in the foreground?

Regards.

[marcov]

In general, the preexisting win32 API has already been expanded to 64-bit in the nineties for non x86 architectures. (e.g. I had an Dec Alpha with Win 2000 beta at some point)

So basically win32 is win32/64. A 32-bits application gets linked to the 32-bit version, a 64-bit binary to the 64-bit of pretty much the same API.

The core difference is that of course the pointer size is different, so structures and parameters might have become bigger. A bigger change is of course that 64-bit has different and unified calling conventions.

So yes, I expect them to behave 100% the same. It is just different fronts of the same code

[devEric69]

In general, the preexisting win32 API has already been expanded to 64-bit in the nineties for non x86 architectures. (e.g. I had an Dec Alpha with Win 2000 beta at some point). So basically win32 is win32/64.

Thank you for the answer.

I asked, because I'm surprised to see very complex and advanced software vendors still offering the "32-bits" compilation version for sale (I need to purchase one). On Microsoft support, I found that they had to modify the 32-bits API at the turn of "XP Home"\"XP Pro" releases, because the apparition of several processors one the same machine were not detected by their API (same problem at that time too - a little later - with the apparition of multi-cores). So, I was wondering if the 32-bits multi-threading APIs really does always the same job as the 64-bits version...

The core difference is that of course the pointer size is different, so structures and parameters might have become bigger. A bigger change is of course that 64-bit has different and unified calling conventions.

This is what I realized after posting my question: the 1st difference between the same software compiled for 32-bits and 64-bits in the multi-threaded domain could probably indeed be roughly summarized to a problem of the amount of memory allocated and processed by each CPU cycle. So, I like to imagine that 32-bits version can be seen as an assertion to use smaller\sized data sets (somewhere related to the 64/32 ratio) when using the 32 bits rather than the 64 bits version: a kind of assertion to be more rigorous in not going in the direction of, nor big sized data neither big counted data (a shield against data inflation\a silly parallel with that of V6 engines versus V12 engines in the car industry\a constraint to more summarise the data).

[domasz]

I'm surprised to see very complex and advanced software vendors still offering the "32-bits" compilation version for salw

32-bit program will run on both 32 and 64 bit systems. So it's cheaper to just release 32-bit version. And the only real limitation (in Windows) is RAM. Most programs don't need more than 4 GB of RAM so 32-bit is sufficient.
Also many programs use DLLs from other sources (other programmers, programming languages) and using 32-bit DLL in 64-bit program is problematic.

[440bx]

Most programs don't need more than 4 GB of RAM so 32-bit is sufficient.
Also many programs use DLLs from other sources (other programmers, programming languages) and using 32-bit DLL in 64-bit program is problematic.

It is true that most programs don't need 4GB of _physical_ memory but, in 32bit, the 4GB address space (of which only 2 is available) has gotten crowded enough that obtaining a few reasonably large blocks of address space has, on occasion, become a problem.

In contrast, 64bit in the great majority of instances delivers all the address space a "normal" program could ever need.

[Thaddy]

In contrast, 64bit in the great majority of instances delivers all the address space a "normal" program could ever need.

Remember Bill Gates's quote? 640Kb is enough? Are you sure? 

[marcov]

In contrast, 64bit in the great majority of instances delivers all the address space a "normal" program could ever need.

Remember Bill Gates's quote? 640Kb is enough? Are you sure? 

Yes, trust me. We have seen that quote been used pointlessly out of context (and era) many, many, too many times.

[Thaddy]

@Marcov

I will note that down, youngster. But you will probably out-live me. Stubborn 50 somethings... 

[440bx]

Remember Bill Gates's quote? 640Kb is enough? Are you sure? 

I did specify "normal" programs.  2 GB of address space should be enough for a reasonably capable personal checkbook balancing program, Celsius to Fahrenheit temp converter, Grandma's and Ma's cooking recipes and such.

Of course, if any of the above apps are written on top of .net then they might need the larger 64 bit address space (and a really fast machine to avoid late payment penalties.)