종합하자면, 컴파일러의 문제도 운영체제의 문제도, PE 파일포맷의 문제도 아닙니다.
어떤 분이 스태틱 영역 할당을 크게 하면 실행화일 크기도 커진다고 말씀하셨지만,
사람이 만드는 이상, 그런 황당한 컴파일러도 물론 있을 수 있겠지만, 제가 쓰는 컴파일러들 중엔 없습니다.

그 원인을 설명드리자면,
화일처리론을 공부하신 분들이라면 익히 알고 있을 문제이네요.

600MB짜리 화일을 생성하는 가장 간단한 방법은,
파일 포인터를 600MB위치로 이동 시키고 (fseek, lseek등)
1Byte 쓰는것입니다.
이 경우, 램에 있는 내용이 화일에 저장할 용량만큼 그대로 화일로 덤프되게 됩니다.
화일시스템의 특징이지요.
특정 위치까지 억세스 한다는건, 그 사이의 범위도 읽고 쓸 가능성이 있는 것이고,
이 때 읽고 쓰는 경우를 최적화 하기 위해서 32비트 보호모드 환경에서는,
화일에 읽고 쓸 영역 만큼을 기본적으로 메모리와 사상시키기 때문입니다.
그렇게 해 두면, Multi-programming 환경이 보다 쉽게 구현되는 것이지요.
IO에 의한 병목이 없는.

아마도, 해당 컴파일러에서는
손쉽게 메모리 참조 테이블을 구현하기 위해
필요 크기만큼을 미리 잡아 놓고, 그 위치를 수정하는 형태로(append가 아닌 rewritable로)
화일에 억세스 하였고,
정작 그리 해 놓은 뒤에 사이 사이 변경되지 않은 영역을 내버려 둔 형태로 실행화일 생성을
완료해 생긴 문제인 것이죠.

즉, 정상적인 컴파일러라면, 스태틱영역을 크게 잡는다고 실행화일의 크기가 커지지 않습니다.
운영체제론을 공부하신 분이라면 익히 아시겠지만,
대부분의 실행화일의 포맷에서,
0을 제외한 정적 영역의 정보와, 리터럴 문자열을 비롯한 변경될 데이타들을 화일에 저장할 뿐이지,
char temp[1000000]; 과 같은 코드를 전역변수로 집어 넣는다해서
실행화일이 1메가를 넘어가진 않습니다.
이 경우는 실행시간에 할당되고, 0으로 초기화 될 따름이니까요.