Talk:Portable Executable

	This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.
	This article is supported by WikiProject Computing.

Position-independent code

PE does support position-independent code, it's just that no compiler or linker does. Interix executables compiled with GCC are position-independent PEs —Preceding unsigned comment added by 151.48.66.164 (talk) 22:48, 21 November 2008 (UTC)[reply]

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

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)[reply]

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)[reply]

"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)[reply]

No. That is to say, all 32-bit and 64-bit Windows operating systems. Guy Harris 08:21, 20 July 2007 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

"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)[reply]

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)[reply]

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)[reply]

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)[reply]

Okay I look over it again and it's probably to much, "PE Explorer" looks nice + is actually the most useless of the three others. ...and it's commercial - so let's drop it!

I know LordPE is old and the initial mask let you edit only selected values in the PE-header, but if you go more in the deep like exploring directories, it show you also 'exotic' structures as TLS, DelayImport, LoadConfig - you normally don't find in the rest of the PE-Editors. Together with the dumper(that also come along the Imagesize mod and Virtualprotect trick as Armadillo uses) it's in my eyes still the best 'all-rounder'.

"CFF Explorer" is great addition to LordPE and may depending on what you're doing/trying to do a better choice.

That 'PEview' is more educational - but I find it fits good for that purpose. It show you the structures in a clean and simple way while showing the offsets and underlaying Hexdata.

A console app like PEDump as also it's advantages if you like to use its output as input for an other program like windiff (examdiff or other differ).

And maybe we should keep that online PE-Viewer, because you can use without installing. ... and kick out the rest.

@Hstab: Okay I see wikipedia is not meant to be a software collection. However regarding this subject some well selected links to free PE-Tools as great addition to make that article more practical and 'living'.

What are the reason/ya experiences, that makes you to be that strictly against this?

Djamana (talk) 03:51, 26 April 2009 (UTC)[reply]

Poor Quality!Needs Improving Badly!

This article is poorly written! anyone explain PE format more clearly? Visame (talk) 18:42, 4 May 2008 (UTC)[reply]

Universal Binary?

What's the difference between Portable Executable and Universal Binary? If I've understood it right Portable Executable is single binary file which has built in binary code for several different architectures while Universal Binary is more like a container for different binaries for different architectures. Is that correct or are both the one and same thing? --Dekonega (talk) 13:23, 10 November 2009 (UTC)[reply]

Universal binary refers to a Mach-O file that contains compiled code for PowerPC and Intel architectures. A common compiler flag used in Mac OS X is 32_64_universal which compiles an application as 32 and 64-bit for both PowerPC and Intel (the resulting executable ending up with instructions for 4 architectures). Dread Lord CyberSkull ✎☠ 09:33, 29 December 2011 (UTC)[reply]

Xbox use a similar format?

I've been reading up on the likelihood that the Xbox console used a somewhat-modified form of the Portable Executable format for its .xbe executable files. Can anyone substantiate this supposition? Did the format translate over the to the Xbox 360? If either answer is affirmative, should those pieces of information be included in the article?—WhosAsking (talk) 18:40, 13 June 2010 (UTC)[reply]

Was PE proprietary at first?

Was PE specification open from the start or was it reverse-engineered and published post factum? 93.175.21.184 (talk) 16:15, 13 January 2011 (UTC)[reply]

http://www.csn.ul.ie/~caolan/publink/winresdump/winresdump/doc/pefile2.html

The Windows NT version 3.1 operating system introduces a new executable file format called the Portable Executable (PE) file format. The Portable Executable File Format specification, though rather vague, has been made available to the public and is included on the Microsoft Developer Network CD (Specs and Strategy, Specifications, Windows NT File Format Specifications). Yet this specification alone does not provide enough information to make it easy, or even reasonable, for developers to understand the PE file format.

The first decent material on the subject was a famous MSDN Magazine article by Matt Pietrek in 1994. — Vano 23:57, 16 July 2013 (UTC)[reply]

Multiple binaries?

Does PE support multiple binaries like Mach-O does? It is not clear from the article whether it does or not. Dread Lord CyberSkull ✎☠ 09:34, 29 December 2011 (UTC)[reply]

No A PE executable is a DOS Executable with extra DATA unlike universal MAC binaries where you have an archive which contain other executable archive: See Below. 2A02:8422:1191:6E00:56E6:FCFF:FEDB:2BBA (talk) 22:42, 16 July 2013 (UTC)[reply]

HISTORY section and efi citation

It should be mentioned that PE was originally developed by IBM and that the DOS executable was not as Stub message.

