Humm... would anybody happen to know how to change the order
in which link.exe spits out the sections? I have a special case where
I *need* .text to be the last section (and I'm merging all the
sections as well). /ORDER: only orders symbol names from COMDATs :/.

Perhaps manually defining the sections instead of using .code and
.data (ie) will help? I have my doubts, as I read in a MSDN article
that the linker has it's own mind as to how it arranges things.

Currently I'm considering the following options, and none of them
is too appealing to me:

nasm + construct whole PE file by hand. Will work, but is messy.

gnu ld from mingw. Should work, but I dunno if it uses ms-coff or
dj-coff input format. Also, it doesn't support the import libraries
from PlatformSDK, so I will have to keep the gnu import libraries
around :/. But the GNU linker script *is* a very flexible thing.

spasm, fasm... ? I don't have any idea whether they will do what
I need, nor if they can handle the syntax I'm going to feed...
I guess I should have a look.
Posted on 2002-01-29 19:30:06 by f0dder
Ok, fasm seems to be able to do what I want, and the syntax is
generally nice. The import stuff is somewhat quirky though, but as
I will be doing very few imports I can live with that.

*however*... it seems that fasm requires the "import" flag on the
section the imports are defined in. This is sort of okay as I keep
everything in one section and the imports first, but it also seems
to cause the peheader.objects.size is set to the entire
section size :/.

I think I will stick to fasm for this, it seems to be the tool that gets
the job done with the less hassle... unless somebody comes up
with some ingenious manual segment declaration in masm ;).
Posted on 2002-01-29 20:26:02 by f0dder

Why not write a toy to do your own section ordering on any standard PE file ? Then you could write it in any language you liked that produced standard PE files.

Posted on 2002-01-29 20:44:34 by hutch--
If I didn't have to flatten all the secitons to a single section, I could
have done that. But since I need section flattening *and* section
ordering, no go :(. Also, writing a toy would be very easy if you only
need to change the *disk* ordering of the sections. It's a lot more
complicated if you want to modify the memory layout as well (you'll
need to deal with relocations and stuff... a bit too much work for
this project).
Posted on 2002-01-29 20:49:14 by f0dder
The MASM manual states that the order of definition of the segments is the order in the file. You can set the order for the linker yourself by using segment names like CODE$aaa, CODE$bbb. The linker docs states that the segment name is just what comes before the $, and everything with the same segment name is combined - if they aren't PRIVATE segments. Sorting occurs based on what comes after the $.
Posted on 2002-01-29 23:27:09 by bitRAKE
I knew about the $-sorting thing... but that will only help me sort
within sections, it will not help in putting eg .data and .idata before
.text .

Also, even if .data can be place before .text just by defining it first
(not too sure about this), this still wont help me with .idata, as it's
created by the linker...
Posted on 2002-01-30 08:36:39 by f0dder
big question: why? :confused:

Posted on 2002-01-30 08:41:44 by bazik
I have my reasons ;). Well, I have a label defined at the end of my
.text section. When this stuff works, I can write a chunk of data
there, align to filealign, and update header.SizeOfImage and the
section table. This is a pretty convenient way to do some stuff.
Posted on 2002-01-30 08:47:45 by f0dder
Posted on 2002-01-30 18:30:48 by cmax
one way to do it would be building the IAT at runtime (well sort off) like yoda in this it can be modified to just have one segment ".text"... but it's a lotb of work if your'e doing something big
Posted on 2002-01-30 20:53:45 by NervGaz
Dynamic IAT? Wont work. You have to have at least one "ordinary"
(ie, implicitly loaded DLL) import from kernel32 or your app wont run
under all win32... and thus you still need a .idata .
Posted on 2002-01-30 20:56:43 by f0dder
wierd... i remember i couldn't get it to compile without atleast one import but i removed the entire import segment afterwards and it ran just fine...
Posted on 2002-01-30 21:01:59 by NervGaz
Well, windows (especially 2000 and later) are very picky about which
PE files it wants to execute :). Various hacks that are possible on
9x aren't possible on win2k.

As for the kernel32 import... what you need is kernel32 mapped in
your process. So importing something from a DLL that ends up
importing kernel32 is all you need... I think the shortest IT can be
made by importing some gdi32 function.
Posted on 2002-01-30 21:08:12 by f0dder
well it makes sense that it wouldn't run if it didn't have an import section since it's a part of the PE structure... and it was on a win98SE i got it to work without import section... i just tested for the hell of it and it didn't work in win2k... i guess your right thenh... just disregard the earlier post.. :)
Posted on 2002-01-30 21:30:31 by NervGaz
NervGaz, Great quick test. Now we know f0dder is right 96.4% of the time...

But NervGaz, if you had an import section will that file still work on win2000 or XP.....Posted on 2002-01-30 21:47:45 by cmax
f0dder why not adding a new section to your executable?
you should be able to reach it from .text without problems
i think...
Posted on 2002-01-31 03:23:21 by mob
I could do that, mob, but it's more code. And I've already got the
single-section stuff working with fasm... works reasonably well.
fasm syntax is pretty okay most of the time, but the imports are a
bit quirky, and the struct handling seems to be pretty limited.

But it works. For some EXEs.

/me goes bughunting.
Posted on 2002-01-31 08:55:23 by f0dder