Re: [line-devel] NTCreatePort failed with a c0000022

[Michael V. <mi...@bl...>]

On Fri, 20 Apr 2001, Michael Stout wrote:

>
> >NTCreatePort failed with a c0000022
>
> c0000022 turns out to be a permission denied message
> I fix this by using winobj from www.sysinternals.com
> and changing the permssions of \\Windows so that I
> can create stuff inside it.

Ah...ok.  I'll try that on Monday (I don't have a NT/2K system at home)


> I've been thinking about how to reflect the int 80 back to the calling
> process, and I just cant think of a clean way to do it.

From the int 0x80 handler, can you do any of the following:

- access the userland address space of the process that invoked it?
- SuspendThread() the thread that invoked it?

Do you know what the stack looks like after the int 0x80 handler is
called?  Shouldn't it be possible just to alter the return address that
the IRETD loads once the handler is finished?


> The native app Creates a very empty process.  If the elf_loader code
> can be merged into the native app and it maps the elf binary into the
> process using MapViewOfFileEx or using the undocumented Section apis,
> then we really have a process that looks like what I imagine a
> linux process to look like (no cygwin.dlls mapped into it's address space)

I think I see where you are going with this.  Are you are suggesting that
the syscall handler be removed from the actual Linux process?

I actually tried that way back in the days of LINE 0.1 and found a number
of problems with it.  But I will admit that it very much appeals
to me to keep the 'kernel' away from the application.

One big problem was the performance hit of doing a ReadProcessMemory() to
retrieve any data being passed into the kernel, then doing
WriteProcessMemory() to put data back to the app afterwards.

Also whenever you do anything that creates a handle (opening a file for
example), the handle is created in the context of kernel' process and not
in the context of the app process.  This means that you either need to
migrate the handle to the app somehow, or maintain a list of all the
currently open handles for each app in the kernel process.  This isn't an
issue when the 'kernel' is in the same process as the app.

Finally, User-mode-linux runs the kernel in the application process space.
I'm not saying that LINE should do it that way just because UML does it,
but eventually I'd really like to see UML ported to Windows.  I sort of
see LINE as a prototype for UML/Win32, a way to figure out all the
possible stumbling blocks.  So it would be nice to try to keep diverging
to much from how UML works.

Although I'm not totally against the idea, I could be convinced.  But
it'll definitly involve a lot of work!


> Unfortunately I'm really a linux newbie, so I really have an uphill battle
> ahead.

Well NT device drivers is definitely uncharted territory for me as well :)


Mike