I'm not sure I understand the first part of the question. Nasm will produce a number of output formats. "nasm -hf" gives (with [my comments]):
valid output formats for -f are (`*' denotes default):
* bin flat-form binary files (e.g. DOS .COM, .SYS)
[16- or 32-bit, default 16-bit - most useful for dos .com files, perhaps, but you can produce *any* executable format with "-f bin" if you really want to]
aout Linux a.out object files
[32-bit - an "obsolete" format, AFAIK]
aoutb NetBSD/FreeBSD a.out object files
[32-bit - I think this is what (G)as calls "bout"]
coff COFF (i386) object files (e.g. DJGPP for DOS)
[32-bit - this is for a "dos extender" that gives us dos and bios interrupts in 32-bit code - *huge* executables! - someone just posted that there *are* 16-bit extensions to COFF, but Nasm doesn't have 'em - the djgpp build of Nasm is much better than "nasm16" for dos on a 386+ - probably not what you want for your .asm files... unless you do... - link with djgpp's ld]
elf ELF32 (i386) object files (e.g. Linux)
[32- bit - there are "GNU extensions" for 16-bit (and 8-bit ???) relocations - link with Linux's ld]
as86 Linux as86 (bin86 version 0.3) object files
[16-bit - obsolete - link with ld86, I think]
obj MS-DOS 16-bit/32-bit OMF object files
[16- or 32-bit, default 16-bit - the 16-bit form is used for dos .exe files (or libraries) - use Alink ("-oEXE"), or MS's *segmented* linker (v 5.63???), or TD or Val, or ??? - the 32-bit extensions are used by the "BORLAND tools" to make Windows (PE) .exes - use Alink ("-oPE") or TD32 or MS's "incremental" linker (it will complain about converting OMF to COFF, but works), or Valx, or ???]
win32 Microsoft Win32 (i386) object files
[32-bit - this is MS's varient of COFF ("PECOFF") - *not* quite the same as "-f coff"!!! - use with MS's "incremental linker", or polink, or Mingw/Cywin ld, or ???]
rdf Relocatable Dynamic Object File Format v2.0
[??? - ask Yuri - linker, etc in the "rdf" directory (of the Nasm source)]
ieee IEEE-695 (LADsoft variant) object file format
[??? - ask David]
macho NeXTstep/OpenStep/Rhapsody/Darwin/MacOS X object files
[32-bit (AFAIK) - "-f macho" is new and experimental - not available in a "release" yet - get source from CVS if you need it - I understand x86 Macs are shipping to developers... - link with OS-X's linker, I suppose(???) - ask Eric]
Which of these output formats you want, and what linker (if any) to use with it is determined by what kind of executable you wish to end up with. Dos ".com" files are probably simplest.
How the loader sets segment registers "depends", too. A dos .com file is loaded with all segregs set to the one-and-only segment - the first free one found by the loader, I suppose. A dos .exe is loaded with ds and es set to the PSP ("Program Segment Prefix"). This isn't where your data is, so you want to start your program with "mov ax, data"/mov ds, ax"/maybe "mov es, ax"... Of course, cs is set to your code segment, and ss to your stack segment. For Windows .exes, and any other 32-bit format I'm aware of, the OS takes care of segment registers - don't touch 'em! (there are exceptions to this, but not for beginners :)
If that doesn't answer your question, ask a question it *does* answer! :)
Best,
Frank
