📄 wpw_w32_mem_95.html
字号:
<HTML>
<HR><A NAME=WIN32_DLL_SHAREDATA>
Return to <a href="wpw_w32_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Win32 DLL and share data</H4><PRE>
In article <3rvnen$pk2@uni4nn.iaf.nl>,
J.Buitenhuis@uni4nn.iaf.nl (Jan Buitenhuis) wrote:
"
"Hello,
"
"I would like to make a DLL that declares some variables
"(static or what ever) that every process can use.
"For instance a window or dialog box. Is this possible.
"I can't get it to work.
"
"Thanks, Jan
Jan,
Check out "Advanced Windows" by Jeffrey Richter. His chapter on DLLs explains
things pretty clearly. In summary, assuming you're using an MS compiler:
1. Surround your variable declarations w/ #pragma dataseg() statements, e.g.
#pragma data_seg(".SHARED")
int nSharedInt = 0;
#pragma data_seg()
2. Make sure to initialize them to a default value.
3. Add a "SECTIONS" section to your .DEF file and make sure your new named
section is declared SHARED, e.g.
SECTIONS
.SHARED READ WRITE SHARED
Unless all three of these conditions are met, you won't get shared data
between processes. If you use this technique, however, you're going to have to
watch out for thread safety. Good luck.
Chris Sells csells@teleport.com CIS:73160,2150 """""
DevelopMentor csells@develop.com (310) 214-7800 { ( )-( ) }
Teaching C++, Win SDK, Win32, Win'95, OLE, MFC and MAPI |
---The opinions expressed above are mine, all mine!!--- \___/
>Alternatively you can use memory mapped files. Probably a LOT simpler!
Actually, memory mapped files is the only way to make this work reliably.
Under NT, a request for a shared data segment may be (silently) ignored!
Jeff Dean
jeff@igc.apc.org
In article <3s0hvd$8n6@maureen.teleport.com>
csells@teleport.com "Chris Sells" writes:
>1. Surround your variable declarations w/ #pragma dataseg() statements, e.g.
>
>#pragma data_seg(".SHARED")
>int nSharedInt = 0;
>#pragma data_seg()
>
>2. Make sure to initialize them to a default value.
>
>3. Add a "SECTIONS" section to your .DEF file and make sure your new named
> section is declared SHARED, e.g.
>
>SECTIONS
> .SHARED READ WRITE SHARED
>
>Unless all three of these conditions are met, you won't get shared data
>between processes. If you use this technique, however, you're going to have to
>watch out for thread safety. Good luck.
Alternatively you can use memory mapped files. Probably a LOT simpler!
Chris
--
--------------------------------------------------------------------------
| Chris Marriott, Warrington, UK | Author of SkyMap v2 shareware |
| chris@chrism.demon.co.uk | 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=WIN32_WINNT_VM>
Return to <a href="wpw_w32_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: WinNT virtual memory system</H4><PRE>
NT's memory management is quite good. You will find that the way that
virtual memory is used is quite impressive. It is simply just one huge
chunk of memory which is then devided up per app in certain proportions
and ways. I don't know the specifics, but have read them.
NT's appropriation of system resources is somewhat customizable as to
what processor and how much foreground vs. background memory is used.
The strength and the limitations to NT are in its strict adherence to its
api. Even in device driver creation there is a tight and very secure api.
You can't get directly at the hardware without going through subsystems
which adress the hardware abstraction layer through some type of api.
Inside Windows NT by Hellen Custer gives a great overview of the makeup
of these subsystems. It is not too technical, but technical enough to be
worthwhile. It is available through the MS Press. After reading this
book, I fell in love with NT.
You may want to look into the NT Resource Kit for tweeking the OS in
performance areas, it is relatively cheap. Also the MSKB might be a good
place to look available at microsoft.com.
</PRE>
<HR><A NAME=WIN32_WINNT_MALLOC_FREE>
Return to <a href="wpw_w32_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: malloc/free under WinNT</H4><PRE>
In <3s29ts$b27@gap.cco.caltech.edu>, heathh@beat.ugcs.caltech.edu (Heath I Hunnicutt) writes:
>rweir@cybercom.net (Robert Weir) writes:
>
>>2) Use a commercial drop-in replacement for malloc() which is tuned to
>>run faster in a virtual memory environment, like SmartHeap.
>
>Why buy one when you can call HeapAlloc() and HeapFree()? They come
>with the OS, work in '95, and are smarter (apparently) than the VC
>calls.
malloc/free probably turn around and call these routines anyway.
The problem with malloc/free is that they have to be general. They
don't know how they are going to be used. If you know how you are
going to allocate/free memory, you can do a better job yourself using
the base OS memory routines.
I know that I wrote a program that did a lot of memory allocations. It could
potentially have a LARGE amount of memory allocated, up to 30 meg. I used
malloc/free at first, but once memory usage exceeded physical ram, performance
really plummited. I changed to allocating a large sparse memory object, and doing
suballocations from this, and performance improved dramatically. (This was with
OS/2 and BC++ OS/2, this should apply to Win32 also). I suspect that the C malloc
call was stepping through memory, trying to find a hole in it's heap large enough
for the allocation. However, to examine the memory, it had to page memory in.
The OS, I believe, has a more efficient mechanism for this. Probably the commercial
mallocs do to.
-----------------------------------------
-- Kevin Krieser
-- Using OS/2 Warp
-- Address: kkrieser@ionet.net
<HR>
Alex Siegel (scimitar@netcom.com) wrote:
: I have a rather large application that does a gazillion (technical term)
: malloc/frees. Now, I've run the same application under UNIX with Purify
: so I'm pretty sure I'm not leaking. However, under NT, virtual memory
: usage goes into high orbit. Does free really work as advertised under
: NT?
This depands on your compiler! The Win32 memory and heap functions
certainly do work. If your compiler does nothing for free() then that's
not the OS's problem.
--
Lucien Cinc (lcinc@cs.newcastle.edu.au)
Author of WinOne, a Super Command Line Shell for Win3.1, WinNT & Win32s
3.1: ftp.cica.indiana.edu:/pub/pc/win3/util/w_one49a.zip & w_one49b.zip
NT: ftp.springsoft.com:/pub/springsoft/win32/shell/ntcmd64.zip
</PRE>
<HR><A NAME=WIN32_WINNT_CHECK_FREE_MEMORY>
Return to <a href="wpw_w32_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: How to check for free memory under WinNT?</H4><PRE>
Ole Matzura <ole@mango.mef.ki.se> wrote:
>How does the standard About Box in i.e. the Program Manager
>check free mem?
It doesn't, it reports the total physical memory of your computer, at
least mine does under NT 3.5
This question, though, is something I've wondered myself, I'll be
interested in seeing the replies to your message.
David
bradley@erinet.com
David
bradley@erinet.com
<HR>
In article <3tqpiv$pmv@news.kth.se>, Ole Matzura <ole@mango.mef.ki.se> says:
>My program allocates some big arrays (using malloc) and frees
>them (using free) later on, checking with the above
>GetMemAvail() doesn't seem to acknowladge the freed arrays,
>but I know they have been freed since I can allocate them
>again. After alot of allocating and freeing, GetMemAvail
>reports no free memory, which isn't right.
Here's the explanation!
The operating system maintains a pool of virtual memory. From
this pool, application malloc libraries request blocks of memory.
When you allocate an array, the malloc library returns memory
from this requested block. If it needs to, malloc gets more
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -