Linking with an import library is actively importing it, in my imprecise
terminology, so you are actively importing coredll.dll (if it's not
there,
your code will not load). The same should not be true of the ole32
stuff,
according to your last message, where you say nothing about needing COM.
If
that's the case, removing those import libraries is a good thing.
You had to set them in the link settings to get them there; they are not
set
by default. Where, exactly you find them depends on which IDE you are
using...
Paul T.
I'm not actively importing anything - if you can tell me where to drop
those things from the linker, I'd do so in a heartbeat.
The DLL is compiled for PPC2003, but apparently it has about the same
success rate on WM5 devices.
On Feb 18, 4:59 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
If you actively import only coredll, you don't need ole32, oleaut32,
uuid,
or commctrl. How is the DLL getting to the device? You're installing
it
with an installer? You're copying it from a storage card? You're
deploying
it with <what> IDE? The DLL is retargeted for each of the indicated
platform versions? That is, you're recompiling against PPC2003 when
you
run
it on the HP PPC2003 device? Then target Windows Mobile 5 SDK when
running
the result on WM5?
Paul T.
Both of the DLLs I am trying to load only show coredll.dll as a
dependency using dumpbin.
The linker command line only shows these libs, which, as far as I
can
tell, are standard. The DLLs only use libc functions.
coredll.lib corelibc.lib ole32.lib oleaut32.lib uuid.lib
commctrl.lib.
They're both compiled as ARMV4 (not ARMV4I) so CPU type does not
matter.
This happens immediately after a soft reset, and with few other
processes running, so it does not seem to be related to another
running process.
Thanks!
On Feb 18, 3:57 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Linked with what? Dump the DLL dependencies using dumpbin or the
dependency
viewer from Visual Studio. What else is running? If you do a soft
reset
and run your code immediately, does it ever happen?
Paul T.
Most problems: HP VGA PPC 2003 device
Fewer problems: HP QVGA WM5 device
Same: Handheld Products QVGA WM5 device
No problems: Dell Axim VGA WM5 device
So, I don't think the device type is really making a difference
here...
There's no dllmain that we explicitly coded. The compiler may
have
put something in, I guess. The DLLs aren't dependent on anything
exotic, either - they're fairly self-contained.
Does that help diagnose? Thanks!
On Feb 15, 3:43 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam
AT
no instrument no spam DOT com> wrote:
What sorts of devices are we talking about? These are Windows
Mobile?
Your
own, with various builds of various operating systems, etc.?
I'm not so sure that 120 is of no use. It indicates that
something
that's
being done is not possible with the set of operating system
components
built
into the device. If we're talking Windows Mobile, it might
indicate
that,
in your DllMain(), you're doing something that can't be done,
returning
an
error, and therefore not allowing yourself to be loaded. If
it's a
custom
Windows CE device, it might indicate that the file was found,
but
it's
compressed in ROM and the compression component isn't there
(that's
just
an
example of the sort of thing it could be; I don't think it's
possible
to
build the OS in that way).
Every problem is critical to the guy asking!
Paul T.
p/Invoke says "Can't find x.dll" when the function's called.
I tried using LoadLibrary on the DLL and it fails 99.9% of the
time.
I have seen rare cases when it loads.
It loads on other devices perfectly. Others, it has a small
random
failure rate. There's no consistency between the OS and CPU
of
the
failures.
I tried getting the last win32 error and it was 120, which is
of
no
use.
Any ideas? This is rather urgent.
