DLL does not load dynamically on AMD64 X2 running windows xp pro (Japanese version)

Cannot dynamically load a DLL completely when using an AMD64 X2 machine with the Japanese version of windows xp pro. The DLL will load and work properly on all 32 bit and xeon processors. The failure point comes from not being able to retrieve a handle to a couple of functions inside the DLL. Actually it fails for 3 functions only out of 25. What can be done to overcome this? Any ideas what to look for?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

well, I would start by what you "assume".
for example, you assume that integer is 4 bytes in size. if you are using anyware in your program/dll another DLL (sdk, framework or even WINAPI) and you (or that fnction from dll) assumes that the integer is 4 bytes, then on a 64 bit processor where the integer is 8 bytes you will have undesireble effects.
this is only one example of things going wrong because you assume something. like when you assume that all variables are automatically initialized and then after 2-3 years you change the memory manager which will no longer initialize the variables.

basically, we cannot help if we don't see the faulty functions. I would assume that all 3 have the same problem so let';s start with the shortest one. post it here so we can have something on which to discuss.
I suggest also looking very carefully at the spelling of the names of each function.  You can use a program named Dependency Walker (Depends.Exe) to see the exact spelling of every Export.
inora08Author Commented:
Thanks for the suggestions.
Another close look at what exactly happens, revealed that the problem was in the installer. For some strange reason, it did not overwrote the DLL on that particular computer. It seems like a issue with some permissions in Windows. This got fixed now everything is running.

Lesson learned: ALWAYS assign new build numbers to everything, then manually check if you really use the correct program/dll.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Development

From novice to tech pro — start learning today.