Re: Bug: C-prog from Win dies in fork; gdb.exe also won't run

[Brian Dessent <brian at dessent dot net>]

Dave Korn wrote:

>   Given that, it's therefore going to have been done as quickly and cheaply
> as possible, so why should we assume they wouldn't they just check the value
> in the PE header at the start of NtSetInformationProcess?

I know it's MS and everything, and if the subject was Outlook or Clippy
or whatnot I'd grant you the mickeymouse-code factor in full force...
But c'mon, what's easier: 
index into a 2 or 3 bit field in a kernel process table structure

or

a) figure out which module of the process is the main one
b) look up its ImageBase
c) compute which page in that processes' VM corresponds to that
ImageBase plus some magic offset (which also implicitly means that all
subsystems must use exactly the same image header format for the entire
lifespan of the operating system, a pretty lousy way to design a kernel)
d) query the memory manager if that page is currently in the working set
e) incurr a page fault if it is not
f) wait for the disk manager to page in that sector from the pagefile,
or from the image on the filesystem if the page has not been modified

... And doing this for every syscall?!?  And that doesn't even begin to
address the most obvious of security issues of having the kernel rely on
userspace structures when enforcing access restrictions.  

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/