Why Win64 (x86_64) executable has more footprint than Win32?

Hi all,

I am using Visual Studio 2005 Professional Edition to build a .dll for
Win32 Release, it is 433 KB, for Win64(x86_64) Release, it is 581 KB
with the exactly same configuration (e.g., /Os). Why? How to reduce the
Win64 .dll footprint? Thanks!

Best Regards,
Xie, Bo

bruno_nos_pam_van_dooren
Tue Sep 26 08:34:01 CDT 2006

> I am using Visual Studio 2005 Professional Edition to build a .dll for
> Win32 Release, it is 433 KB, for Win64(x86_64) Release, it is 581 KB
> with the exactly same configuration (e.g., /Os). Why? How to reduce the
> Win64 .dll footprint? Thanks!

64 bit cpu's have different binary code than 32 bit cpu's. pointers are 64
bit wide, different instructions, addresses are 64 bit,...
I think this is normal.
given what I know about Itanium, I suspect that Itanium 64 bit binaries
would be even bigger still.

Remember the golden rule of engineering: if it ain't broken, don't fix it.

the only thing you could do is to optimize for size instead of speed for 64
bit builds.
But really, the difference is not that big that you should worry about it.

--
Kind regards,
Bruno.
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"

xiebopublic
Tue Sep 26 09:55:09 CDT 2006

I really care about it. My program has a hard footprint limitation
(e.g., 300 KB) and my win32 version can meet the footprint limitation,
but win64 version can not meet it. Then I must reduce win64 executable
footprint. Is there any trick to reduce the win64 footprint limitation?

Thanks!

Best Regards,
Xie, Bo

Bruno wrote:
> > I am using Visual Studio 2005 Professional Edition to build a .dll for
> > Win32 Release, it is 433 KB, for Win64(x86_64) Release, it is 581 KB
> > with the exactly same configuration (e.g., /Os). Why? How to reduce the
> > Win64 .dll footprint? Thanks!
>
> 64 bit cpu's have different binary code than 32 bit cpu's. pointers are 64
> bit wide, different instructions, addresses are 64 bit,...
> I think this is normal.
> given what I know about Itanium, I suspect that Itanium 64 bit binaries
> would be even bigger still.
>
> Remember the golden rule of engineering: if it ain't broken, don't fix it.
>
> the only thing you could do is to optimize for size instead of speed for 64
> bit builds.
> But really, the difference is not that big that you should worry about it.
>
> --
> Kind regards,
> Bruno.
> bruno_nos_pam_van_dooren@hotmail.com
> Remove only "_nos_pam"

Mark
Tue Sep 26 10:11:53 CDT 2006

Select optimize for size in the project configuration; but really - Win64 is
a completely different system from Win32. How can you expect them to be
equal?

--
- Mark Randall
http://www.temporal-solutions.co.uk
http://www.awportals.com

<xiebopublic@gmail.com> wrote in message
news:1159282508.395489.273480@h48g2000cwc.googlegroups.com...
>I really care about it. My program has a hard footprint limitation
> (e.g., 300 KB) and my win32 version can meet the footprint limitation,
> but win64 version can not meet it. Then I must reduce win64 executable
> footprint. Is there any trick to reduce the win64 footprint limitation?
>
> Thanks!
>
> Best Regards,
> Xie, Bo
>
> Bruno wrote:
>> > I am using Visual Studio 2005 Professional Edition to build a .dll for
>> > Win32 Release, it is 433 KB, for Win64(x86_64) Release, it is 581 KB
>> > with the exactly same configuration (e.g., /Os). Why? How to reduce the
>> > Win64 .dll footprint? Thanks!
>>
>> 64 bit cpu's have different binary code than 32 bit cpu's. pointers are
>> 64
>> bit wide, different instructions, addresses are 64 bit,...
>> I think this is normal.
>> given what I know about Itanium, I suspect that Itanium 64 bit binaries
>> would be even bigger still.
>>
>> Remember the golden rule of engineering: if it ain't broken, don't fix
>> it.
>>
>> the only thing you could do is to optimize for size instead of speed for
>> 64
>> bit builds.
>> But really, the difference is not that big that you should worry about
>> it.
>>
>> --
>> Kind regards,
>> Bruno.
>> bruno_nos_pam_van_dooren@hotmail.com
>> Remove only "_nos_pam"
>

NickP
Tue Sep 26 10:17:38 CDT 2006

Have you tried this....

http://upx.sourceforge.net/

It will compress your EXE, I use it for Win32 and it works great...

Nick

