Anyone happen to know why all the memory management routines in Delphi take a signed rather than unsigned integer? Even routines that support 64-bit memory addresses use NativeInt rather than NativeUInt? A quick glance around the OS and language landscape suggests unsigned is the norm.
Anyone happen to know why all the memory management routines in Delphi take a signed rather than unsigned integer? Even routines that support 64-bit memory addresses use NativeInt rather than NativeUInt? A quick glance around the OS and language landscape suggests unsigned is the norm.
Using signed integers unnecessarily limits the maximum size of contiguous memory that can be allocated and requires all those routines to check that parameters are not less than zero. Why would someone purposefully do this?
Using signed integers unnecessarily limits the maximum size of contiguous memory that can be allocated and requires all those routines to check that parameters are not less than zero. Why would someone purposefully do this?
My first guess would be backwards compatibility and not going into the 4GB region in 32bit. Also NativeUInt did not exist or did not work since Delphi 2009. Did they use Integer or Cardinal in older Delphi versions?
ReplyDeleteCuriosity got the better of me and I looked up how GetMem was defined in TP5.5. It was:
ReplyDeleteprocedure GetMem(var P: Pointer; Size: word);
Found evidence that this was still the case in Delphi 1. I'm guessing when they moved Delphi to 32-bit they moved from an unsigned 16-bit integer to a signed 32-bit integer. Doesn't make any sense to me. Wonder if anyone from the original Delphi team knows why they switched.
Before windows 95，the MS used segmentation memory mode in DOS and Windows 3.x- standard mode OS.
ReplyDeleteIn segmentation mode, a segment boundary is 16bit, so it MUST use word type integer. In Practice, switching between segment (64k) is common operation.
Windows 95+ use flat memory mode. Every application get 4G memory address space. However, above 2G space is used by kernel objects mapping. So an application space limit to 2G (some windows versions can adjust to 3G but not normal).
Although application get 2G space, common installed physical RAM is less than 2G at that time. As I said above, EVERY application own 2G, but total RAM below 2G. OS using 386 paging tech to map user space to hard disk. So allocate a continuous memory larger then 2G is not possible and even 1G is not encourage because RAM may less than it. If you wanna access 1G+ data from file , should use memory file mapping to partially loading chunk by thunk to memory address.
Therefore, in Win32, signed integer is practically enough. In 64bit OS, the scenario is similar. Installed RAM always extremely less than total memory address spaces.
The critical problem is if someone happily allocate 3G+ memory with API, application will crash in the runtime, because 2G+ (normal app) address is forbidden in win32 OS.