Talk:Portable Executable
From Wikipedia, the free encyclopedia
Contents |
[edit] Smallest valid assembly code (WIN32)
.386 .model flat,stdcall option casemap:none include kernel32.inc includelib kernel32.lib .code start: mov eax,0 invoke ExitProcess,eax end start
written and compiled in MASM using PoLink
[edit] Errors
Much of this is inaccurate. The .NET CLR is NOT 'added after the PE/COFF headers' nor does the CLR itself contain the mscoree!_CorExeMain or mscoree!_CorDllMain reference. The CLR header, defined as IMAGE_COR20_HEADER, is referenced through a data directory (#14) in the PE/COFF header. This data directory points to the virtual address and size of the CLR header.
The normal PE/COFF IMPORT table contains the mscoree!_Cor*Main reference. The entry point has a single jmp far instruction into the IAT table entry for this single import.
The IMAGE_COR20_HEADER is used by the CLR when it is loaded into the process space through a .NET aware operating system (WindowsXP+) or through the mscoree!CorExeMain or mscoree!CoreDllMain APIs.
- So I gather three things are wrong:
-
- 1)The CLR header and data sections are not placed at some memory address after the PE/COFF header section.
- 2)The reference to CorExeMain and mscoree are not in the CLR header or data sections, but instead the import table
- 3)The CLR header is referenced/loaded by the CLR, not by the loader directly.
-
- I've made changes accordingly. Thanks for the corrections.
- Vector4F 21:49, 20 November 2005 (UTC)
- I've made changes accordingly. Thanks for the corrections.
[edit] Broken link in OpenRCE
The "PE File Format Diagram" is broken, I don't know the right link... FYI Gil_mo 07:25, 15 July 2007 (UTC)
[edit] "portable" refers to the format's portability across all 32-bit
(and by extension 64-bit) Windows operating systems.
- That is to say, all 16 bit and 32-bit and 64-bit Windows and DOS operating systems? 150.101.166.15 02:21, 20 July 2007 (UTC)
-
- No. That is to say, all 32-bit and 64-bit Windows operating systems. Guy Harris 08:21, 20 July 2007 (UTC)
-
-
- No, the format was designed to be portable to DOS operating systems. There were two (rare) uses for the DOS compatibility, and one common use. The common use was to include a stub that displayed "This program requires Windows" or words to that effect. The less common uses were to include a stub that restarted the program in a Windows system, or to include a separate DOS copy of the program in the same file. The format also supports and is compatible with 16 bit windows, as it was designed to be, but I never heard of anyone using it for that purpose.
- Since the body of the article clearly discusses this, and the specification clearly discusses this, can we change the leading sentence? 150.101.166.15 (talk) 03:21, 22 November 2007 (UTC)
-
-
-
-
- The specification also clearly says, in the abstract, "This specification describes the structure of executable (image) files and object files under the Microsoft® Windows® family of operating systems." and the article clearly says "The format has retained limited legacy support to bridge the gap between DOS-based and NT systems." Neither of these speak of it as a format intended for use on DOS or 16-bit Windows; the format happens to begin with a header in the format of an MS-DOS executable, but there's nothing in the article or the PE specification to indicate that there was any intent that MS-DOS should be able to execute the code in the PE sections of the file just as 32-bit and 64-bit Windows can. Guy Harris (talk) 09:13, 22 November 2007 (UTC)
- It "happens" to begin with a legacy format specifically so that it will be portable to legacy systems. It really looks like you are grasping at straws here!150.101.166.15 02:54, 4 December 2007 (UTC)
- The specification also clearly says, in the abstract, "This specification describes the structure of executable (image) files and object files under the Microsoft® Windows® family of operating systems." and the article clearly says "The format has retained limited legacy support to bridge the gap between DOS-based and NT systems." Neither of these speak of it as a format intended for use on DOS or 16-bit Windows; the format happens to begin with a header in the format of an MS-DOS executable, but there's nothing in the article or the PE specification to indicate that there was any intent that MS-DOS should be able to execute the code in the PE sections of the file just as 32-bit and 64-bit Windows can. Guy Harris (talk) 09:13, 22 November 2007 (UTC)
-
-
-
-
-
-
-
- "Portable to legacy systems" in what sense? The legacy systems don't interpret the part that's new, so the only reason to run a PE binary on a legacy system, rather than just running an MZ binary, is to use PE as a fat binary format, with a single file containing both an old DOS binary and a new 32-bit or 64-bit Windows binary. The code in the PE portion of the binary will not be executed on DOS, so it's not as if PE adds anything for DOS-only binaries.
-
-
-
-
-
-
-
-
-
- As such, you're stretching rather a lot to try to speak of it as being portable to DOS or 16-bit Windows, or to change the first sentence to speak of it as a file format used on DOS or 16-bit Windows - yes, if you try to run a PE file on DOS or 16-bit Windows, it'll run the MZ binary at the beginning, but if you try to run a file consisting of, for example, an MZ binary followed by a copy of the US Constitution in ASCII, it'll run the MZ binary at the beginning of that file, too. I.e., DOS doesn't explicitly support PE - it explicitly supports MZ, and, as PE files look like MZ if you ignore stuff past the size specified in the MZ header, that means it also runs the stub portion of PE binaries. Guy Harris 03:30, 4 December 2007 (UTC)
-
-
-
-
-
-
-
-
-
- Or, to put it another way, DOS can't execute PE binaries. It can, however, execute MZ binaries with extra cruft stuck at the end; that's what a PE binary is to DOS. Saying it's used in DOS and 16-bit Windows is thus misleading; the only part that's used is the part that was there before PE was invented. Guy Harris 04:25, 4 December 2007 (UTC)
- Yes, that's what Portable means. The Executable format is Portable to DOS etc. No, having a Portable Executable Format does not magically change BSD programs into Linux programs: There is a fairly clear distinction between having portable programs and having a portable executable format. Of course, having a portable executable format is a pre-requisite for having portable executables, which is why MS designed a PEF that was portable to DOS as well as Windows. 150.101.166.15 (talk) 01:38, 20 December 2007 (UTC)
- Or, to put it another way, DOS can't execute PE binaries. It can, however, execute MZ binaries with extra cruft stuck at the end; that's what a PE binary is to DOS. Saying it's used in DOS and 16-bit Windows is thus misleading; the only part that's used is the part that was there before PE was invented. Guy Harris 04:25, 4 December 2007 (UTC)
-
-
-
-
[edit] Useless links
I didn't see any advantages of "yoda's LordPE Deluxe" and "PE Explorer" over "CFF Explorer" tool listed under "Related tools" section. The first one provides very limited set of features and the second one looks like advertisement. Hstab 02:52, 7 August 2007 (UTC)
[edit] Poor Quality!Needs Improving Badly!
This article is poorly written! anyone explain PE format more clearly? Visame (talk) 18:42, 4 May 2008 (UTC)

