Hi Zanuda,
I've never used ilink32... we're talking about the Borland product, right? I've used (very little) Tlink and Tlink32 - both of which use "-f obj" (OMF) format. I assume that ilink32 also wants OMF, but I'm not really sure. If it *does* want COFF, it's probably "ms-coff" (-f win32), and not "djgpp-coff", which is what "-f coff" produces (they're *almost* the same, but not quite).
One issue is that Nasm's "-f obj" format defaults to 16-bit. If there's *anything* in the file (code, data, or just a label) before a 32-bit segment is declared, Nasm will put it into its default 16-bit code segment, causing a 32-bit linker to complain about 16-bit sections. One way around that is to put "bits 32" as the very first thing in the file - before any "%include"s or anything. That has to be "bits32" - "bits32" is seen as just a label.
Another thing linkers care about is the exact names of sections. Especially if you're linking against existing code, "code" and "_CODE" are two different sections, which will - at best - bloat your code unnecessarily. You can find out the existing names with "objdump", or just look at the .obj in a text editor.
If you can't get it working, post the exact error-message from ilink32 - sometimes there's a good "clue" there. You may have to RTFM on ilink32 to see what input format it *does* want. I'm fairly certain that Nasm will produce something it'll eat.
Best,
Frank
