Image size increases if built with separate_object_root

NTDEV
1

Hello,

I am trying to make my sources read-only and to achieve the same, I am using
OBJECT_ROOT. I see that the size of the binaries and the .pdb files
increase. I can understand why .pdb can grow, but any reason why the binary
file size increases? Note that except for OBJECT_ROOT all other parameters
are same across separate_object_root specified vs not specified.

I appreciate any information on how to avoid the bulge in size.

Regards,
Chakri

2

I guess the real question is why? When you execute BUILD.exe the targets, obj, and pdb files are created in a “objchk_wxp_x86” or “objfre_wxp_x86” path. The names are changed for free or checked, OS, and platforms. It sounds like you have spent time doing something already done for you. Unless, its the SOURCES file itself you are trying to set to read only, and I must say I’m scratching various parts of my anatomy wondering why you are wasting time on this.

Gary G. Little

----- Original Message -----
From: “Chakri”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 13, 2011 3:14:03 AM
Subject: [ntdev] Image size increases if built with separate_object_root

Hello,

I am trying to make my sources read-only and to achieve the same, I am using
OBJECT_ROOT. I see that the size of the binaries and the .pdb files
increase. I can understand why .pdb can grow, but any reason why the binary
file size increases? Note that except for OBJECT_ROOT all other parameters
are same across separate_object_root specified vs not specified.

I appreciate any information on how to avoid the bulge in size.

Regards,
Chakri

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

I understand that objchk_wxp_x86/objfre_wxp_x86 are created. But, I want to
treat my entire directory structure of the source (NOT SOURCES file) files
as read-only.

Simple use case - it helps one to build source files in source repository
system without having to create all the intermediate files in the repository
itself. That keeps the repository clean.

I hope that answers your WHY part; although my “real” question is “why the
binary size differs depending on whether separate_object_root is used or
not?”.

-Chakri

“Gary G. Little” wrote in message
news:xxxxx@ntdev…
I guess the real question is why? When you execute BUILD.exe the targets,
obj, and pdb files are created in a “objchk_wxp_x86” or “objfre_wxp_x86”
path. The names are changed for free or checked, OS, and platforms. It
sounds like you have spent time doing something already done for you.
Unless, its the SOURCES file itself you are trying to set to read only, and
I must say I’m scratching various parts of my anatomy wondering why you are
wasting time on this.

Gary G. Little

----- Original Message -----
From: “Chakri”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 13, 2011 3:14:03 AM
Subject: [ntdev] Image size increases if built with separate_object_root

Hello,

I am trying to make my sources read-only and to achieve the same, I am using
OBJECT_ROOT. I see that the size of the binaries and the .pdb files
increase. I can understand why .pdb can grow, but any reason why the binary
file size increases? Note that except for OBJECT_ROOT all other parameters
are same across separate_object_root specified vs not specified.

I appreciate any information on how to avoid the bulge in size.

Regards,
Chakri

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

(no I don’t have an answer for you)

Interesting… How MUCH do the sizes change? Can you give us a couple of example file sizes (with and without OBJECT_ROOT specified)?

Peter
OSR

5

And to go one step further, if you have dumpbin (comes with Visual
Studio) how about a dumpbin /headers of the two sys files. This will
likely pinpoint the section that is growing.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@osr.com” wrote in message news:xxxxx@ntdev:

> (no I don’t have an answer for you)
>
> Interesting… How MUCH do the sizes change? Can you give us a couple of example file sizes (with and without OBJECT_ROOT specified)?
>
> Peter
> OSR

6

Excellent suggestion.

If you don’t have VS installed for the dumpbin command, just use “link /dump /headers” with the linker from the WDK.

Peter
OSR

7

