LOW LEVEL C - What else?

[clive]

The 4K page comes from the 386, the cluster size on the disk has very little impact. What Windows wants to have is a directly mappable file, that it can pin in memory directly from disc, and not have to load and shuffle into a page backed by the page file.

There are two alignments, one in memory, and one in the file. The PE file format has historically been quite flexible. You can pick field combinations that cause the "Not a valid Win32 executable" message to be emitted. Most specifically the Base address (64K aligned), and the Virtual Address (>= 4K).

The linker and libraries can impact how the import table is built, and some of the sections could technically be coalesced. We could certainly examine the PE files and come to some specific conclusions, but this is not high on my priorities list. Making files incredibly small falls into the dont-care category as they usually get classed as heuristically bad by the AV tools.

I was building under Vista, using MASM32 (10) libraries

[redskull]

But increasing the cluster size to, say, 8K would certainly increase the size of the file on disk, while not the actual file size itself.  And while all you say is true, we are (presumably) talking about identical code, build tools, and libraries; in this case, there would have to be some sort of code in the linker that builds the PE file with an extra 512 bytes, depending on what version of Windows is running, which I find unlikely (though nothing is impossible).  I won't lose any sleep over it, for sure, but it would be interesting to know what's in those bytes.

-r

[clive]

File mapping is page based. The size of the cluster impacts the amount of space wasted on the disc (allocation quantum), but the memory pinning is going to occur on a page/sector basis.

I'm pretty sure the linker doesn't care, or test, what the cluster size is. The different sizes here most likely relate to our varied choice of assemblers, libraries, and linkers. Using the same set I could show consistency from NT through Vista.

[frktons]

If you are curious about the extra 512 bytes, have a look at the
exe produced under win7, disassemble it, edit with an hexeditor or
whatever you think is fit.

I am unable to verify things like this at the moment.

I include the exe in case you like to have a look.

Frank

[redskull]

Apparently it's a relocation table.  Lord knows why LINK stuck one on there, your version must default to using ASLR or something.  Maybe use /DYNAMICBASE:NO and see what you get?

Code Select Expand

SECTION HEADER #4
  .reloc name
      48 virtual size
    4000 virtual address (00404000 to 00404047)
     200 size of raw data
     A00 file pointer to raw data (00000A00 to 00000BFF)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
42000040 flags
         Initialized Data
         Discardable
         Read Only

RAW DATA #4
  00404000: 00 10 00 00 34 00 00 00 0E 30 1A 30 2E 30 34 30  ....4....0.0.040
  00404010: 77 30 83 30 88 30 99 30 A7 30 CB 30 E2 30 F2 30  w0.0.0.0§0Ë0â0ò0
  00404020: F8 30 FE 30 04 31 0A 31 10 31 16 31 1C 31 22 31  ø0þ0.1.1.1.1.1"1
  00404030: 28 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00  (1..............
  00404040: 00 00 00 00 00 00 00 00                          ........

BASE RELOCATIONS #4
    1000 RVA,       34 SizeOfBlock
       E  HIGHLOW            00403038
      1A  HIGHLOW            00403021
      2E  HIGHLOW            00403040
      34  HIGHLOW            0040303C
      77  HIGHLOW            00403038
      83  HIGHLOW            0040303C
      88  HIGHLOW            00403000
      99  HIGHLOW            00403038
      A7  HIGHLOW            00403038
      CB  HIGHLOW            00403038
      E2  HIGHLOW            00403038
      F2  HIGHLOW            00402000
      F8  HIGHLOW            00402004
      FE  HIGHLOW            00402008
     104  HIGHLOW            0040200C
     10A  HIGHLOW            00402010
     110  HIGHLOW            00402014
     116  HIGHLOW            00402018
     11C  HIGHLOW            0040201C
     122  HIGHLOW            00402020
     128  HIGHLOW            00402024
       0  ABS

  Summary

        1000 .data
        1000 .rdata
        1000 .reloc
        1000 .text


[Vortex]

Playing with the alignment value is not always the best solution. Not all versions of Windows can run those executables built with minimal alignment values.

[jj2007]

For comparison. PeView is a good tool for doing this.

[frktons]

Playing with the alignment value is not always the best solution. Not all versions of Windows can run those executables built with minimal alignment values.

In my win7 if I compile with the /ALIGN:16 the exe is smaller but it won't run.

For comparison. PeView is a good tool for doing this.

Your program is a lot different, it doesn't use all the APIs for a fixed size 80x25
console, and doesn't use colors or positioning on the centre of the screen as well. ::)

If it is only for seeing what's inside, it should be closer to the one we are analysing.

[jj2007]

Playing with the alignment value is not always the best solution. Not all versions of Windows can run those executables built with minimal alignment values.

I wonder whether there is a practical case to demonstrate this. Does the attachment choke for anybody? It's align 16 and runs fine on XP...

[frktons]

Playing with the alignment value is not always the best solution. Not all versions of Windows can run those executables built with minimal alignment values.

I wonder whether there is a practical case to demonstrate this. Does the attachment choke for anybody? It's align 16 and runs fine on XP...

On win7 it doesn't run  ::)

message: "The application was unable to start correctly".

Well win7 is a little bit different from win xp, it doesn't like small things  :lol

[jj2007]

Your program is a lot different, it doesn't use all the APIs for a fixed size 80x25
console, and doesn't use colors or positioning on the centre of the screen as well. ::)

If it is only for seeing what's inside, it should be closer to the one we are analysing.

No problem - see red's version attached. 1536 bytes with standard alignment, so it should run on Win7 if alignment is the problem.

[frktons]

Your program is a lot different, it doesn't use all the APIs for a fixed size 80x25
console, and doesn't use colors or positioning on the centre of the screen as well. ::)

If it is only for seeing what's inside, it should be closer to the one we are analysing.

No problem - see red's version attached. 1536 bytes with standard alignment, so it should run on Win7 if alignment is the problem.

Same error. Unable to start....
Well apparently the startup code produced is not compatible with win7  ::)

[jj2007]

Same error. Unable to start....

Well, sounds like a good occasion to isolate the culprit. Take the source code, and try various options. BTW, I used polink.

[frktons]

Same error. Unable to start....

Well, sounds like a good occasion to isolate the culprit. Take the source code, and try various options. BTW, I used polink.

I compiled the pgm you posted and the exe is again 3072 bytes and it run on win7.
I used the "console assemble and link" of masm32 editor, don't know if the polink was invoked,
You inserted some new code for it but I don't know if it works inside masm32 editor.

In my opinion  win7 has a startup code that is somewhat bigger then previous
windows xp edition. But I am not an expert. And it is a 64 bit edition as well.
Maybe it counts in all the scene.

[jj2007]

Which versions run from the attachment?