LoadLibrary call on Pocket PC Mobile Ed 2003 vs Windows CE.Net 4.2

Hi there,

Are there differences in behaviour with LoadLibrary() between CE.Net 4.2 and
Pocket PC Mobile Edition 2003?

I've got some code that has been working great on a CE.Net 4.2 device. The
code calls LoadLibrary to load in a custom DLL.

The same device was upgraded to run Pocket PC Mobile Edition 2003. Now my
software is failing at the LoadLibrary call. Calling GetLastError() returns
"module not found".

This situation perplexes me given that the library exists alongside the
executable. I've even put the library in the Windows directory; same result.

Thanks for any help.

Cheers,
-C

Alex
Wed Mar 09 19:00:45 CST 2005

Do you suppose it might have some dependencies that fail to resolve?

--
Alex Feinman

---
Visit http://www.opennetcf.org
"Christopher Hunt" <Christopher Hunt@discussions.microsoft.com> wrote in
message news:AE7355FA-B1E8-4219-89BC-A62DF4B3DFB9@microsoft.com...
> Hi there,
>
> Are there differences in behaviour with LoadLibrary() between CE.Net 4.2
> and
> Pocket PC Mobile Edition 2003?
>
> I've got some code that has been working great on a CE.Net 4.2 device. The
> code calls LoadLibrary to load in a custom DLL.
>
> The same device was upgraded to run Pocket PC Mobile Edition 2003. Now my
> software is failing at the LoadLibrary call. Calling GetLastError()
> returns
> "module not found".
>
> This situation perplexes me given that the library exists alongside the
> executable. I've even put the library in the Windows directory; same
> result.
>
> Thanks for any help.
>
> Cheers,
> -C

ChristopherHunt
Wed Mar 09 19:31:03 CST 2005

> Do you suppose it might have some dependencies that fail to resolve?

Thanks Alex. I did check that by running dumpbin.exe to check on the
dependencies of the DLL. The dependencies are the same as the application
that is calling LoadLibrary so I don't think that dependencies are the issue.

I'm also aware of the 16MB limitation on DLL loading and, given that I'm
using the MFC dll, I'm wondering if memory is the problem (as explained at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncenet/html/advmemmgmt.asp).
However I would have throught that GetLastError() would have returned a
memory related error code and not "module not found" if memory is the problem.

Any more ideas? I'm thinking of statically linking MFC to the DLL and seeing
how that goes just in case we're looking at a memory related issue. Is there
a better way to diagnose dll memory exhaustion or am I barking up the wrong
tree?

Cheers,
-C

Alex
Wed Mar 09 19:54:25 CST 2005

Are you sure the MFC dlls are all there?

--
Alex Feinman
---
Visit http://www.opennetcf.org
"Christopher Hunt" <ChristopherHunt@discussions.microsoft.com> wrote in
message news:AFF8F10E-8879-48A6-9CE1-C5CAC666A9F5@microsoft.com...
>> Do you suppose it might have some dependencies that fail to resolve?
>
> Thanks Alex. I did check that by running dumpbin.exe to check on the
> dependencies of the DLL. The dependencies are the same as the application
> that is calling LoadLibrary so I don't think that dependencies are the
> issue.
>
> I'm also aware of the 16MB limitation on DLL loading and, given that I'm
> using the MFC dll, I'm wondering if memory is the problem (as explained at
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncenet/html/advmemmgmt.asp).
> However I would have throught that GetLastError() would have returned a
> memory related error code and not "module not found" if memory is the
> problem.
>
> Any more ideas? I'm thinking of statically linking MFC to the DLL and
> seeing
> how that goes just in case we're looking at a memory related issue. Is
> there
> a better way to diagnose dll memory exhaustion or am I barking up the
> wrong
> tree?
>
> Cheers,
> -C

ChristopherHunt
Wed Mar 09 23:19:03 CST 2005

> Are you sure the MFC dlls are all there?
Well, the calling app works and the dependencies are the same; in fact, the
calling app has more dependencies that the dll.

I might try statically linking MFC though and see if the problem goes away.
I might also try just loading a well-used dll and see if I can successfully
load that ('just to ensure that I'm not going insane).

ChristopherHunt
Thu Mar 10 17:37:07 CST 2005

OK, problem solved. Little did I realise that PPC ships with an older version
of MFC than Windows CE.Net 4.2. My dll was trying to load v4 of MFC
(mfcce400.dll). I cleaned my build directory and rebuilt my dll and presto,
the dependency was now (mfcce300.dll).

How annoyingly confusing. Maybe one day MS will based PocketPC on the latest
Windows CE.

Now to find out what the differences are between v3 and v4 of MFC!

Alex
Thu Mar 10 18:17:08 CST 2005

PPC does not ship with MFC dlls. They could have been installed there by
some software OEM bundles with the device, but not likely in ROM. eVC is
your source of MFC DLLs. eVC 3 comes with MFC 3. eVC 4 comes with MFC 4. For
PPC2003 projects you are supposed to use eVC 4, so there is nothing wrong.

--
Alex Feinman
---
Visit http://www.opennetcf.org
"Christopher Hunt" <ChristopherHunt@discussions.microsoft.com> wrote in
message news:B5FF7A9D-333F-4FA7-944E-B88F92846268@microsoft.com...
> OK, problem solved. Little did I realise that PPC ships with an older
> version
> of MFC than Windows CE.Net 4.2. My dll was trying to load v4 of MFC
> (mfcce400.dll). I cleaned my build directory and rebuilt my dll and
> presto,
> the dependency was now (mfcce300.dll).
>
> How annoyingly confusing. Maybe one day MS will based PocketPC on the
> latest
> Windows CE.
>
> Now to find out what the differences are between v3 and v4 of MFC!

ChristopherHunt
Thu Mar 10 19:47:01 CST 2005

When I cleaned my project out and then re-built, the dependency was on v3,
not v4. Previously it was v4 'cause I was building to the CE.Net 4.2 target
and I hadn't cleaned out the directory before building to the Pocket PC
target.

dumpbin.exe confirmed that the previous build depended on v4 and that the
new build depended on v3.

I'm using SP4 of evc++ 4.

Maybe my device manufacturer placed the MFC libraries on the device - it is
a customsed rugged PDA, not a general consumer one.