I’d still ask why do you want to bother? You can easily solve that problem by establishing the discipline of what is placed in the repository and possibly providing a tutorial and/or checklist for checking things into the repository. I’m assuming here you are referring a source control system such as Visual Source Safe or SVN. It’s a sign of the totally clueless, brain-dead or just plane old lazy if someone adds all directories, sub-directories, and source files to such a repository. But that’s personal opinion.

As to why the file sizes dramatically increase, that I cannot say, since I’ve not attempted what you describe.

Gary G. Little

----- Original Message -----
From: “Chakri”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 13, 2011 7:59:11 AM
Subject: Re:[ntdev] Image size increases if built with separate_object_root

I understand that objchk_wxp_x86/objfre_wxp_x86 are created. But, I want to
treat my entire directory structure of the source (NOT SOURCES file) files
as read-only.

Simple use case - it helps one to build source files in source repository
system without having to create all the intermediate files in the repository
itself. That keeps the repository clean.

I hope that answers your WHY part; although my “real” question is “why the
binary size differs depending on whether separate_object_root is used or
not?”.

-Chakri

“Gary G. Little” wrote in message
news:xxxxx@ntdev…
I guess the real question is why? When you execute BUILD.exe the targets,
obj, and pdb files are created in a “objchk_wxp_x86” or “objfre_wxp_x86”
path. The names are changed for free or checked, OS, and platforms. It
sounds like you have spent time doing something already done for you.
Unless, its the SOURCES file itself you are trying to set to read only, and
I must say I’m scratching various parts of my anatomy wondering why you are
wasting time on this.

Gary G. Little

----- Original Message -----
From: “Chakri”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 13, 2011 3:14:03 AM
Subject: [ntdev] Image size increases if built with separate_object_root

Hello,

I am trying to make my sources read-only and to achieve the same, I am using
OBJECT_ROOT. I see that the size of the binaries and the .pdb files
increase. I can understand why .pdb can grow, but any reason why the binary
file size increases? Note that except for OBJECT_ROOT all other parameters
are same across separate_object_root specified vs not specified.

I appreciate any information on how to avoid the bulge in size.

Regards,
Chakri

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

You’re taking issue with his wish to build somewhere other than his source tree? Why? Personally, I HATE when people build in the source tree, but that’s a matter of opinion.

This is hardly an exotic request and your solution has nothing to do with his question necessarily.

mm

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Thursday, January 13, 2011 10:38 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Image size increases if built with separate_object_root

I’d still ask why do you want to bother? You can easily solve that problem by establishing the discipline of what is placed in the repository and possibly providing a tutorial and/or checklist for checking things into the repository. I’m assuming here you are referring a source control system such as Visual Source Safe or SVN. It’s a sign of the totally clueless, brain-dead or just plane old lazy if someone adds all directories, sub-directories, and source files to such a repository. But that’s personal opinion.

As to why the file sizes dramatically increase, that I cannot say, since I’ve not attempted what you describe.

Gary G. Little

----- Original Message -----
From: “Chakri”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 13, 2011 7:59:11 AM
Subject: Re:[ntdev] Image size increases if built with separate_object_root

I understand that objchk_wxp_x86/objfre_wxp_x86 are created. But, I want to
treat my entire directory structure of the source (NOT SOURCES file) files
as read-only.

Simple use case - it helps one to build source files in source repository
system without having to create all the intermediate files in the repository
itself. That keeps the repository clean.

I hope that answers your WHY part; although my “real” question is “why the
binary size differs depending on whether separate_object_root is used or
not?”.

-Chakri

“Gary G. Little” wrote in message
news:xxxxx@ntdev…
I guess the real question is why? When you execute BUILD.exe the targets,
obj, and pdb files are created in a “objchk_wxp_x86” or “objfre_wxp_x86”
path. The names are changed for free or checked, OS, and platforms. It
sounds like you have spent time doing something already done for you.
Unless, its the SOURCES file itself you are trying to set to read only, and
I must say I’m scratching various parts of my anatomy wondering why you are
wasting time on this.

Gary G. Little

