Re: 2.7 thoughts: common well-architected object model

[Jamie Lokier <jamie@shareable.org>]

asdfd esadd wrote:
> There is a connex, fork() might be a bad example,
> 
> it's simple - yes but 20 years have passed as Solaris
> is finding:
> 
> pid_t fork(void); vs. 
> 
> the next step in the evolution CreateProcess
>
> [extraordinarily long-winded way of saying the same thing as
>  if ((pid = fork()) == 0) { set_things(); go(); } ]

Dear asdfd,

How can you possibly think the CreateProcess monstrosity superior to
fork in any way?  You seem to have picked the canonical example of
just what is awful about the Win32 AI and why it's so much work to use.

I cannot think of a single example where CreateProcess is simpler to
use - and it's worse than that: it comes with a bunch of assumptions
and limitations, exactly the kind of thing that presumably you expect
"a component model" to _not_ have.

What do you do when you want to create a process with a property that
_isn't_ listed in the arguments to CreateProcess?  Yes: you have to
set those in the child process, just like with fork().

So what's the point in having some of the properties listed in
CreateProcess?  Answer: none.  Not from an API cleanliness point of
view anyway.

> System.Object
>    System.MarshalByRefObject
>       System.ComponentModel.Component
>          System.Diagnostics.Process
> [C#]
> public class Process : Component
> [C++]
> public __gc class Process : public Component

This begins to make more sense.  You do understand that unix has this
class too, but it's called pid_t, not Process?

> * unified well architected core component model
> which is extensible from OS services to application
> objects

Yeah, but CreateProcess _isn't_ well architected.  It's among the
worst of excreta in Win32.

> * the object model should be defined from the kernel
> layer for process/events/devices etc. up and not
> started at the application layer

Unfortunately you just state this, without giving any reasons for it.

If this were implemented in userspace (i.e. the Mono project),
can you give a single reason why it needs to be extended into the kernel?

-- Jamie