Re: Explicit loading does not work
- From: "Voidcoder" <voidcoder@xxxxxxxxx>
- Date: Mon, 13 Feb 2006 09:01:41 -0800
Oh, it seems you are quite deep in the Black Forest
researching this issue :)
Just an idea, if you first start a different off-screen dummy
app which loads a bunch (lets say a half part) of your DLLs ...
does it show some difference when you load your may app
in this case?
Also have a look at this article, epecially "DLL Load Problem" part
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncenet/html/advmemmgmt.asp
"Vyacheslav Lanovets" <my-emai-is-xentrax@xxxxxxxxxxxxxxxxxx> wrote in message
news:OEIOzi8LGHA.604@xxxxxxxxxxxxxxxxxxxxxxx
Yes, I am sure. It's quite easy to check - make a simple application which loads dll with one exported function and
MessageBox GetProcAddress of this function.
We even got "dumpmem" utility from MS one time when we could not understand why our application can not run on
PocketPC2000 platform. This utility just prints virtual memory layout for the application with XIP attributes if any.
Btw, you can not use memory status WINAPI as it reports XIP memory as FREE virtual memory. ROTFL.
Application DLLs can not be loaded at the address where XIP dlls reside. But all vendors use extensive XIPping to save
RAM and speed up startup of default applications to get good marks in popular magazines reviews: "aha, this PocketPC
can start WMP faster so it gets our best choice award". But this leads to a disaster for even medium-sized industrial
applications.
HeapAlloc by default begins allocating memory from the virtual space between the threads stacks and the lowest dll and
I don' like it.
The workaround is already there: when this space is out, HeapAlloc begins allocating virtual memory from the XIP
space. As a consequence, when application then tries to load the XIPped dlls which reside at these addresses
LoadLibrary fails. We are pretty happy with XIP virtual memory reuse, as HP iPAQs have 16 MB of XIP dlls in Slot0.
We decided to move parts of our application to explicitly loaded dlls. I'm afraid, our PocketPC users will have to
restart our latest version quite often to access explicitly loaded functionality.
I want to somehow change behaviour of HeapAlloc to prevent it allocating memory from the lower addresses. I would like
it to allocate virtual memory from the XIP space or even use WindowsCE VirtualAloc > 2MB dirty hack. Why does Heap
Aloc not use this dirty hack itself?? It could assess VM usage and switch to using shared memory if application size
is more than 4-6 megabytes.
Right now our problem is that some brain-washed customers want PocketPC platform even in our proprietary devices (as
it is "more robust"), but as I was said, 24MB of virtual memory is the maximum, and it's dengerously low.
I am thinking of several ways to workaround.
Probably, if I allocated a big chunk of memory at startup it would begin using XIP at once, this needs to be checked.
One more idea is just to replace HeapAlloc. As internal MS implementaion is inefficient, this might give us additional
benefits.
Another idea is to lock precious virtual addressed by VirtualAlloc, and unlock only required minimum for loading dll
by estimating size of the dll on the disk and rounding it by 64K. I am planning to begin with this one.
Regards,
Vyacheslav
"Voidcoder" <voidcoder@xxxxxxxxx> wrote in message news:eI%23AETlLGHA.1180@xxxxxxxxxxxxxxxxxxxxxxx
Hm, are you sure the problem is some
hardcoded limit for a differnet platforms?
Probably something is causing one or more
DLLs to allocate more or less memory during the
DLLMain(DLL_PROCESS_ATTACH) call on
different devices.
"Vyacheslav Lanovets" <my-emai-is-xentrax@xxxxxxxxxxxxxxxxxx> wrote in message
news:Oi9iXjkLGHA.2912@xxxxxxxxxxxxxxxxxxxxxxx
Hi!
Believe it or not, but even default PocketPC 2003SE platform has only 24 MB of virtual memory for loading dlls. All
modern HP iPAQs have only 16 MB for loading dlls.
For instance, hx2790 loads first dll at 15.8 MB address. XIPoing speeds up loading built-in software and reduces
physical memory requirements but it prevents other software from functioning. Our own rugged devices use HPC version
of WCE 4.2, and we have access to all 32 MB of virtual memory. Hardware department is only happy that we can not
support altenative devices.
Our application size on the disk is ~ 14 MB. It uses SQLCE and ADO - 2 MB more.
We could convert to explicitly loaded DLLs as much as 7MB, so with latest changes the lowest dll loads at 5MB
address.
The problem is that we can not change ADO/SQLCE source code, we have some third-party LIBs (AutoDesk) and our code
uses a lot of CStrings, CArrays, CMaps and so on. We have some legacy code which uses STL. All of the above use
HeapAlloc to get memory.
When memory allocated by HeapAlloc gets freed, it is not returned to system. So, after loading data from DXF or
plotting complex map on the screen, EXPLICIT LOADING DOES NOT WORK.
So the best solution would be to dynamically replace this function and provide our own implementation which would
use VirtualAlloc hack.
On the other hand, I think, MS might provide some way to tweak HeapAlloc behavior.
"Voidcoder" <voidcoder@xxxxxxxxx> wrote in message news:eXf3ethLGHA.3492@xxxxxxxxxxxxxxxxxxxxxxx
Do you really need all the DLLs loaded in the same time? Why not
to load them dynamically?
Also 12MB is quite far away from the 32MB limit. Are there any
huge memory allocations in your code? Or may be too much
allocations/releasing blocks of different size, causing heap
fragmentation? You can use memory mapped files or VirtualAlloc
to allocate extra memory outside the 32MB slot space.
"Vyacheslav Lanovets" <my-emai-is-xentrax@xxxxxxxxxxxxxxxxxx> wrote in message
news:ewEzk%23gLGHA.1536@xxxxxxxxxxxxxxxxxxxxxxx
Hi All
We have an application with ~ 12 MB of dlls linked and loaded implicitly. After application starts on WM2005
device (HP iPAQ), I try to explicityly load 1 more dll (~ 1 MB), but it does not load because, it seems virtual
memory below all loaded dlls is already busy by the heap.
There is a "feature" in Windows CE to reuse XIP virtual addresses for operator new() / malloc() allocations. But
this feature starts working only after some of the heap was already allocated in its standard place - just under
all loaded dlls.
Is it possible to do something from the application developer standpoint to tweak it so it would reuse XIP space
just from the start? Some linker settings? Secret registry key? Some hook on HeapAlloc to replace it with own
memory manager?
I was thinking of explicitly loading empty stub 2-3MB dll during static data initialization. So when I need to
explicity load something useful I would unload stub dll, load required dll, do the job, and then put stub dll back
into memory.
Regards, Vyacheslav
.
- References:
- Explicit loading does not work
- From: Vyacheslav Lanovets
- Re: Explicit loading does not work
- From: Voidcoder
- Re: Explicit loading does not work
- From: Vyacheslav Lanovets
- Re: Explicit loading does not work
- From: Voidcoder
- Re: Explicit loading does not work
- From: Vyacheslav Lanovets
- Explicit loading does not work
- Prev by Date: Re: Using sprintf with float numbers doesn't work
- Next by Date: Re: Desperately Need STANDARD SDK 400 and 410 for eVC++ 4.0
- Previous by thread: Re: Explicit loading does not work
- Next by thread: Performance correction on drawing.
- Index(es):
Relevant Pages
|
Loading
