Re: Odd call stack

Yes, that is what I mean. You've already "confirmed" it yourself by
observing the callstack.

Whatever all the problems are, they solved it in WinCE version 1.0.

I believe the reason they chose this mechanism is because they thought it
was a faster mechanism than marshaling parameters, setting events, waiting -
and full context switches. This is sort of a "light" context switch with no
marshaling (just take parameters off the same stack, map pointers.

You have to understand the memory architecture to know how they can map
pointers - essentially allow one process to dereference a pointer coming
from another process's address space, but that is way beyond the scope of
the topic at hand. Incidentally, if you've ever wondered why WinCE is
limited to 32 processes with a 32MB address space, this is it - PSLs /
cross-process calling.

It's "publicly" documented in that MS has made the source code available.
See \WINCEXXX\PRIVATE\WINCEOS\COREOS\NK\KERNEL\objdisp.c. Search for
ObjectCall or PSL. You can also search for CreateAPISet and RegisterAPISet
to see how an API server process (a PSL - Process Server Library) registers
its functions with the kernel.

--
Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com


"Thomas" <totohero@xxxxxxxxx> wrote in message
news:1117529139.069710.154250@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Do you mean that function call across multiple processes is possible?
> If it is, there are too many problems which should be addressed first,
> regarding how to define and detect that kind of function call and who
> will save and restore the context of 'callee process', etc. Above all,
> why don't use event handling instead of 'inter-process function
> calling'? Is this feature documented publicly by MS?
>
> Michael J. Salamone wrote:
>> Perfectly normal in WinCE. The OS migrates threads from one process
>> context
>> to another when calling system services. The migration is a light
>> context
>> switch of sorts. Same thread, same stack, same registers - just maps in
>> the
>> address space of the server process and a little magic.
>>
>> --
>> Michael Salamone [eMVP]
>> Entrek Software, Inc.
>> www.entrek.com
>>
>>
>> "Thomas" <totohero@xxxxxxxxx> wrote in message
>> news:ac9276f6.0505011830.28f41fc2@xxxxxxxxxxxxxxxxxxxxx
>> >I was debugging my own audio device driver and get follwoing call
>> > stack log after stopped at some breakpoint inside the driver code.
>> >
>> > You can see NK and DEVICE in the middle of the call stack. Does that
>> > mean the functions of an EXE file can be called by another
>> > executables? It's impossible AFAIK. Some one please explain this for
>> > me?
>> >
>> >
>> >
>> > Call Stack: cprog.exe: 0x59DEC862 17:15:27 05/01/2005 +9+
>> > WAVEDEV!HandleWaveMessage(MMDRV_MESSAGE_PARAMS * 0x2403e768,
>> > unsigned long * 0x2403e760) line 559
>> > WAVEDEV!WAV_IOControl(unsigned long 0x0000003a, unsigned long
>> > 0x00000000, unsigned char * 0x00000057, unsigned long 0x00410057,
>> > unsigned char * 0x005f0056, unsigned long 0x004f0049, unsigned long *
>> > 0x006f0043) line 936 + 12 bytes
>> > WOWXT_ARM_WCE_PPC_DRIVER!011e3624()
>> > WOWXT_ARM_WCE_PPC_DRIVER!011e2a80()
>> > DEVICE!FS_DevDeviceIoControl(fsopendev_t * 0x00000000, unsigned
>> > long 0x000005c8, void * 0x00000001, unsigned long 0x0000040b, void *
>> > 0x00000004, unsigned long 0x2403e764, unsigned long * 0x00045d10,
>> > _OVERLAPPED * 0x00000000) line 1252 + 44 bytes
>> > NK!SC_DeviceIoControl(void * 0x00000000, unsigned long 0x000005c8,
>> > void * 0x00000001, unsigned long 0x0000040b, void * 0x00000000,
>> > unsigned long 0x2403e814, unsigned long * 0x2403e844, _OVERLAPPED *
>> > 0x00000000) line 3658 + 64 bytes
>> > COREDLL!xxx_DeviceIoControl(void * 0x00000000, unsigned long
>> > 0x000005c8, void * 0x00000001, unsigned long 0x0000040b, void *
>> > 0x2403e760, unsigned long 0x00000004, unsigned long * 0x2403e764,
>> > _OVERLAPPED * 0x00000000) line 27 + 92 bytes
>> > AUDEVMAN!CAudioDevice::wavMessage(CAudioDevice * const 0x00000000,
>> > unsigned int 0x000005c8, unsigned long 0x00000001, unsigned long
>> > 0x0000040b, unsigned long 0x00000000) line 846 + 56 bytes
>> > End Call Stack: cprog.exe: 0x59DEC862 17:15:27 05/01/2005 +9+
>


.

Relevant Pages

  • Re: Miltu-core CPUs, threads vs AST driven approaches
    ... The way to do that is to run the several 'worker' threads at normal (not AST) level, and use the AST routines only to process I/O completion and as part of that completion move the continuation context for the relevant activity onto a 'to do' queue, which each thread visits whenever it has no processing to do. ... This preserves VMS's guarantee that no more than one AST will be active at a time, and the extremely brief processing required at AST level (compared with the processing required in each thread between interruptions) ensures that this will not impede progress even if many processors are working in parallel in the single process. ... The main gotcha here is that *all* the context for each operation must be held in that queued context structure, rather than conveniently on a thread's stack - since the thread's stack gets unwound before each such interruption. ...
    (comp.os.vms)
  • Re: interrupt routine and application pages
    ... application stack in the interrupt context. ... are still in the context of interrupted thread. ... your code runs at raised IRQL, Memory Manager just had no chance to ...
    (microsoft.public.development.device.drivers)
  • Re: Network Stack Locking
    ... :>:of continuations during IPC to avoid a full context switch. ... Even a minimal stack is ... :> continuation mechanism increases as system load increases rather ...
    (freebsd-arch)
  • Re: Odd call stack
    ... will save and restore the context of 'callee process', ... > Michael Salamone ... >>I was debugging my own audio device driver and get follwoing call ... >> stack log after stopped at some breakpoint inside the driver code. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Whats the big deal with cross-platform?
    ... tell by invoking some core function, and tracing the call stack all the ... the next Windows version, or in WinCE, or... ...
    (borland.public.delphi.non-technical)