Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE324A18A@probe-2.Acclaim-Euro.net> From: Shawn Hargreaves To: djgpp AT delorie DOT com Subject: Re: Neeed some help about protected-mode-memory-management Date: Mon, 2 Nov 1998 11:42:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Reply-To: djgpp AT delorie DOT com Christian Hofrichter writes: > How can I get the offset of a variable or a function ? > > offset=&variable; Correct. > offset=function or offset=&function I think that either of those is technically correct, although the first one is by far the most common usage. > How can I get the size of a function ? > (with sizeof ????) In general you cannot. This is IMHO something of a pity, and a sizeof(function) capability would be a very useful compiler extension if someone could hack it into gcc, but that would probably be very tricky to achieve. A common trick is to declare another dummy function immediately after the one you want to measure, and compare their addresses (see the LOCK_FUNCTION() macro in the Allegro library for an example). This method is very ugly, though, and not guaranteed to be reliable across different compiler and linker versions. > Why do I have to lock the memory when I want to access a linear > address? I mean when this space is swaped to disk and I want to > access it with a selector and an offset, doesn't the dpmi-server > reload it from disk automaticly ? Yes indeed. You only need to lock memory when you are using it inside a hardware interrupt handler, because in that context it isn't possible for the DPMI server to reload data that has been swapped out to disk (because it might be in the middle of a DOS call when the interrupt occurs, and DOS doesn't support reentrant calls to the filesystem functions). > When I want to copy memory-blocks in the space above 1 MB (in > assembler), is this the same procedure like in real-mode with the > difference that I have to store the selectors in the registers > where I had to store the segments in the real-mode before ? You don't need to touch the selectors at all: just do a direct copy from one 32 bit address to another, or use the standard memcpy() function. > Can I have direct access to memory in the space above1 MB without > using the FAT DS method ? Yes, this is the whole point of being in protected mode! You can forget all about selectors and far pointers, except for a few very specific cases where you need to talk with 16 bit code or hardware devices. > Can I have direct access to memory in the space under 1 MB without > using the FAT DS method ? Yes, you can use the dosmemput() function, or the routines from . > When I map linear memory, what does it mean ? Does it mean that I > can access this memory-space without a selector because this > space is now in the available address space of my program ? What exactly do you mean by "map linear memory"? If you are talking about the __dpmi_physical_address_mapping() routine, this makes a specific physical address range available in linear memory, so you can then create a selector and use far pointer functions to access it. If you mean the __dpmi_map_device_in_memory_block(), that does indeed make a range of physical addresses available directly in your local address space, but isn't really very useful because it is a DPMI 1.0 function, and this is not available on the vast majority of machines. > How can I get the physical address when I have a selector and an > offset (this memory-space is not swaped to disk) ? You cannot (apart from some very low-level hooks in cwsdpmi, but you really don't want to mess with those). Whyever you think you need this, there is almost certainly some other, better way to do the same thing: check the djgpp FAQ, or give more details about what you are trying to do. If you need this for a DMA buffer, the usual method is to allocate this in a conventional memory block. > Do the memory-copy-routines - for the protected-mode in Djgpp- move > 4 bytes at one time ? Use the Source, Luke! (or I could just say yes, of course they do). > --------------FC45C735E917CFD8ADAB54AF > Content-Type: text/html; charset=us-ascii > Content-Transfer-Encoding: 7bit Please don't post HTML messages on this newsgroup: configure your software properly so that it will send ASCII text that we can all read. Shawn Hargreaves.