<xiebopublic@gmail.com> wrote in message
news:1159282508.395489.273480@h48g2000cwc.googlegroups.com...
>I really care about it. My program has a hard footprint limitation
> (e.g., 300 KB) and my win32 version can meet the footprint limitation,
> but win64 version can not meet it. Then I must reduce win64 executable
> footprint. Is there any trick to reduce the win64 footprint limitation?
>
> Thanks!
>
> Best Regards,
> Xie, Bo
>
> Bruno wrote:
>> > I am using Visual Studio 2005 Professional Edition to build a .dll for
>> > Win32 Release, it is 433 KB, for Win64(x86_64) Release, it is 581 KB
>> > with the exactly same configuration (e.g., /Os). Why? How to reduce the
>> > Win64 .dll footprint? Thanks!
>>
>> 64 bit cpu's have different binary code than 32 bit cpu's. pointers are
>> 64
>> bit wide, different instructions, addresses are 64 bit,...
>> I think this is normal.
>> given what I know about Itanium, I suspect that Itanium 64 bit binaries
>> would be even bigger still.
>>
>> Remember the golden rule of engineering: if it ain't broken, don't fix
>> it.
>>
>> the only thing you could do is to optimize for size instead of speed for
>> 64
>> bit builds.
>> But really, the difference is not that big that you should worry about
>> it.
>>
>> --
>> Kind regards,
>> Bruno.
>> bruno_nos_pam_van_dooren@hotmail.com
>> Remove only "_nos_pam"
>

Eric
Tue Sep 26 11:21:36 CDT 2006

> I really care about it. My program has a hard footprint limitation
> (e.g., 300 KB) and my win32 version can meet the footprint limitation,
> but win64 version can not meet it. Then I must reduce win64 executable
> footprint. Is there any trick to reduce the win64 footprint limitation?

This isn't meant to be rude, but who would impose a 300K (or whatever)
limitation on the size of a DLL or executable and why?

What I'm getting at is that if you have a hard 300K per-file limit, could
you split your DLL into two 250K files instead? Or if the limit is the
total amount of "network" storage space allocated, you could put the file
into an archive and unpack them on the local machine. A "hard footprint"
limitation can mean many things.

Eric

NickP
Tue Sep 26 12:07:02 CDT 2006

Hey Eric,

I'm not meaning to sound rude either, but if developer has a
specification that states 300k size limit, then what is he/she supposed to
do?

I think UPX packing would help personally, I've had to drop the size of
an app recently to make it as small as possible and currently it is under
300k, that is ideal for our purpose.

Imagine if every self executing zip file was 500k before your data was
even added... (not that I have any idea how large it currently is)

Nick.

"Eric Hill" <eric@ijack.net> wrote in message
news:op.tghueahlsqk0wa@wcerich-6223.pioneer.world...
>> I really care about it. My program has a hard footprint limitation
>> (e.g., 300 KB) and my win32 version can meet the footprint limitation,
>> but win64 version can not meet it. Then I must reduce win64 executable
>> footprint. Is there any trick to reduce the win64 footprint limitation?
>
> This isn't meant to be rude, but who would impose a 300K (or whatever)
> limitation on the size of a DLL or executable and why?
>
> What I'm getting at is that if you have a hard 300K per-file limit, could
> you split your DLL into two 250K files instead? Or if the limit is the
> total amount of "network" storage space allocated, you could put the file
> into an archive and unpack them on the local machine. A "hard footprint"
> limitation can mean many things.
>
> Eric

Eric
Tue Sep 26 13:12:42 CDT 2006

> I'm not meaning to sound rude either, but if developer has a
> specification that states 300k size limit, then what is he/she suppose=
d =

> to
> do?

Well, I guess that's my point really - a specification of 300k doesn't =

necessariliy imply that the developer couldn't have more than one 250k =

file, or that the 300k file couldn't be compressed in some way, or for =

that matter simply downloaded at runtime to a temporary folder. There m=
ay =

be other options than just "the compiler must spit out less than 300k of=
=

code".

> I think UPX packing would help personally, I've had to drop the si=
ze =

> of
> an app recently to make it as small as possible and currently it is un=
der
> 300k, that is ideal for our purpose.
>
> Imagine if every self executing zip file was 500k before your data=
=

> was
> even added... (not that I have any idea how large it currently is)

I've used UPX in the past and while it does work very well for what it =

does, it can also introduce some other problems in certain circumstances=
. =

A) Certain virus checkers have problems with executables that modify the=
=

in-memory code (unpacking =3D=3D modifying). B) Sometimes the unpacking=
=

