For initialised data we use db, dw, dq, dp,... Then rb, rw,... is to reserve space. What?s the difference then between initialised data and reserved data space?
And is it possible to reserve uninitialised data?
I have tryed:
and it gives a error:invalid argument
And is it possible to reserve uninitialised data?
I have tryed:
fileName: times 127 rb ?
and it gives a error:invalid argument
You have combined two different ways of declaring uninitialized data, the correct are:
or (recommended):
Uninitialized data declared at the end of section won't use the space of your program file, it will be only allocated in memory when loading the program.
fileName: times 127 db ?
or (recommended):
fileName rb 127
Uninitialized data declared at the end of section won't use the space of your program file, it will be only allocated in memory when loading the program.
Thank you,
I was sort of confusing what "rb" meant.
Now it?s completely clear.
If we decalre uninit. data at the beginning of sect it will use space then?
I was sort of confusing what "rb" meant.
Now it?s completely clear.
"Uninitialized data declared at the end of section won't use the space of your program file, it will be only allocated in memory when loading the program."
If we decalre uninit. data at the beginning of sect it will use space then?
section '.data'
buffer rb 1024
gizmo dd 1234h
another_buffer rb 1024
section '.idata'....
If we decalre uninit. data at the beginning of sect it will use space then?
Yes, your '.data' section will be 1028 bytes long in file (but it will be aligned to 1536, because PE files for Win32 must have 512 bytes alignment), but it will become 2052 bytes in memory (will be aligned to 4096). First 1024 bytes in file will be filled with zeros.
Interesting, but weird, who aligns that then, the PE format itself, or Windows?
Btw, I?ve seen your beer example (yes, I also needed some space too ;) and it only takes 1K, and you achieve this by removing all sections, right?
(What?s your favourite beer, I?m inviting you to one next time we meet ;)
Btw, I?ve seen your beer example (yes, I also needed some space too ;) and it only takes 1K, and you achieve this by removing all sections, right?
(What?s your favourite beer, I?m inviting you to one next time we meet ;)
The beer example consists of one section, first 512 bytes contain the MZ stub and PE headers, second 512 bytes contain the single section.
Structure of PE format allows any alignment of file (you specify it in the header), but Win32 PE files must have it equal to 512 bytes, so fasm allows this alignment only (is the not-so-portable excutable format used somewhere else?).
Beer? I prefer Porter ;)
Structure of PE format allows any alignment of file (you specify it in the header), but Win32 PE files must have it equal to 512 bytes, so fasm allows this alignment only (is the not-so-portable excutable format used somewhere else?).
Beer? I prefer Porter ;)
So, then, it would be possible to have one 512-bytes only PE?
I?m not too sure, haven?t tryed if Windows starts a prog with different PE-header.
Porter, nice one, it?s done ;)
(is the not-so-portable excutable format used somewhere else?).
I?m not too sure, haven?t tryed if Windows starts a prog with different PE-header.
Porter, nice one, it?s done ;)
Theoretically yes (by using the header data as a section data), but for example WinNT kernel doesn't want to run executables of size less than 1024 bytes.
Okay, you have guessed my intentions with the header data. But it?s not good if it won?t work in NT.
How about LE and NE, do you plan to implement them in the future?
How about LE and NE, do you plan to implement them in the future?
Well, possibly you could create LE executables with fasm's COFF output and some external linker. The NE is the obsolete 16-bit and it would be hard to implement it with "flat" architecture of fasm.
Thanx again, this last question was just curiosity ;)
rb was really a good idea!
The syntax is short and explicit enough. :alright:.
The syntax is short and explicit enough. :alright:.