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?
Posted on 2002-09-20 14:02:47 by wicr0s0ft
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
Posted on 2002-09-20 14:40:52 by Asm_Freak
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:
Posted on 2002-09-20 14:41:57 by stryker
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
Posted on 2002-09-20 15:07:37 by 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!
Posted on 2002-09-20 15:12:38 by wicr0s0ft

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...
Posted on 2002-09-20 15:28:14 by JCP

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... :(
Posted on 2002-09-20 16:57:05 by wicr0s0ft

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
Posted on 2002-09-20 17:05:46 by Thomas
Also, Iczelion wrote a series of tuts on the PE file format. You may want to check those out as well.
Posted on 2002-09-20 17:39:42 by Will
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
Posted on 2002-09-20 18:29:32 by wicr0s0ft
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.
Posted on 2002-09-20 18:58:05 by bitRAKE
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.
Posted on 2002-09-20 22:35:16 by eet_1024

NTFS has the same problem. I've seen a 40GB HD with 7GB of unuseable space.
Compression
Posted on 2002-09-20 22:44:58 by bitRAKE
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).
Posted on 2002-09-20 22:54:59 by eet_1024
I guess on NTFS system, disk access are much more faster than on FAT32s.
Can anyone confirm this?
Posted on 2002-09-21 08:00:45 by Axial
The only advantage to NTFS I've heard of is that it can save huge files (= larger than 4 gigabyte)
Posted on 2002-09-21 08:58:40 by Qweerdy
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
Posted on 2002-09-21 16:16:56 by kr0n0
I have attached "$Id: pe.txt,v 1.9 1999/03/20 23:55:09 LUEVELSMEYER Exp $" :grin:
Posted on 2002-09-22 00:47:14 by roticv
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
Posted on 2002-09-22 02:27:13 by hutch--
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,
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 page for above is -> here <-.

I don't notice any speed difference between NTFS (compressed) and FAT32, haven't done any bechmarking thou.
Posted on 2002-09-22 03:21:20 by scientica