I am using only 8.3 names for both directories and source files, but did
find some strange things happening today. I was reorganizing some source
code, and when I made a build I noticed the sys file had a different size.
After checking everything else, I compared every file with the former
location. All sources are equal. I have tried this with both the 3790 and
the 3790.1830 DDK/IFS Kit, and environment is “setenv w2k fre”.
When building at “e:\src\fsfmgr” the size of the driver is 18688 bytes,
when building exactly the same files at
“e:\tmp\tmp3ab\tmp4cd\tmp5de\tmp6fg\src\fsfmgr” (just a test example, no
example of how I organize code ;)) the size becomes 18816 bytes. When
comparing these two files in a binary diff utility, it shows that quite
some bytes are different through the code section, and there is also some
additional data a few places. When comparing the obj files generated, they
do also have more-than-normal difference in the content. But both drivers
seems to work correct, but have not made extensive testings for this yet.
Anyone else having seen this, and knows more about the cause and if the
additional information does cause something to break…?
/Ola
Absolute paths are often baked into the binary when the FILE macro is
used. Debug builds often use FILE to implicitly pass diagnostic
information to functions.
Use your binary diff tool, find the sections that have changed, and view
them in “text” mode. You’ll probably find that they contain path strings.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ola J. Presterud
Sent: Tuesday, October 11, 2005 8:13 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Strange behaviour from build
I am using only 8.3 names for both directories and source files, but did
find some strange things happening today. I was reorganizing some source
code, and when I made a build I noticed the sys file had a different size.
After checking everything else, I compared every file with the former
location. All sources are equal. I have tried this with both the 3790 and
the 3790.1830 DDK/IFS Kit, and environment is “setenv w2k fre”.
When building at “e:\src\fsfmgr” the size of the driver is 18688 bytes, when
building exactly the same files at
“e:\tmp\tmp3ab\tmp4cd\tmp5de\tmp6fg\src\fsfmgr” (just a test example, no
example of how I organize code ;)) the size becomes 18816 bytes. When
comparing these two files in a binary diff utility, it shows that quite some
bytes are different through the code section, and there is also some
additional data a few places. When comparing the obj files generated, they
do also have more-than-normal difference in the content. But both drivers
seems to work correct, but have not made extensive testings for this yet.
Anyone else having seen this, and knows more about the cause and if the
additional information does cause something to break…?
/Ola
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stonestreetone.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Your short path is 13 char long, your long one is 45 for a difference of 32.
The difference in sys file sizes is 128.
Perhaps the path is stored in the binary 4 times?
Ola J. Presterud wrote:
I am using only 8.3 names for both directories and source files, but did
find some strange things happening today. I was reorganizing some source
code, and when I made a build I noticed the sys file had a different size.
After checking everything else, I compared every file with the former
location. All sources are equal. I have tried this with both the 3790 and
the 3790.1830 DDK/IFS Kit, and environment is “setenv w2k fre”.
When building at “e:\src\fsfmgr” the size of the driver is 18688 bytes,
when building exactly the same files at
“e:\tmp\tmp3ab\tmp4cd\tmp5de\tmp6fg\src\fsfmgr” (just a test example, no
example of how I organize code ;)) the size becomes 18816 bytes. When
comparing these two files in a binary diff utility, it shows that quite
some bytes are different through the code section, and there is also some
additional data a few places. When comparing the obj files generated, they
do also have more-than-normal difference in the content. But both drivers
seems to work correct, but have not made extensive testings for this yet.
Anyone else having seen this, and knows more about the cause and if the
additional information does cause something to break…?
/Ola
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@earthlink.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
Ola J. Presterud wrote:
I am using only 8.3 names for both directories and source files, but did
find some strange things happening today. I was reorganizing some source
code, and when I made a build I noticed the sys file had a different size.
After checking everything else, I compared every file with the former
location. All sources are equal. I have tried this with both the 3790 and
the 3790.1830 DDK/IFS Kit, and environment is “setenv w2k fre”.
When building at “e:\src\fsfmgr” the size of the driver is 18688 bytes,
when building exactly the same files at
“e:\tmp\tmp3ab\tmp4cd\tmp5de\tmp6fg\src\fsfmgr” (just a test example, no
example of how I organize code ;)) the size becomes 18816 bytes. When
comparing these two files in a binary diff utility, it shows that quite
some bytes are different through the code section, and there is also some
additional data a few places. When comparing the obj files generated, they
do also have more-than-normal difference in the content. But both drivers
seems to work correct, but have not made extensive testings for this yet.
Anyone else having seen this, and knows more about the cause and if the
additional information does cause something to break…?
It’s not terribly surprising, and the answer would be clear if you
looked at the source with a hex dump utility. The complete path to the
source for each .obj is embedded in the binary for that .obj, and hence
in the .sys, even for free builds. Doesn’t your binary diff utility
show you ASCII? That should have made it clear.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On Tue, 11 Oct 2005 09:00:46 -0700, Tim Roberts wrote:
It’s not terribly surprising, and the answer would be clear if you
looked at the source with a hex dump utility. The complete path to the
source for each .obj is embedded in the binary for that .obj, and hence
in the .sys, even for free builds. Doesn’t your binary diff utility
show you ASCII? That should have made it clear.
Yes, I have of course looked at it with ASCII. Had it been only the
filename, where the only one referenced with full build path in the sys
file is the PDB, it hadn’t been that strange and I hadn’t bothered
wondering why. But as I say, in the code part of the file there is a lot of
different single bytes (or sometimes words). They are not normal ASCII
characters, and not forming any kind of pattern. This is very unusual in
compiled EXE files when they are built within the same conditions, and also
the first time I have seen with drivers. Even when a co-worker compiles
this driver code on a very different computer setup (some thousends of
kilometers away), they turns out as the one compiled with the short path.
The only differences which always is present is the header (which I guess
contains some date information) and the PDB path.
/Ola
Have you disassembled the different sections? Does it look like valid
assembly code, or something different?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ola J. Presterud
Sent: Tuesday, October 11, 2005 1:47 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Strange behaviour from build
On Tue, 11 Oct 2005 09:00:46 -0700, Tim Roberts wrote:
It’s not terribly surprising, and the answer would be clear if you
looked at the source with a hex dump utility. The complete path to
the source for each .obj is embedded in the binary for that .obj, and
hence in the .sys, even for free builds. Doesn’t your binary diff
utility show you ASCII? That should have made it clear.
Yes, I have of course looked at it with ASCII. Had it been only the
filename, where the only one referenced with full build path in the sys file
is the PDB, it hadn’t been that strange and I hadn’t bothered wondering why.
But as I say, in the code part of the file there is a lot of different
single bytes (or sometimes words). They are not normal ASCII characters, and
not forming any kind of pattern. This is very unusual in compiled EXE files
when they are built within the same conditions, and also the first time I
have seen with drivers. Even when a co-worker compiles this driver code on a
very different computer setup (some thousends of kilometers away), they
turns out as the one compiled with the short path.
The only differences which always is present is the header (which I guess
contains some date information) and the PDB path.
/Ola
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stonestreetone.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
On Tue, 11 Oct 2005 13:58:36 -0400, Arlie Davis wrote:
Have you disassembled the different sections? Does it look like valid
assembly code, or something different?
Nope, havn’t done that yet. Will check it tomorrow at the office!
/Ola