#1
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2005
    Posts
    227
    Rep Power
    0

    Exclamation Is .exe in multiples of 8-bits?


    Hi, I'm trying to read an EXE as chunks of 8-bits. My question: Is .exe in multiple of 8-bits?

    I mean, say: the code compiles and generates an exe of 61-bits. Would it be converted to 64-bits automatically? or would it remain 61-bits on HD as binary file (.exe)?

    If it is appended, what are the three bits?

    Or is it that the compiler ALWAYS generates in multiple of 8-bits?

    2) Secondly, we know HD saves files in minimum of 1kbyte chunk.
    If the code generates 64-bits, Are the rest of the (1024-8) bytes NULL bytes?

    If I try to read the binary .exe 1kbyte file in char[] buffer in C\C++, would the filestream read 1kbytes or 64 bits (8 bytes) ?
  2. #2
  3. Contributing User

    Join Date
    Aug 2003
    Location
    UK
    Posts
    5,109
    Rep Power
    1802
    At least on an x86 PC a byte is the smallest addressable unit of memory. Moreover the filesystem works as a byte storage system, so no file of any type can have a number of bits that is not a multiple of 8 even if that means including redundant bits.

    It is the linker not the compiler than generates the exe file.

    That said, the equation makes little sense. An exe is an object file format; it contains code which is intrinsically 32 bit, but it also contains metadata that may contain structures containing fields of various sizes including bitfields.

    You can find documents on the EXE file format here
  4. #3
  5. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    What operating system are you using?

    In DOS/Windows, an .exe file has a header with information about the executable, such as what its memory and heap requirements are. It's only after that header (whose length you do not know) that any object code might exist. But even then, there are addresses within that object code that is only relative to the initial addresses of the object code. All those addresses will be resolved and fixed, but only by the program loader, whose responsibility is to lead that code into an actual memory location and then to fix all those addresses to that actual starting memory location that cannot ever be known until the program is finally loaded into memory.

    Please reconsider your questions in light of that information.
  6. #4
  7. Contributing User

    Join Date
    Aug 2003
    Location
    UK
    Posts
    5,109
    Rep Power
    1802
    Originally Posted by speedbooster
    2) Secondly, we know HD saves files in minimum of 1kbyte chunk.
    "We" know nothing of the sort. On an NTFS volume, the cluster size is 4K for volumes greater than 2Gb (which is any disk capable of hosting Windows).

    Originally Posted by speedbooster
    If the code generates 64-bits, Are the rest of the (1024-8) bytes NULL bytes?
    That is down to the file system. In most cases I imagine that it would leave the unused space entirely alone rather than unnecessarily writing data. Why would you care? The padding is not part of the file, and cannot be read by any normal file handling functions. You'd have to access the raw disk to see that, and the OS makes that difficult to do without specialist kernel level coding.

    Originally Posted by speedbooster
    If I try to read the binary .exe 1kbyte file in char[] buffer in C\C++, would the filestream read 1kbytes or 64 bits (8 bytes) ?
    Read the documentation for whatever file read function you are using. For example if you wrote:
    Code:
    size_t bytes = fread ( buffer, 1, 1024, fp );
    bytes would equal 8 and 8 bytes would b read - the remaining bytes in buffer would be untouched.

    On the other hand if you wrote:

    Code:
    size_t blocks = fread ( buffer, 1024, 1, fp );
    blocks would equal zero, and no data would be read and buffer would be unchanged.
    Last edited by clifford; January 5th, 2013 at 05:21 AM.
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Feb 2004
    Location
    San Francisco Bay
    Posts
    1,939
    Rep Power
    1313
    Originally Posted by speedbooster
    I mean, say: the code compiles and generates an exe of 61-bits.
    That's simply not possible, since a file (.exe or any other type) always consists of a whole number of bytes.

    Originally Posted by speedbooster
    2) Secondly, we know HD saves files in minimum of 1kbyte chunk.
    If the code generates 64-bits, Are the rest of the (1024-8) bytes NULL bytes?
    I don't know, and neither should you, since you're never going to see those "extra" bytes (if they exist at all, which depends on the filesystem).

    All clear now? A file is a sequence of bytes. It's not a sequence of individual bits, nor is it a sequence of 1024-byte chunks.
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2005
    Posts
    227
    Rep Power
    0
    thanks a lot guys, it was a great help.

    one last clarification:

    so in an 8-byte file, on NTFS, we could only read the first 8-bytes in buffer.
    But actually on the HD, the rest of (4k-8) bytes would be *whatever the previous value was there on sector*.

    Now by 4kb chunk, it means that NTFS 'reserves' the 4kb for the file to use? although it is currently using only 8bytes. correct?

    2) and if the file exceeds to 7kb later on, and there is no adjacent 4kb chunk available, it would be assigned somewhere else, pointed by the last byte(s) of the first chunk?
  12. #7
  13. Contributing User

    Join Date
    Aug 2003
    Location
    UK
    Posts
    5,109
    Rep Power
    1802
    Originally Posted by speedbooster
    and if the file exceeds to 7kb later on, and there is no adjacent 4kb chunk available, it would be assigned somewhere else, pointed by the last byte(s) of the first chunk?
    I don't think NTFS is quite that simplistic, but the point is that the file system implementation (of which NTFS is only one) is abstracted away by the standard library and/or the OS API, so the actual implementation is transparent and files are accessed as byte streams.
  14. #8
  15. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2005
    Posts
    227
    Rep Power
    0
    thank you so much !!

IMN logo majestic logo threadwatch logo seochat tools logo