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) ?

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

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.

"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).

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.

Read the documentation for whatever file read function you are using. For example if you wrote:

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:



blocks would equal zero, and no data would be read and buffer would be unchanged.

That's simply not possible, since a file (.exe or any other type) always consists of a whole number of 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.

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?

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.

thank you so much !!