----- Original Message -----
From: “Chakri”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 13, 2011 3:14:03 AM
Subject: [ntdev] Image size increases if built with separate_object_root

Hello,

I am trying to make my sources read-only and to achieve the same, I am using
OBJECT_ROOT. I see that the size of the binaries and the .pdb files
increase. I can understand why .pdb can grow, but any reason why the binary
file size increases? Note that except for OBJECT_ROOT all other parameters
are same across separate_object_root specified vs not specified.

I appreciate any information on how to avoid the bulge in size.

Regards,
Chakri

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

9

Chakri wrote:

I hope that answers your WHY part; although my “real” question is “why the
binary size differs depending on whether separate_object_root is used or
not?”.

A quick session with a hex editor would have confirmed the obvious
answer. In a checked build, the full path to the source code and
associated PDB file is stored inside the binary.

This does not happen in a free build, and in a free build you’ll find
the binaries are the same size.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

10

Nice, Tim… thanks.

So… we’re talking a TINY increase in file size?

Hmmmm…

Peter
OSR

11

Oh, man. I thought you’d be one of the first to pounce on that one, Peter.

Sorry, Tim, but you are incorrect. The default behavior for WDK builds is
to embed the path to the .pdb in release builds, as well. I believe there
is an environment var that you can set to suppress that, but by default it’s
there.

D:\Projects\Trunk\Foo\filter\objfre_wxp_x86\i386>strings -n 20 Foo.sys

Strings v2.41
Copyright (C) 1999-2009 Mark Russinovich
Sysinternals - www.sysinternals.com

!This program cannot be run in DOS mode.

d:\projects\trunk\foo\filter\objfre_wxp_x86\i386\Foo.pdb
EtwRegisterClassicProvider
[snip]

Phil

Philip D. Barila??? (303) 776-1264

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, January 13, 2011 11:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Image size increases if built with separate_object_root



Nice, Tim… thanks.

So… we’re talking a TINY increase in file size?

Hmmmm…

Peter
OSR

12

Philip D Barila wrote:

Oh, man. I thought you’d be one of the first to pounce on that one, Peter.

Sorry, Tim, but you are incorrect. The default behavior for WDK builds is
to embed the path to the .pdb in release builds, as well. I believe there
is an environment var that you can set to suppress that, but by default it’s
there.

Hmm. I did a quick test before I replied, so I wouldn’t appear to be an
idiot, and the sizes were the same. However, I see the path embedded in
my own free builds. Let me run that test again…

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

13

Tim Roberts wrote:

Philip D Barila wrote:
> Oh, man. I thought you’d be one of the first to pounce on that one, Peter.
>
> Sorry, Tim, but you are incorrect. The default behavior for WDK builds is
> to embed the path to the .pdb in release builds, as well. I believe there
> is an environment var that you can set to suppress that, but by default it’s
> there.
Hmm. I did a quick test before I replied, so I wouldn’t appear to be an
idiot, and the sizes were the same. However, I see the path embedded in
my own free builds. Let me run that test again…

Yes, I fooled myself. The path is embedded once in a free build, in a
table that is apparently has enough “pad” built-in that a longer path
doesn’t increase the length of the file. It is included multiple times
in a checked build, and the size goes up as a result.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

14

> This does not happen in a free build, and in a free build you’ll find

the binaries are the same size.

At least in 6001.18002 the full PDB pathname is there even in release builds.

More so, release build of the same tree on 2 different machines differ only in this path and several PE header values (build date and checksum being 2 of them).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

15

Hello Peter,

The files sizes for win7 free build are:

Normal build - 1,487,360 mydrv.sys

OBJECT_ROOT - 1,494,128 mydrv.sys

Don, I will try dumpbin.

-Chakri

