Finding the video pointer (i.e. debugging code)

[Digby]

[R0B]

[R0B]

[Digby]

You are calling GXOpenDisplay in all your tests, right?  I ask this because GAPI will need to convert the physical display memory address to a virtual address that can be used by your process.  This is normally done with a call to VirtualCopy.  It shouldn't be doing this every frame though (i.e. in GXBeginDraw) because that would be horribly inefficient (so would displaying a splash dialog, but that doesn't stop some).<br><br><br>Look at step #2 in KB Article for what I'm talking about.  Ignore the part about config.bib, your display memory buffer is already allocated by the OS at boot time.<br><br>Again, this isn't something that would need to happen every time the app calls GXBeginDraw.  This could happen in DllMain in response to DLL_PROCESS_ATTACH for gx.dll, or I suppose when the app called GXOpenDisplay.<br><br>

[R0B]

Actually, GXOpenDisply does nothing in the HPC version.  Also, you only need to call GXBeginDraw once.  But, you may be on to something.  I think what I need to do is use virtual copy like you said to change it from a physical address to a virtual one.  I'll look into that right now and then see what happens.  Just remember, GAPI for the HPC is not nearly as good as the real thing.  The following functions only return 0 (and nothing else).<br><br>GXOpenDisplay<br>GXOpenInput<br>GXSuspend<br>DXResume<br>GXCloseDisplay<br>GXEndDraw<br>GX (you know, the one that tells you if the video hardware is "normal."  I think that it is quite funny that it returns 0 when it was designed for this hardware.)<br><br>And a couple others that I cannot think of.  I believe that the only functions that actually do something are these.<br><br>GXBeginDraw<br>GXGetDisplayProperties (or is it just GXDisplayProperties)<br>and<br>GXGetDefaultKeys (see question above)<br><br>The one thing that I really feel it is lacking is the ability to get unfiltered key messages.  If it had that, I could define the hotkeys at the to as F keys (f1..fx)

[Digby]

If the function you're referring to is GXIsDisplayDRAMBuffer(), it probably should return 0, meaning GXBeginDraw will return a pointer to actual display memory instead of a pointer to an intermediate buffer in DRAM.<br><br>Let us know how you make out.<br><br>

[R0B]

I looked for a refrence for VirtualCopy in all of the include files, and I couldn't find anything.  What about virtualAlloc.  Do I actually have to allocate the memory at this address myself, or what?  <br><br>The thing about GXIsDisplayDRAMBuffer() is that the code for it is to simply return 0.  That's it.<br><br>int (I think) GXIsDisplayDRAMBuffer(){<br>return 0;<br>}<br><br>Keep in mind, that Larry's GAPI is not MS GAPI.  I wish it was, but it just isn't.

[Digby]

VirtualCopy is declared in pkfuncs.h which is included with Platform Builder.  You might get away with asking Dan East for the header file and/or docs as he has recently obtained the CE source code.<br><br>The physical address of the display memory will need to be mapped to a virtual address in order for your process to dereference it properly.  You'll need to use VirtualAlloc to reserve the address space (don't allocate - just reserve), and then VirtualCopy to bind the physical memory to the virtual memory.  I thought there was an example of this in the KB article I provided.  Did you look at it?<br><br><br>You wrote:<br>GX (you know, the one that tells you if the video hardware is "normal."  I think that it is quite funny that it returns 0 when it was designed for this hardware.)<br><br>GXIsDisplayDRAMBuffer is implemented correctly.  What's so funny about it?  Larry obviously knows he's not using an intermediate DRAM buffer, so the function is returning 0, indicating such.  Did I miss something?<br><br>

[Dan East]

VirtualCopy is defined as DoVirtualCopy in kernel.h:<br>[fixed]<br>#undef VirtualCopy<br>#define VirtualCopy DoVirtualCopy<br>[/fixed]<br>The definition of DoVirtualCopy is found in KWIN32.H and is:<br>[fixed]<br>BOOL DoVirtualCopy(LPVOID lpvDest, LPVOID lpvSrc, DWORD cbSize, DWORD fdwProtect);[/fixed]<br><br>An example usage out of the KMISC.C file:<br>[fixed]LPBYTE lpNLSView = VirtualAlloc(0, cbSize, MEM_RESERVE, PAGE_NOACCESS);<br>VirtualCopy(lpNLSView, pvPhysical, cbSize, PAGE_READONLY);<br>[/fixed]<br>Where pvPhysical is a pointer to the physical memory you want a copy of.<br><br>Also, you may want to see MS knowledge base article Q213359. It refers to problems when using VirtualCopy to copy physical memory. It says it applies to "Microsoft Windows CE for the Handheld PC", so I don't know if it is pertinent CE versions greater than 2.0 or not.<br>The body of the DoVirtualCopy function is 180 lines long, so I'm not going to include it here.<br><br>Dan East

[R0B]

So, what your saying is that I need to download the windows ce source code.  Or could someone email me the related files?

[Digby]

It's my guess that from what Dan posted, DoVirtualCopy is exported by coredll.dll.  All you need is the function prototype to keep the compiler happy (Dan has posted that).<br><br>

[R0B]

Thanks a lot for all of your help so far guys.  I'll work on this somemore tonight, and tell you what happens probably tomorrow after noon.  Thanks again.<br><br>Oh, one quick question, should I use lpNLSView, or pScreenBuf after I virtualalloc the me, assuming I allocate it to lpNLSView.  I am pretty sure I need to use lpNLSView, but I just wanted to check.  I would try it myself, but my computer with eVc on it, is not with me right now.

[Moose or Chuck]

yup