It was similar to Universal Binary. There was two executable for two different platform at same time. They both do the same thing. The latest know example is the windows 98SE installer. there are the same pictures with DOS and windows. OS/2 had no graphic interface in the beginning.

There is two formats on DOS: the first one is .com. It is an unformatted one. You can even boot on it if put one in a Boor sector. The second is .EXE. It is an archive which contain several files and allow relocatable sections. A PE executable is A DOS EXE with certain instructions for stopping the program before the beginning of the other. When windows explorer see a PE header with an icons it opens the archive go into a special folder an extract an .ico file then it display it. It is just for saying PE headers are archive based. It is an neglected aspect. Someone who read the article won't understand it.

When times goes by, DOS usage was decreasing. It didn't worth to develop application for DOS. It is at this time DOS executables started to be STUb message.

When DOS was dropped, they were implementations problems (ex:mingw): it is impossible to have a PE header without a working DOS .exe format. So compiler still continue to generate Stub message. It is the failure of forced compatibility. A normal situation in another case (Other OS) would make the new executable don't work at all. On DOS running a DLL would normaly crash the system. Most people think Stub message were designed for 9x users. But it WRONG because it is no longer the case. It is caused by a design issue

I didn't find a efi file available directly for download. I think it is that should be used for the source. 2A02:8422:1191:6E00:56E6:FCFF:FEDB:2BBA (talk) 22:39, 16 July 2013 (UTC)[reply]

You're confusing it with DOS MZ executable. Btw, there was New Executable in between too. A note about a full-fledged DOS program is worth noting, I've added it. — Vano 22:58, 16 July 2013 (UTC)[reply]

I couldn't find any sources about PE format usage in OS/2 - they only talk about Linear Executables. So i'm removing that statement as plain confusion unless you find a reliable source saying otherwise. — Vano 23:39, 16 July 2013 (UTC)[reply]

I couldn"t find any source too but if you download ecomstation CD you'll see that every executable have a PE header. OS/2 was released before windows. Everybody who used OS/2 before windows know it is IBM that developed the nt kernel. Also don't forget first OS/2 (including 2.0) didn't use 32 bits and had their own type. 2A02:8422:1191:6E00:56E6:FCFF:FEDB:2BBA (talk) 23:58, 16 July 2013 (UTC) Do not invisibly edit old or replied messages - this distorts the discussion history. Make changes clearly visible and timestamped (like this) or write a new message. — Vano 12:10, 18 July 2013 (UTC)[reply]

OS/2 was jointly developed by IBM and Microsoft, see Microsoft#1984.E2.80.9394:_Windows_and_Office. eComStation, regardless of formats, looks like an OS/2 spin-off rather that the original IBM's product. Whether its use of PE format deserves mentioning in .exe depends of how notable that OS is. — Vano 00:27, 17 July 2013 (UTC)[reply]

I found this. 2A02:8422:1191:6E00:56E6:FCFF:FEDB:2BBA (talk) 22:17, 17 July 2013 (UTC)[reply]

Pretty surprising. I didn't know there was (and more so, STILL was: check out the VS version) a publicly supported way to attach MS-DOS executables. — Vano 22:48, 17 July 2013 (UTC)[reply]

Not surprising at all: It is the same with number of MS products: you have parts of very old code that is not obsoleted (absent article on a Software development process part) and removed. The web documentation is probably automaticlly generated by their build systems. It says that it is limited to win32, but it work on ervery executable having a PE header (They talk of Vxd whereas 2012 version no longer alow building Vxd). Sure, it still exist because nobody think to remove it. What if it is not a bug

: It is designed in the case a developper want anticipating this kind of user idea:

I have a new computer. UEFI is super: there are applications files. After playing my games, I want to boot another OS without leaving DOS for rebooting. I'm taking my 64 bits EFI file (since there is 16 bit-code in 64 bits programs). I'm renaming the extension to exe and try to see if there is the dos version included. Let's check...

Cooooooooooooooooool it work !!!!!!!!!!!!!

2A02:8422:1191:6E00:56E6:FCFF:FEDB:2BBA (talk) 00:38, 18 July 2013 (UTC)[reply]

I'm glad for you but please refrain from drifting off topic too much. Article talk pages in Wikipedia are supposed to support writing the article, general discussions are only good as long as they facilitate that goal. Specifically:

your MSDN link is good to support the "can be a full MS-DOS app" clause
the fact that PE is the format for EFI executables is already present (a link to a section of UEFI standard is desirable though). A working DOS version of the loader as the MZ stub may be a part of the UEFI standard, Microsoft's implementation detail or just your luck with this particular loader. Please check this out if you want to add this fact to the article. — Vano 11:43, 18 July 2013 (UTC)[reply]