“Don Burn” wrote in message news:xxxxx@ntdev…
> And to go one step further, if you have dumpbin (comes with Visual Studio)
> how about a dumpbin /headers of the two sys files. This will likely
> pinpoint the section that is growing.
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
>
> “xxxxx@osr.com” wrote in message news:xxxxx@ntdev:
>
>> (no I don’t have an answer for you)
>>
>> Interesting… How MUCH do the sizes change? Can you give us a couple of
>> example file sizes (with and without OBJECT_ROOT specified)?
>>
>> Peter
>> OSR
>
>

16

On 1/13/2011 7:49 PM, xxxxx@osr.com wrote:

So… we’re talking a TINY increase in file size?

On 1/13/2011 9:58 PM, Chakri wrote:

The files sizes for win7 free build are:

Normal build - 1,487,360 mydrv.sys

OBJECT_ROOT - 1,494,128 mydrv.sys

6768 bytes is *tiny*???

Well… being a WINDOWS build, you are of course right.

17

On 1/14/2011 7:51 AM, Hagen Patzke wrote:

6768 bytes is *tiny*???

Before the bashing begins: I was and am working with embedded systems.

Here, 4k more code can make the difference between everything being OK,
or with your code not fitting into flash memory any more (or worse, into
ROM). If you are unlucky, this can be “end of game::end of project”.

In former times, it was also not so uncommon in the PC domain to be
aware of small changes: if anything changed that was not supposed to
change, it could point to a severe problem. (And often it did.)

Later, with bigger memories, these issues had to be checked b/c they
could point to a security risk, i.e. “if you do not understand where a
change comes from and *WHY* it takes place, it is suspicious”.

With the advent of multigigabyte memories in the PC domain, everyone now
obviously just thinks “oh well, who cares”.

[NB: With regard to security, Microsoft could be regarded as actively
promoting a kind of “just use, don’t think^H^H^H^H^Hworry” policy by not
releasing WDF source.]

18

You’ve heard the saying “the straw that broke the camel’s back”? Well, in ANY system, it’s possible to find the point where “4K more code can make the difference.”

If you’re working in a limited memory embedded environment, I expect you’ll take all the necessary extra steps to ensure your executables are optimized for size and stripped of every possible unnecessary piece of crap.

But in most cases and in most places 6768 bytes is SMALLER than TINY… given we’re routinely thinking of systems (yes, and even embedded systems) with multiple gigabytes of memory.

Yup. That’s exactly what *I* usually think, to be perfectly honest. 2GB of memory costs US$23 on Amazon. There’s no way I can match that in terms of value.

Peter
OSR

19

Chakri,

What sections are growing?

Phil

Philip D. Barila (303) 776-1264

20

Hagen,

I have to admit it’s been awhile since I had to worry about my system code
fitting in 12K, but I do remember it. No bashing from here. :slight_smile:

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Friday, January 14, 2011 1:06 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Image size increases if built with separate_object_root

On 1/14/2011 7:51 AM, Hagen Patzke wrote:

6768 bytes is *tiny*???

Before the bashing begins: I was and am working with embedded systems.

Here, 4k more code can make the difference between everything being OK, or
with your code not fitting into flash memory any more (or worse, into ROM).
If you are unlucky, this can be “end of game::end of project”.

In former times, it was also not so uncommon in the PC domain to be aware of
small changes: if anything changed that was not supposed to change, it could
point to a severe problem. (And often it did.)

Later, with bigger memories, these issues had to be checked b/c they could
point to a security risk, i.e. “if you do not understand where a change
comes from and *WHY* it takes place, it is suspicious”.

With the advent of multigigabyte memories in the PC domain, everyone now
obviously just thinks “oh well, who cares”.

[NB: With regard to security, Microsoft could be regarded as actively
promoting a kind of “just use, don’t think^H^H^H^H^Hworry” policy by not
releasing WDF source.]

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

__________ Information from ESET Smart Security, version of virus signature
database 5788 (20110114) __________

The message was checked by ESET Smart Security.

http://www.eset.com