I want to find out if it is possible to build an entire application manually. The reason I want to do that, is to understand everything inside the applications I write, and thus have more conclusiveness about it.
I didn't find any documents about how resources WORK
or what is added to your OBJ file (wich I assume now that is a direcy transcription of the opcodes/values you put on your .asm file) so it can be called and executable file.
Any ideas?
I didn't find any documents about how resources WORK
or what is added to your OBJ file (wich I assume now that is a direcy transcription of the opcodes/values you put on your .asm file) so it can be called and executable file.
Any ideas?
sure it's possible... although to learn how a pe works i don't think building it manually is the best way to go, but suit yourself, to learn more about the coff obj formats, pe files, and resource files, goto wotsit.org
oOoOoOoOooo!!! another one who wants to try to be a real man!!! well first off I have to tell you it's not easy.
- have a look at the PE structure... study them
- look at the opcodes, mod r/m and sib bytes (Intel Manuals Volume 2). Study how opcodes are "constructed"
as for resources, I haven't delved into this yet. :grin:
- have a look at the PE structure... study them
- look at the opcodes, mod r/m and sib bytes (Intel Manuals Volume 2). Study how opcodes are "constructed"
as for resources, I haven't delved into this yet. :grin:
www.wotsit.org, search for "Portable Executable format description". The pe.txt file inside the zip shows how to write a PE exe manually using a hex editor.
Thomas
Thomas
Ok, I think I have really a LOTTA to read now (even more than the piles Im on right now :-D ) .... Ill hang!
But I dont want to be a perfect nerd about it, I want to use that knowledge, in "some" practical manner. For example, it annoys me to open a executable file (like my fisrt asm programs) and see that they are mostly NULL bytes!!!! Come on!! Dowsn't anyone cares about that like me?? I want to remove those, and also would be kinda cool to mess up with our .exe files directly, wouldn't it?? ;)
...and resource files, goto wotsit.org
:-o I was just browsing through this very site these days for file formats... :) ... good to know it will be more usefull than I thought at fisrt.
oOoOoOoOooo!!! another one who wants to try to be a real man!!! well first off I have to tell you it's not easy.
:-[ ... ok, ok... I think it is good then... :) ... unfortunately will take lotta time, huh?
as for resources, I haven't delved into this yet
Thats the sad part when you want to do something really wacky and almost unusefull ( for "normal people" only? ; ) ... there is NOT many information about it... on the other side, whoever does it, will be kinda legendary...
------
See yaz!
But I dont want to be a perfect nerd about it, I want to use that knowledge, in "some" practical manner. For example, it annoys me to open a executable file (like my fisrt asm programs) and see that they are mostly NULL bytes!!!! Come on!! Dowsn't anyone cares about that like me?? I want to remove those, and also would be kinda cool to mess up with our .exe files directly, wouldn't it?? ;)
...and resource files, goto wotsit.org
:-o I was just browsing through this very site these days for file formats... :) ... good to know it will be more usefull than I thought at fisrt.
oOoOoOoOooo!!! another one who wants to try to be a real man!!! well first off I have to tell you it's not easy.
:-[ ... ok, ok... I think it is good then... :) ... unfortunately will take lotta time, huh?
as for resources, I haven't delved into this yet
Thats the sad part when you want to do something really wacky and almost unusefull ( for "normal people" only? ; ) ... there is NOT many information about it... on the other side, whoever does it, will be kinda legendary...
------
See yaz!
Ok, I think I have really a LOTTA to read now (even more than the piles Im on right now :-D ) .... Ill hang!
But I dont want to be a perfect nerd about it, I want to use that knowledge, in "some" practical manner. For example, it annoys me to open a executable file (like my fisrt asm programs) and see that they are mostly NULL bytes!!!! Come on!! Dowsn't anyone cares about that like me?? I want to remove those, and also would be kinda cool to mess up with our .exe files directly, wouldn't it?? ;)
Even if you write your executables using a Hex editor, you will still have these null bytes, al least if you want to make standard and fully win32 compliant PE files...
This is padding, and if you remove some bytes of it, the exe file is not garanteed to work...
If you want to save you time, use a very low-level assembler like FASM or NASM that allows much control over the outputted binary files... the result will be nearly the same, to not say the same...
use a very low-level assembler like FASM or NASM that allows much control over the outputted binary files... the result will be nearly the same, to not say the same...
:( really? can u tell what are there so many useless bytes then? I think they must be "reserved" for something (that will almost never be used :-p ), but maybe something else?
... anyway, I should have expected that... there is not a single thing thing that M $ does that we can fully enjoy... :(
But I dont want to be a perfect nerd about it, I want to use that knowledge, in "some" practical manner. For example, it annoys me to open a executable file (like my fisrt asm programs) and see that they are mostly NULL bytes!!!! Come on!! Dowsn't anyone cares about that like me??
I would prefer the null bytes, since they ensure the sections are aligned and can be loaded faster into memory... It might save a few bytes if you remove them but it's actually slower (although you won't really notice it). Optimizing for speed and optimizing for size don't always go hand in hand well together.
Thomas
Also, Iczelion wrote a series of tuts on the PE file format. You may want to check those out as well.
in reply to Thomas:
I really prefer the smallest file possible. I dont care about the extra secs (mili? nano maybe?) it will take to load. In fact, I just had the following idea:
how many executable files you think you have on a normal (ultra bloated :-p ) M$ based machine? Have you ever tried to search *.exe in your hard drive.... better, you can only try the %system% dir. :)
I can say just by my memory, it is more than 50 ( i searched on my work's winNT and found 240 ) ... well, pals, I think we could save some MEGS on our hard disk getting rid of those null bytes, dont you think? Dont forget to include the null bytes we would find in AAALLL the DLLs and VXD, etc.... ;)
------------------
I think I have a point here! :-D
I really prefer the smallest file possible. I dont care about the extra secs (mili? nano maybe?) it will take to load. In fact, I just had the following idea:
how many executable files you think you have on a normal (ultra bloated :-p ) M$ based machine? Have you ever tried to search *.exe in your hard drive.... better, you can only try the %system% dir. :)
I can say just by my memory, it is more than 50 ( i searched on my work's winNT and found 240 ) ... well, pals, I think we could save some MEGS on our hard disk getting rid of those null bytes, dont you think? Dont forget to include the null bytes we would find in AAALLL the DLLs and VXD, etc.... ;)
------------------
I think I have a point here! :-D
wicr0s0ft, search this board or M$.com for "PE File Format" - good to hear straight from the source. These are good things to know - really gives you a deeper understanding of what can be in an EXE and what features the PE format offers. These features are not all so easily exposed by the linker.
Even if you did strip all the padding, it will still take up at least 4KB on your HD.
That's called Slack Space and is due to sectors. FAT32 supports a smallest of a 4KB sector. The larger the HD, the larger the sector.
NTFS has the same problem. I've seen a 40GB HD with 7GB of unuseable space.
The only solutions comprise either partitioning the HD, or using a different File System.
That's called Slack Space and is due to sectors. FAT32 supports a smallest of a 4KB sector. The larger the HD, the larger the sector.
NTFS has the same problem. I've seen a 40GB HD with 7GB of unuseable space.
The only solutions comprise either partitioning the HD, or using a different File System.
NTFS has the same problem. I've seen a 40GB HD with 7GB of unuseable space.
I wouldn't use compression just like I wouldn't use NTFS. To hard to recover data. FAT32 w/ Many partitions works for me.
As a side note, Win2K is NOT capable of formating large FAT32 Partitions (ie > 2GB).
As a side note, Win2K is NOT capable of formating large FAT32 Partitions (ie > 2GB).
I guess on NTFS system, disk access are much more faster than on FAT32s.
Can anyone confirm this?
Can anyone confirm this?
The only advantage to NTFS I've heard of is that it can save huge files (= larger than 4 gigabyte)
wicr0s0ft
be sure to read this one
"$Id: pe.txt,v 1.9 1999/03/20 23:55:09 LUEVELSMEYER Exp $"
search for <LUEVELSMEYER + pe file format> on google.com, i'm sure u'll find it. it was how i learnt about the PE file format and it also covers how both the assembler and linker works, the .resources are also covered, but it's a pain in the 4ss to understand it in a real exe :\
if you're unhappy with the 0-arrays :) try using UPX to compress the exe, it's a good packer, and the execution isn't really afected since by diminuishing the .exe the hard drive reads less bytes and the CPU does a fast unpacking in memory
hope i helped
cya
be sure to read this one
"$Id: pe.txt,v 1.9 1999/03/20 23:55:09 LUEVELSMEYER Exp $"
search for <LUEVELSMEYER + pe file format> on google.com, i'm sure u'll find it. it was how i learnt about the PE file format and it also covers how both the assembler and linker works, the .resources are also covered, but it's a pain in the 4ss to understand it in a real exe :\
if you're unhappy with the 0-arrays :) try using UPX to compress the exe, it's a good packer, and the execution isn't really afected since by diminuishing the .exe the hard drive reads less bytes and the CPU does a fast unpacking in memory
hope i helped
cya
I have attached "$Id: pe.txt,v 1.9 1999/03/20 23:55:09 LUEVELSMEYER Exp $" :grin:
Axial,
The info I have seen says no, NTFS has additional features but it is no faster than FAT32. I run win2k over a win98 installation with dual boot on a test machine and win2k reads and writes to FAT32 OK so if it cannot format bigger than 2 gig in FAT32, use the DOS format on a floppy.
This does sound unusual to me as FAT16 had this limit where FAT32 did not.
Regards,
hutch@movsd.com
The info I have seen says no, NTFS has additional features but it is no faster than FAT32. I run win2k over a win98 installation with dual boot on a test machine and win2k reads and writes to FAT32 OK so if it cannot format bigger than 2 gig in FAT32, use the DOS format on a floppy.
This does sound unusual to me as FAT16 had this limit where FAT32 did not.
Regards,
hutch@movsd.com
Wasn't FAT32 more or less made for making bigger partitions avalible? Well, after googling i found the sites mentioned below (links within "->","<-" ). (I didn't know M$ thay had such info on thir sites.)
On the M$ Support site, they say maximum size for a FAT16 disk is 2 GB. Here is the -> page <-
And for the FAT32,
the page for above is -> here <-.
I don't notice any speed difference between NTFS (compressed) and FAT32, haven't done any bechmarking thou.
On the M$ Support site, they say maximum size for a FAT16 disk is 2 GB. Here is the -> page <-
And for the FAT32,
Quoted from M$'s support site:
* The maximum possible number of clusters on a volume using the FAT32 file system is 268,435,445. With a maximum of 32 KB per cluster with space for the file allocation table (FAT), this equates to a maximum disk size of approximately 8 terabytes (TB).
...
* You cannot format a volume larger than 32 GB in size using the FAT32 file system in Windows 2000. The Windows 2000 FastFAT driver can mount and support volumes larger than 32 GB that use the FAT32 file system (subject to the other limits), but you cannot create one using the Format tool. This behavior is by design. If you need to create a volume larger than 32 GB, use the NTFS file system instead.
* The maximum possible number of clusters on a volume using the FAT32 file system is 268,435,445. With a maximum of 32 KB per cluster with space for the file allocation table (FAT), this equates to a maximum disk size of approximately 8 terabytes (TB).
...
* You cannot format a volume larger than 32 GB in size using the FAT32 file system in Windows 2000. The Windows 2000 FastFAT driver can mount and support volumes larger than 32 GB that use the FAT32 file system (subject to the other limits), but you cannot create one using the Format tool. This behavior is by design. If you need to create a volume larger than 32 GB, use the NTFS file system instead.
the page for above is -> here <-.
I don't notice any speed difference between NTFS (compressed) and FAT32, haven't done any bechmarking thou.