Comments (3)

  1. Helge Kruse says:

    The article states that not supported functions, like MapCallerToProcess, are still resolved with coredll.dll.

    What sense does it make, to load applications, drivers, …, that will fail later when calling this functions? What compatibility is maintained?


  2. Doug says:

    The MapCallerPtr and MapPtrToProcess APIs still exist for backward compatability.  It works out that for a kernel mode driver, the NOP functionality of these functions in 6 is the right thing to do to make the driver work.  If the APIs were removed, all the drivers would have some editing needed just to compile.

    I understand that developers should always look at their code when porting, but its nice to have it compile and mostly work while working on other incompatiblities.

  3. Tony says:

    Hi Mike,

           I have some confusions about the address mapping between physical address and virtual address in Windows CE5.0.

            If I want to access memory in my applications,what should I do?

           In my opinion I can use VirtualAlloc( ) and VirtualCopy( ) to realize, and I can also use MmMapIospace( ). Am I right? My problem is:

           1.When should I use the PAGE_PHYSICAL with  VirtualCopy( )? When I use arbitrary physical address or physical address above 0x1FFFFFFF?

           2.I’m confused by the VirtualCopy.Is the "source address" parameter can be both virtual space of kermel and physical address?

           3.If I use VirtualAlloc() and VirtualCopy() without the page_physical parameter, I need to define static map relationship in OEMAddressTable and reserve difined virtual address in config.bib first?

            Thank you for help.