From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: Physical Memory Addresses Date: Sun, 22 Sep 1996 11:45:06 CDT Organization: Rice University, Houston, Texas Lines: 29 Message-ID: <32456d12.sandmann@clio.rice.edu> References: <9609180832 DOT AA26846 AT leopard DOT proteon DOT com> Reply-To: sandmann AT clio DOT rice DOT edu NNTP-Posting-Host: clio.rice.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp > BTW, if anyone can tell me how to read the CPU's CR3 register when you > are not a protection level 0, I would love you here from you! I'm > pretty sure it is impossible without hacking the DPMI server to give > you the value through a new (non-DPMI) interface call. You are right that it's not possible in the general sense. There is a back door approach to get this informtion under CWSDPMI, so you do this under the ring 3 version. In general: sgdt can get you the linear base of the gdt table str can get you the current task register Looking directly in the gdt table you can compute the base address of the current task structure Offset 1c into that structure will get you your CR3 value. If you do this carefully with some checking, you can detect non-CWSDPMI hosts and avoid doing bad things. Using this technique you then have direct access to the page tables, with all the advantages (and hazards). Using the nearptr or farptr routines, you can then read or write the page tables directly, as long as you make the "operating system" bits consistent with what CWSDPMI expects (see it's documentation in paging.h). Using this technique, you can then read page tables to set up the DMA buffers in the 1Mb to 16Mb range (you may need to modify the tables since anything over 4K may not be contigous - careful touching of pages in order should page them in contigous). You can also see how much of the stack you have used, and lots of other fun things if you are handy with page tables.