Re: Odd call stack

Right. A thread on Windows CE can "migrate" into another
process. Basically the thread structure and stack stay the same, but the
current process (slot 0) is mapped to a new process and execution continues.
This is a unique design in Windows CE.

Regarding your specific questions:

>> Do you mean that function call across
>> multiple processes is possible?

Yes. This is how many system API calls are implemented.

>> 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.

The Windows CE Kernel already addressed all of these.

>> Above all, why don't use event handling instead
>> of 'inter-process function calling'?

Thread migration is actually faster because it doesn't require thread switch
or data copying/marshalling.

>> Is this feature documented publicly by MS?

This has been the way Windows CE makes system API calls since version 1.0.
There's a presentation about the Windows CE kernel available on MSDN that
touches this subject a little bit. You can find it by visitting the
following website and find ?Windows CE Operating System and Memory
Architecture? on that page.

http://msdn.microsoft.com/embedded/getstart/basics/tutorialsce/default.aspx


The CE kernel is unique in this regard and much of it is not obvious and is
not documented extensively because it is mostly internal implementation
details (which may change).

John Eldridge
Microsoft Corporation
KITL First. Ask questions later!
http://blogs.msdn.com/kitlfirst

Disclaimer: This posting is provided "as is" with no warranties, and
confers no rights.

~~~~~~~~~~~~~~~

"Michael J. Salamone" <mikesa#at#entrek#dot#com> wrote in message
news:edYjUwdZFHA.2496@xxxxxxxxxxxxxxxxxxxxxxx
> 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: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but not
    ... Short of carnal knowledge of what's in the target structure or the particular meaning of the context value -- something that's certainly an inviting approach, but generally also not a good idea to know about for reasons of upward-compatibility -- there's often no way to verify these sorts of structures. ... If there's a function available to validate, then I should be calling *that*. ... When I can establish the correctness of all possible inputs, then I will have reached spiritual perfection. ... I know of no way to provide what you want within the context of X Windows, short of rebuilding the whole X Windows platform. ...
    (comp.os.vms)
  • Re: listing to a file
    ... batch file but I cannot remember where I found it. ... To create the entry in the context menu it's necessary to first create a ... Save the file in your WINDOWS folder as shown in, ... File Listing will probably be most useful, but you can name yours something ...
    (microsoft.public.windowsxp.general)
  • Win Explorer Context Menu Queue it up, Add to Playlist NOT WORK
    ... During all this year by now I noticed one big problem with Windows ... Windows Explorer Right click Context menu on multimedia files (e.g. .mp3, ... In the first, I was thinking that maybe some WMP Plug-in, or Visualizations ... start to install more Software on it. ...
    (microsoft.public.windowsmedia.player)
  • Re: Accessing Physical Memory & Other Processs Address Space
    ... I believe Windows has an equivalent mechanism though I haven't done ... any Windows kernel programming in a very long time. ... context in user mode (and a kernel stack representing its context there). ...
    (comp.lang.asm.x86)
  • Re: Right Click Crashes Windows Explorer
    ... Wondering why troubleshooting using ShellExView did not isolate the ... Apparently by doing this I insured that PowerDesk's Context Menus load ... What about other shell extensions (not only Context Menu handlers). ... see if the Event Viewer provides any clue on the Windows ...
    (microsoft.public.windows.vista.installation_setup)