Why can't EXE exceed 4 GB?

Http://www.cnblogs.com/lixiong/archive/2010/07/13/1776284.html

 

 

Why can't EXE exceed 4 GB?

 

A few days ago, we saw that we were discussing the issue of EXE loading, which was very novel. Some say that PE loading is restricted by the process space, some say that PE must be loaded as a whole, and some use zip self-decompressed packages for example.

 

I thought about it at the time and thought that PE should not be loaded as a whole. The PE file contains a PE Header, which defines the offset addresses of various segments, such as codes and resources. It should not exceed the PE Header definition during loading. That is to say, if the PE Header defines the farthest segment as 10 m, but the PE file has m, it should be loaded at most 10 m.

 

So I wrote a program to test it. First, write a simple C ++ helloworld. Then I randomly found a MB or so on the hard disk, and then executed the following command to combine the two files into a new EXE:

 

Copy/B helloworld.exe/B + Regular disk zookeeper. AVI/B largepe.exe/B

 

Then run largepe.exe. Everything is normal. After deploying largepe.exe in debugger, we found that the module occupies the same memory space as helloworld, and there is no Avi package.

 

So I am thinking, in this case, I can put a lot of data behind the EXE file, and then read the data in segments in the EXE implementation, implement self-decompression and so on. To prove this again, I used dxshow to write a simple playback program, and then spliced a 4G multi-definition version in the same way. Run and find:

 

Cannot run. This is the invalid Win32 application.

 

Well, from this point of view, there is a reason why the self-extracting file does not exceed 4 GB. But what is the reason? Is it really related to 4 GB memory? So I changed a 64-bit machine and ran it and found that:

Cannot run. This is the invalid Win32 application.

 

Oh, the 64-bit machine cannot run an EXE larger than 4 GB. It seems that it has nothing to do with the memory space of any process. But what is the cause? I followed the debugger to the last API before the failure and found it was zwcreatesection. This API call failed and returned status_invalid_file_for_section. Well, this is beyond my knowledge, so I went to the discussion group to ask experts and experts.PavelSaid:

 

"
Section_image_information structure contains a ulong imagefilesize field. If we allow files larger than 4 GB, programs that use this structure may break, and that can potentially affect 3rd party apps because all this information
Is on the web, even though the structure and the APIS using it are not officially specified ented.

(Note that this is separate from the image size in the PE headers, which is also a ulong and is currently limited to slightly less than 2 GB .)

-- By Pavel
"

 

This is the case ~~~

 

PS, with the preceding structure definition of section_image_information:

Http://www.nirsoft.net/kernel_struct/vista/SECTION_IMAGE_INFORMATION.html

 

Typedef struct _ section_image_information
{
Pvoid transferaddress;
Ulong zerobits;
Ulong maximumstacksize;
Ulong committedstacksize;
Ulong subsystemtype;
Union
{
Struct
{
Word subsystemminorversion;
Word subsystemmajorversion;
};
Ulong subsystemversion;
};
Ulong gpvalue;
Word imagecharacteristics;
Word dllcharacteristics;
Word machine;
Uchar imagecontainscode;
Uchar imageflags;
Ulong complusnativeready: 1;
Ulong complusilonly: 1;
Ulong imagedynamicallyrelocated: 1;
Ulong Reserved: 5;
Ulong loaderflags;
Ulong imagefilesize;
Ulong checksum;
} Section_image_information, * psection_image_information;