process causes excessive memory fragmentation on older systems with less=
=

ram causing the executable to run insanely slow or not at all. C) =

Unpacking executables eats up valuable GDI resources on Windows 9x/ME =

machines that cause applications to crash when not enough resources are =
=

available whereas an unpacked executable will work just fine.

Eric

xiebopublic
Tue Sep 26 20:37:44 CDT 2006

I've done it for both win32 and win64 (/O1 /Os), it works but the
result win64 .dll is still too big.

Best Regards,
Xie, Bo

Mark Randall wrote:
> Select optimize for size in the project configuration; but really - Win64 is
> a completely different system from Win32. How can you expect them to be
> equal?
>
> --
> - Mark Randall
> http://www.temporal-solutions.co.uk
> http://www.awportals.com
>
> <xiebopublic@gmail.com> wrote in message
> news:1159282508.395489.273480@h48g2000cwc.googlegroups.com...
> >I really care about it. My program has a hard footprint limitation
> > (e.g., 300 KB) and my win32 version can meet the footprint limitation,
> > but win64 version can not meet it. Then I must reduce win64 executable
> > footprint. Is there any trick to reduce the win64 footprint limitation?
> >
> > Thanks!
> >
> > Best Regards,
> > Xie, Bo
> >
> > Bruno wrote:
> >> > I am using Visual Studio 2005 Professional Edition to build a .dll for
> >> > Win32 Release, it is 433 KB, for Win64(x86_64) Release, it is 581 KB
> >> > with the exactly same configuration (e.g., /Os). Why? How to reduce the
> >> > Win64 .dll footprint? Thanks!
> >>
> >> 64 bit cpu's have different binary code than 32 bit cpu's. pointers are
> >> 64
> >> bit wide, different instructions, addresses are 64 bit,...
> >> I think this is normal.
> >> given what I know about Itanium, I suspect that Itanium 64 bit binaries
> >> would be even bigger still.
> >>
> >> Remember the golden rule of engineering: if it ain't broken, don't fix
> >> it.
> >>
> >> the only thing you could do is to optimize for size instead of speed for
> >> 64
> >> bit builds.
> >> But really, the difference is not that big that you should worry about
> >> it.
> >>
> >> --
> >> Kind regards,
> >> Bruno.
> >> bruno_nos_pam_van_dooren@hotmail.com
> >> Remove only "_nos_pam"
> >

xiebopublic
Tue Sep 26 20:39:48 CDT 2006

I've tried UPX and it does not support Win64 .dll although it works
well for win32 .dll.

Best Regards,
Xie, Bo

NickP wrote:
> Have you tried this....
>
> http://upx.sourceforge.net/
>
> It will compress your EXE, I use it for Win32 and it works great...
>
> Nick
>
> <xiebopublic@gmail.com> wrote in message
> news:1159282508.395489.273480@h48g2000cwc.googlegroups.com...
> >I really care about it. My program has a hard footprint limitation
> > (e.g., 300 KB) and my win32 version can meet the footprint limitation,
> > but win64 version can not meet it. Then I must reduce win64 executable
> > footprint. Is there any trick to reduce the win64 footprint limitation?
> >
> > Thanks!
> >
> > Best Regards,
> > Xie, Bo
> >
> > Bruno wrote:
> >> > I am using Visual Studio 2005 Professional Edition to build a .dll for
> >> > Win32 Release, it is 433 KB, for Win64(x86_64) Release, it is 581 KB
> >> > with the exactly same configuration (e.g., /Os). Why? How to reduce the
> >> > Win64 .dll footprint? Thanks!
> >>
> >> 64 bit cpu's have different binary code than 32 bit cpu's. pointers are
> >> 64
> >> bit wide, different instructions, addresses are 64 bit,...
> >> I think this is normal.
> >> given what I know about Itanium, I suspect that Itanium 64 bit binaries
> >> would be even bigger still.
> >>
> >> Remember the golden rule of engineering: if it ain't broken, don't fix
> >> it.
> >>
> >> the only thing you could do is to optimize for size instead of speed for
> >> 64
> >> bit builds.
> >> But really, the difference is not that big that you should worry about
> >> it.
> >>
> >> --
> >> Kind regards,
> >> Bruno.
> >> bruno_nos_pam_van_dooren@hotmail.com
> >> Remove only "_nos_pam"
> >

Alexander
Tue Sep 26 21:59:47 CDT 2006


