AllBASIC
BASIC Developer & Support Resources => Open Forum => Topic started by: John on December 17, 2017, 11:01:15 PM
-
The project is limited to 32 bit.
Even in Access 2013 format x64 the database limit is 2GB. So even no advantage on that..
And the 4GB memory limitation for 32 bit is not an argument. Every 32 bit process can have 4gb allocation. (Not in total allocation; per process allocation)
So who want to use more than 4gb of ram in an office instance?
My advise: go back to 32 bit office.
64 bit Windows is a lonely place for 3rd party developers.
-
64-bit windows is a pretty useless evolution -
It gives no benefit in speed, arithmetical precision or process capacity.
It doesn't even seem to improve memory handling.
The extra memory is useful, but that costs more money.
The 2GB limit on Access DB seems to be down to a 32-bit codebase simply compiled for 64 bit - like so many other programs.
-
64-bit helps Kernel developers but does little for high-level languages and applications. And I moan about the 64-bit calling conventions at every opportunity. They are totally wacko.
-
The funny thing is that Linux people have put 32 bit behind them long ago. A completely different mentality with where Microsoft is going (or not) with Windows 64 bit.
-
64-bit helps Kernel developers but does little for high-level languages and applications. And I moan about the 64-bit calling conventions at every opportunity. They are totally wacko.
You mean that the 32-bit conventions aren't?
Mind you, I'm still thinking in 16-bit, here :o
-
I don't think stdcall and cdecl can be improved, given the limitations on Pentium registers. I use something very similar to cdecl for non-exported functions when compiling 64-bit in OxygenBasic.