wpw_wapi_mem_95.html

VC programing

>strings.

Make double sure that all of your resources are marked "moveable" and
"discardable" in your resource script/resource editor.  Also, the 
numbering of your string resources is important.  Whether or not you 
need it, windows will load chunks of 16 strings at a time.  So, keep
strings that are closely related together, and try to group them
at multiples of 16.  

-- 
-----------------------------------------------------------
Daniel G. Hyams
email:  [e-mail]
WWW:    http://www.eng.clemson.edu/~dhyams/
phone:  [phone]
-----------------------------------------------------------
</PRE>


<HR><A NAME=WINAPI_MEMORY_VIRT_TO_PHYSICAL>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: How to convert virtual addr to physical addr?</H4><PRE>
SILASI C A ([e-mail]) wrote:
: Turnar Christophe ([e-mail]) wrote:
: : I allocate a buffer to perform DMA transfers between a peripheral
: : device and the PC memory. When I allocate, I get a protected mode
: : address but I must inform the DMA controller with a real mode
: : address (seg:ofs sheme). How can I convert the protected mode
: : address into the real mode address ?

: That's not the way to go - what happens if the memory allocated (as
: it should be in p mode) is above the 1MB boundary ? How do you access
: that in real mode ?

: Use GlobalDOSAlloc to allocate the memory and you'll get a protected
: mode selector and a real mode segment which should solve your problem.

: You can use the DPMI functions to get info on selectors (like base
: address and length) if you really want to.

: Hope this helps.

: Adrian
: -- --
: Adrian Silasi
: City University
: London
: ([e-mail])

This example below work fine.

HGLOBAL hGlobalMemory = (HGLOBAL) GlobalAlloc( GPTR!... );

LPVOID  lpMemoryBuff = (LPVOID) GlobalLock( hGlobalMemory );

lpMemoryBuff is a poiner to allocated memory block.

The memory that you use must be Fixed for DMA transfer.

DWORD GetLinearAddress( HGLOBAL hGlblMem )
{
  GLOBALENTRY lpge;

  GlobalEntryHandle( &gpge, hGlblMem );

  return gpge.dwAddress;        // return Linear Address
}

But you are must to know about Paging mode. If Paging is locked then
Linear Address is just physical address. If no, you must to convert
linear address with Paging conventions.

Good luck,
                Alex

<HR>
In article <[e-mail]>, [e-mail] (ray dzurney) wrote:
>Greetings All:
>
>       I need to access absoulte memory locations from within a Windows
>program.  I am assuming that Windows virtualizes all memory accesses.  Is 
there
>a way to convert from a virtual memory location in Windows to its absolute
>(physical) address?   Something like :
>
>       unsigned char *absolute = (unsigned char *)0x00001234L;
>
>which is what I would do in DOS for address 1234h.  Can anyone help me with
>this?  Any and all responses are appreciated.  Thanks in advance.
>

If your running windows 16 bit you can allocate a selector, set its base 
address and its limit, and then create a pointer using that selector and an 
offset. The calls you'll need are (I may not have the names exactly right, see 
the SDK help file)


AllocSelector()
FreeSelector()
SetSelectorBase()
SetSelectorLimit()
MAKELP()

You should be able to decompose an address with

HIWORD()
LOWORD()
GetSelectorBase()






        

--
Stephen Estes
[e-mail]
</PRE>



<HR><A NAME=WINAPI_MEMORY_ALLOC_64K_MORE>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: How to more than 64K of memory?</H4><PRE>
David Gates ([e-mail]) wrote:
: I want to work with strings greater than 64K.  I know to use huge
: pointers.  My problem is that using malloc to allocate space for the
: string takes a parameter for the byte count of type 'size_t'.  size_t
: is defined in MSVC as unsigned int (64K limit).  The same goes for all
: the string manipulation functions such as strcpy.  How do I work
: around this?
: Thanks, Dave


Use _halloc() to allocate memory, and _fstrcpy() & its kin for manipulation.  The
names of these functions are not standard, but I think all modern compiler
vendors provide something equivalent.  Look up the manuals for your local
version.

    Hugh


      Hugh Duggan,           |    [e-mail]
      HP Labs,               |    switchboard: [phone]
      Filton Road,           |    direct     : [phone]
      Bristol BS12 6QZ,      |    fax        : [phone]
      England.               |

<HR>
In article <3u8ilk$[e-mail]>
           [e-mail] "Nina Mohadjer" writes:

>i could really use some help here. here's the situation
>
>- i've got a larger than 64K data to work with and therefore i use
>globalAlloc.
>- i get a pointer to it with globallock and try to change someting at
>location let's say 70000 in the array.
>- i'm using the small model with ds=ss
>- visual c++ version 1.5 is the product.
>
>the problem:
>when i advance the pointer to 70000 it actually looks like it is
>wrapping around and it seems like i write over my initial portions of
>the array. so how can i access past the 64k? there must be a better way
>than messing with the segment address and such.

You need to use a huge pointer, eg:

    char huge *x;
    x = (char huge *) GlobalAllocPtr( GHND, 1000000L );
    x[70000L] = 'a';

>ps. one more for the road, how do i get version 1.52. i hear about this
>subscription thing. how does it work?

You need to buy the VC++ 2.0 package and take out a subscription.
The VC++ subscription gets you three upgrades to VC++:

 - v2.1 (out now - contains the 16-bit VC++ 1.52)
 - v2.2 - due around the end of this month.
 - v4.0 - due out sometime this autumn.

Chris
-- 
--------------------------------------------------------------------------
| Chris Marriott, Warrington, UK      | Author of SkyMap v2 shareware    |
| [e-mail]            | astronomy program for Windows.   |
|      For more info, see http://www.winternet.com/~jasc/skymap.html     |
|      Author member of Association of Shareware Professionals (ASP)     |
--------------------------------------------------------------------------
 
</PRE>

<HR><A NAME=WINAPI_MEMORY_VIRTUAL_TURNOFF>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: How to trun off virtual memory?</H4><PRE>
On Fri, 14 Jul 1995 16:43:11 GMT, [e-mail] (john hazen) said in article <[e-mail]>:
>Hi-
>
>I am writing a multimedia application, and since _real_ memory (RAM) is 
>so much faster than using memory in the swap file, I would like to turn 
>off virtual memory.  If there is no way to do this, can I at least detect 
>when virtual memory is turned on, so I can tell the user to turn it off?

I don't think that would be a good idea.  Instead, I would suggest using 
GlobalPageLock() on any memory that you need to have in RAM at all times.


--
Robert Mashlan             R2M Software Company           Programmer for Hire
mailto:[e-mail]    http://www.csn.net/~rmashlan     PGP key available
Resources for Windows Developers    -     http://www.csn.net/~rmashlan/windev
Windows Developers FAQ    -    http://www.csn.net/~rmashlan/win-developer-FAQ
</PRE>


<HR><A NAME=WINAPI_MEMORY_LOCKED>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: What on earth makes you suppose that locked memory can't be moved?</H4><PRE>

In article <[e-mail]> Chris Marriott <[e-mail]> writes:

>Rubbish. What on earth makes you suppose that locked memory can't be
>moved?

Maybe because it can't. <g>

Locked means locked--if a global memory block is locked, Windows will not move 
it within the linear address space.

Of course, GlobalLock() on a nondiscardable memory block does not lock the 
memory; perhaps that's what you're referring to.  However, GlobalLock() on a 
discardable memory block does lock the memory, and Windows will not move that 
memory in the linear address space.

GlobalFix() is the "true" GlobalLock function in protected mode Windows.  
GlobalFix() always locks the block in question, and that block will not move.

-MG

<HR>
In article <3uvkg1$[e-mail]> Alessandro Iacopetti <iaco> writes:
>Chris Marriott <[e-mail]> wrote:
>
>>>I spent a considerable amount of time searching a justification for the
>>>Handle vs Pointers memory organizations of Windows.
>>>The only benefit seems to be that handles permit compacting memory.
>>>When I do a GlobalLock() the memory block can't be moved around no more, but
>>>can it be swapped to disk?
>>
>>Rubbish. What on earth makes you suppose that locked memory can't be
>>moved?
>
>Thank you for your kind answer...
>So if locked memory can be moved, the last reason for using handles drops...
>or I'm wrong again?

	The only reason I know of for using Windows memory functions
	like GlobalAlloc is "because you have to use them for a few
	specific operations".  The best example is the clipboard - you
	need to pass a handle to it, not a pointer. Therefore you MUST
	use GlobalAlloc.  The only other case I have run into it is for
	accessing the DEVMODES or DEVMODE structs in the PRINTDLG struct.
	I just wanted to display some of the info, so I had to use
	GlobalLock() to get at it.  Other than those 2 uses, I have no
	other occurrences in ~150k lines of Windows code.
-- 
John A. Grant						[e-mail]
Airborne Geophysics
Geological Survey of Canada, Ottawa
</PRE> 

</HTML>