Quote from: WASasquatch on August 02, 2019, 11:48:25 AM
Also I am not sure what you mean by images? Executables are not images. Images use sectors and headers cause originally they were snapshots of actual HDDs. IMG, IMA, etc have this info so they can be mountable as a medium.
I am using Microsoft terminology. The PE32+ format is what is used for AMD64. I think it is called
PE32+ instead of PE64 because it only supports 32-bit images but was upgraded from PE32 so
that it can load them into a 64-bit address space. However, the specification is complicated and
documentation is not well written in my opinion. So it may be that loading an executable that uses
a list of sections instead of an image may make it possible to load programs much larger than
what will fit into a 32-bit section of address space. I can't say.
What I understand an image to be is a section of address space that can be reached using 32-bit
offsets. Since these are signed (plus or minus) either direction will only reach 2 GBytes (not 4). In
other words, a reference can reach up to 2GB forward or 2GB backward. If the reference was at the
beginning of the image, it can only reach 2GB forward. Reaching backward will not be used because
the reference being at the beginning of the image means that there is nothing to reach back there.
Same goes for a reference being at the end of an image. The reference will only reach backward
because there is nothing forward to reach because the reference is at the end of the image.
The image includes the program plus the statically defined data which includes globals and constants.
Dynamic memory (which is called the heap in C/C++) is another matter and that is implemented using
RAM that is not part of the image. So it may be that the TG memory usage that I see not only includes
the image but also dynamic memory which will grow and shrink depending on what it is doing. So I don't
think TG has to worry about its executable becoming too large because the image is certainly a lot smaller
than 2GBytes. The TGD.EXE file shows to be 488KB. That plus any DLLs that are used are probably a
good approximation of what TG uses statically. Sorry if I alarmed anyone.
Here is a picture I took out of a document that describes the PE32 file format it uses the term "image"
in two places. The PE32+ is similar but it has some fields extended to 64-bit to support a large address
space. But images are still limited to 2GBytes.
The reason why Windows32 needs 4GBytes is so that it can look at system space at the same time
as it looks at user space, each being 2GBytes in size.
[attach=1]