Date: Tue, 12 Jan 1999 11:09:40 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: russell DOT thamm AT dsto DOT defence DOT gov DOT au cc: djgpp AT delorie DOT com Subject: Re: Accessing Reflective Memory using Pointers In-Reply-To: <77efr1$ti8$1@nnrp1.dejanews.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com On Tue, 12 Jan 1999 russell DOT thamm AT dsto DOT defence DOT gov DOT au wrote: > I am trying to use reflective memory from DJGPP. Please explain what ``reflective memory'' is and what do you want to use it for. > I have no problems > accessing the reflective using _farpeek/_farpoke. However, the > main attraction of using reflective memory is that it appears to > be normal memory. There's nothing non-normal in using _farptr functions to access memory. _farptr functions don't make memory not normal. > Reflective memory access should be transparent > to the program. You can always design a C++ class that conceals the _farptr access with overloaded operators. > Therefore, I wish to access this memory using pointers eg rfm->field1. Or, you can use near pointers, although that makes your program less protected and less portable (as some platforms supported by DJGPP don't allow use of near pointers). > The FAQ says that this can't be done (under DJGPP 2) but offers no > explanation as to why. Excuse me? Most of chapter 18 is devoted to explaining how to access memory not normally mapped into your DS segment. Section 18.4 explains _farptr techniques, and section 18.6 describes the nearptr facility. > I am running under CWSDPMI with virtual memory disabled. It occurred to > me that I should be able to create a pointer that points to the start > of the reflective memory by finding the base address of the segment > whose selector is in the DS register and subtracting it from the > physical address of the Reflective Memory. You have just reinvented the nearptr method. See section 18.6 of the FAQ. > Firstly, the base address is 0x1000000 which is incomprehensible to me. > I am assuming that a linear address is the same as the physical address > because virtual memory is disabled. Disabling virtual memory doesn't disable memory mapping. In other words, when virtual memory is disabled, logical addresses still differ from physical ones, since the CPU's memory-mapping unit is still active. > Secondly, the limit for this segment is too small. This limit appears > to increase as memory is allocated but does not appear to decrease as > memory is freed. This is correct. DJGPP's memory allocation doesn't ever return memory to the memory manager. This is also explained in the FAQ (section 15.2). > Can I modify the limit to include the entire address space? That's what the library function __djgpp_nearptr_enable does. See section 18.6 of the FAQ. Of course, this means that you disable some of the memory protection (a rogue pointer can trash your system). Which is why this method is not generally recommended.