Hey Chris!

Just thought I'd ask your opinion on the gunk that MSVC link.exe and
ld.exe put in the executable headers of binaries. Personally, I really
dislike them, especially the Rich headers that MSVC link.exe adds by
default (fortunately, it's at least opt-out). I have noticed that ld.exe
also populates unused fields of the DOS header and still inserts the DOS
dummy program, even though that hasn't been relevant for over 2 decades now.

In my minimal fork of your w64devkit project, I added a patch to ld.exe
to simply omit this junk from the headers:

https://github.com/friendlyanon/w64devkit/blob/ddef429672eafe83e0a548430ebad64b351542f5/minimal-pe-header.patch

I was hoping to maybe see this added to your project as well, but it's
fine if you decline on the basis that this would be yet another thing to
maintain for you.

Regards

Thanks for the patch, Pali! I've had similar feelings about the DOS stub 
myself. This change interests me, and perhaps early in the project before 
anyone was making serious use of the toolchain, and therefore there was 
little to break, I might have accepted it.

However, the "MinGW" ecosystem is old and well-established, and there's a 
surprising amount of value in remaining compatible with it. Often when I 
want to build something in w64devkit, the hardest work was already done 
before w64devkit even existed. Someone previously ported it to MinGW or 
Mingw-w64, and that capability has been maintained.

I'm afraid of the potential downstream effects from changing something as 
fundamental as the PE header, even if the specification technically allows 
it. I don't know what might be counting on everything being just the way 
it always has been. The benefits of removing the stub are operationally 
irrelevant, so that seems like high risk, small reward. My own experience 
hacking on PE binaries has been that security software is suspicious of 
the unconventional, especially this case.

I would be more interested if the change was opt-in, perhaps through a 
linker flag, so that the default experience remains the same, but people 
interested in removing the DOS stub — which would be me sometimes — could 
do so at their own peril. I'm not saying you should necessarily update 
your patch to add an opt-in with a new ld flag, because then accepting it 
means maintaining that substantial patch through Bintuils upgrades! And, 
again, for such a small reward. It would be a lot of work, but the best 
place for a patch adding a new no-dos-stub ld switch would be upstream. 
There are already a number of PE-only switches after all.

I considered tossing your patch in my (new) contrib/ directory for those 
that might want it, but there's quite a bit of GPL code in the patch.

Regardless, I'm happy that you were able to fork w64devkit and modify it 
for your own purposes! Enabling that has been one of my goals.

3 Jun 2024 4:55:03 am Pali Zer <skype1234@waifu.club>:

> Hey Chris!
>
> Just thought I'd ask your opinion on the gunk that MSVC link.exe and
> ld.exe put in the executable headers of binaries. Personally, I really
> dislike them, especially the Rich headers that MSVC link.exe adds by
> default (fortunately, it's at least opt-out). I have noticed that 
> ld.exe
> also populates unused fields of the DOS header and still inserts the 
> DOS
> dummy program, even though that hasn't been relevant for over 2 decades 
> now.
>
> In my minimal fork of your w64devkit project, I added a patch to ld.exe
> to simply omit this junk from the headers:
>
> 
> https://github.com/friendlyanon/w64devkit/blob/ddef429672eafe83e0a548430ebad64b351542f5/minimal-pe-header.patch
>
> I was hoping to maybe see this added to your project as well, but it's
> fine if you decline on the basis that this would be yet another thing 
> to
> maintain for you.

Wouldn't this be unlikely to really save any space, since the filesystem 
would probably be in 4k clusters regardless? Even then, 64 bytes really 
isn't much, with 1 million executables you are saving 64MB

I suspect any compression benefits too would be likely negligible.

I agree this is cruft and I would remove it if I were executable golfing 
or making a demo, but practically for users of a toolchain, I can't see 
much point.

>
> Regards

Regards,
Peter D.

On 2024. 06. 03. 6:05, Peter0x44 wrote:
> Wouldn't this be unlikely to really save any space, since the filesystem 
> would probably be in 4k clusters regardless? Even then, 64 bytes really 
> isn't much, with 1 million executables you are saving 64MB
> 
> I suspect any compression benefits too would be likely negligible.
> 
> I agree this is cruft and I would remove it if I were executable golfing 
> or making a demo, but practically for users of a toolchain, I can't see 
> much point.

It's not about any potential space savings. Segments in PE executables
are aligned to at minimum 1 byte boundaries based on my testing with
link.exe and it seems to default to 512 bytes for non-driver binaries
anyway.

Removing the vestigial DOS stub and setting unused DOS header fields to
0 is about the principle. They are absolutely useless nowadays, so
whatever can be removed, should be removed. The only fields Windows
cares about are e_magic and e_lfanew.

On 2024. 06. 03. 9:55, Pali Zer wrote:
> Segments in PE executables are aligned to at minimum 1 byte
> boundaries based on my testing with link.exe and it seems to default
> to 512 bytes for non-driver binaries anyway.

Correction: while /filealign seems to allow 1, anything lower than 512
produces an executable that cannot be executed, while /align accepts 16
at minimum.