"NickP" <a@a.com> wrote in message
news:eR8A34Y4GHA.1248@TK2MSFTNGP03.phx.gbl...
> Hey Eric,
>
> I'm not meaning to sound rude either, but if developer has a
> specification that states 300k size limit, then what is he/she supposed to
> do?
>

Challenge the specification. That's what any real engineer should do when
given unreasonable expectations from marketing. Be a real software engineer,
not coding monkey.

bruno_nos_pam_van_dooren
Wed Sep 27 04:06:02 CDT 2006

> > I'm not meaning to sound rude either, but if developer has a
> > specification that states 300k size limit, then what is he/she supposed to
> > do?
> >
>
> Challenge the specification. That's what any real engineer should do when
> given unreasonable expectations from marketing. Be a real software engineer,
> not coding monkey.

I was going to suggest just that.
If specifications are not realistic, try to get them changed (or drop
functionality to decrease code size). Especially if they are 'wants' instead
of 'needs'.

Using the same specification for different platforms is senseless.
That would be like saying that a Hummer should be able to drive 50 miles per
gallon because a yugo can also do it.

--
Kind regards,
Bruno.
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"

NickP
Wed Sep 27 06:57:36 CDT 2006

I agree, only if 300k were an unlreasonable size limit.

But considering we know nothing of the application in question I think that
is difficult to say.

"Bruno van Dooren [MVP VC++]" <bruno_nos_pam_van_dooren@hotmail.com> wrote
in message news:32D2568A-31E2-4333-8549-EA90329C7F09@microsoft.com...
>> > I'm not meaning to sound rude either, but if developer has a
>> > specification that states 300k size limit, then what is he/she supposed
>> > to
>> > do?
>> >
>>
>> Challenge the specification. That's what any real engineer should do when
>> given unreasonable expectations from marketing. Be a real software
>> engineer,
>> not coding monkey.
>
> I was going to suggest just that.
> If specifications are not realistic, try to get them changed (or drop
> functionality to decrease code size). Especially if they are 'wants'
> instead
> of 'needs'.
>
> Using the same specification for different platforms is senseless.
> That would be like saying that a Hummer should be able to drive 50 miles
> per
> gallon because a yugo can also do it.
>
> --
> Kind regards,
> Bruno.
> bruno_nos_pam_van_dooren@hotmail.com
> Remove only "_nos_pam"
>

Alex
Wed Sep 27 09:29:11 CDT 2006

NickP wrote:
> I agree, only if 300k were an unlreasonable size limit.
>
> But considering we know nothing of the application in question I think that
> is difficult to say.

Personally, I encountered module size limitations only once
in my career: while working with embedded systems. That's
the only place when size limitation was reasonable because
of hardware properties. To impose any limitation on module
size for modern desktop/workstation computers sounds inane
for me. I cannot imagine any real situation where the
difference between 300K module and 500K module will gain you
anything (except headache for developers, therefore
increased sales for coffee and painkillers vendors).

Tim
Fri Sep 29 00:33:34 CDT 2006

"NickP" <a@a.com> wrote:
>
>I agree, only if 300k were an unlreasonable size limit.

It IS entirely unreasonable to expect the 64-bit version of a DLL to be the
same size as the 32-bit version. That's just ignorant. Data items and
pointers in Win64 are twice as big as in Win32, and the same instructions
will be larger as well.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

NickP
Fri Sep 29 04:01:07 CDT 2006

Yes

> It IS entirely unreasonable to expect the 64-bit version of a DLL to be
> the
> same size as the 32-bit version. That's just ignorant. Data items and
> pointers in Win64 are twice as big as in Win32, and the same instructions
> will be larger as well.

ACK.

Did I say otherwise?

I merely said it's reasonable to pose limits on the size of compile
software!

So get off your high horse!

Bruno
Fri Sep 29 03:52:08 CDT 2006

>>I agree, only if 300k were an unlreasonable size limit.
>
> It IS entirely unreasonable to expect the 64-bit version of a DLL to be
> the
> same size as the 32-bit version. That's just ignorant. Data items and
> pointers in Win64 are twice as big as in Win32, and the same instructions
> will be larger as well.


That was my point exactly.

And if they would support itanium, they would be in for a nasty surprise.
It uses VLIW, meaning it executes 6 instructions in parallel. For compilers
this it is very difficult to know what can be parallellized or not, when
compiling general purpose code. Some people told me that the average is only
2 concurrent instructions per instruction cycle, with 4 NOPs for the other
pipelines.

The resulting binary would thus be even bigger, since it contains a lot of
useless stuffing, as well as having larger pointers.

--

Kind regards,
Bruno van Dooren
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"