>         When I get the time I am hacking away at a dos emulator.  It
> has come time to seriously think about implementation issues for the
> emulator itself.  One thing that has me worried at the moment (not the
> only thing...;-) is the fact that the DOS land is going to occupy the
> bottom 1Meg of the emulator address space.

that shouldn't be a problem.

> 1) The unix exit code of the process will be overwritten by the DOS
> stuff

in what way?  the exit code of the process is what's passed to exit()...

> 2) I think the first couple of pages of the process are protected so
> that dereferencing a null pointer will produce a SIGSEGV.

they're part of the address space, they're just unmapped by default.
you can mmap things into that space.  (i.e. MAP_ANON)

> My current thinking is that I can spelunk the crt0.c to make a special
> one for the emulator so that the exit code is shifted to above the
> 1Meg+64K magic limit that DOS knows about.

NetBSD's execve() will always want to load your program at its
conception of 'the right place' in VM.  that'll be at CLBYTES,
generally.  what you need is for your program to be at ~1M.

what i'd do, and i can't guarantee that this will work:
	take crt0.c, and modify it so that:
		(1) it maps the appropriate bit of high memory,
		(2) copies your program into it,
		(3) protects the appropriate bit as necessary
			(i.e. read-only for text, rw for data/bss)
		(4) unmaps the original memory.
		(5) remaps va 0 -> wherever as MAP_ANON
		If you do this right, you'll only have to copy
		text+bss; you can just MAP_ANON the data.
	use ld's -T, etc., to get your program loaded to the
		appropriate address, etc.

If you do crt0.c right, you might even be able to use shared libs...


cgd

------------------------------------------------------------------------------