GetLongPathNameW error - VC8 Build for NT4 Target

I am migrating code from MS VC6 to VC8.  My app HAS to be able to run on XP and NT4 machines.  The APP runs fine on XP.  I get an error on NT machines stating 'could not find enry point for GetLongPathNameW in kerneal32.dll'

I have tried placing the following in my StdAfx.cpp file.

How is the implementation of NewAPIs.h suppose to be done?
Is NewAPIs.h the expected way to may Apps backward compatible?
If not, what needs to be done to allow the app to run NT4 and XP machines?

--------------------------------------------------------
// stdafx.cpp : source file that includes just the standard includes
//      stdafx.obj will contain the pre-compiled type information
#include "stdafx.h"

// needed for NT machines to work with GetLongPathNameW
#define COMPILE_NEWAPIS_STUBS
#define WANT_GETLONGPATHNAME_WRAPPER
#include <NewAPIs.h>  
--------------------------------------------------

VideoFletchAsked:
Who is Participating?
 
itsmeandnobodyelseConnect With a Mentor Commented:
>>>> by creating a new project and add the sources to this new project.
>>>> Sorry, I do not understand what you mean.

you told you have problems linking the with the static libraries of MFC. My suggestion to build up a new project would solve problems that ocurred because of manually changing from shared to static.

>>>> maybe I don't have all the needed runtime libraries installed
No, the problem occurs in kernel.dll and a update to kernel.dll only could be done by a service pack or by a patch  but there are no further service packs or patches planned for NT (as far as I know).

We have two facts:

1. There is a module that calls GetLongPathNameW.
2. kernel.dll at NT doesn't contain a GetLongPathNameW.

IMO, you can't do anything with 2. So 1. is left and is the only choice. If you could spot the dll that needs GetLongPathNameW (by Dependency Walker) we could try to exchange that dll e.g. by using a static library instead or by using a non-Unicode version of the dll (if any) or by eliminating the cause for calling that function, e. g. by not loading a dll dynamically but statically or by using a data source rather than accessing the DAO database via filename, ...

But before we can do anything we need more information ...

 >>>> thought this was going to be an easy one
No, compatibility issues never are easy. If you are using functions in mfc80.dlls it is clear that you most likely get problems on older Windows platforms. Mfc80.dlls only contain 'new' functions that were needed to port MFC to .NET and XP. If you want to run the ported application on a NT machine you would need to use the 'old' libraries. That may include that you have to make portable code that compiles at VC8, VC7 and even VC6 if necessary and that can be build at the target platform.

The issue that VS2005 cannot be installed at NT is a good indication that programs build with VC8 most probably don't run at NT.

Regards, Alex
 
0
 
itsmeandnobodyelseCommented:
the only purpose of stdafx.cpp is to compile the precompiled header. What do you expect when including <NewAPIs.h>  ? If it isn't included in stdafx.h none of the cpp that use precompiled header can successfully include it again cause header protections actually don't work if you play around with precompiled headers. I strongly recommend to let your fingers from stdafx.cpp and some less strongly to not change stdafx.h beside of that you got generated by the wizard.

Regards, Alex
 
0
 
jkrCommented:
You should not directly reference 'GetLongPathNameW', just 'GetLongPathName' - the emulation layer will take care about whether to use 'GetLongPathNameW' or 'GetLongPathNameA'. If you use either the ANSI or UNICODE name directly, you'll run into the above problem, since 'NewAPIs.h' only translates 'GetLongPathName'.
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

 
VideoFletchAuthor Commented:
I've searched through the entire code and include files.  I can find any direct (or indirect) reference to GetLongPathNameW or even GetLongPathName.

It doesn't seem to matter where I put the NewAPIs.h header and defines.  I still get the same runtime error on the NT4 machine.  
0
 
jkrCommented:
What libraries are you linking with?
0
 
VideoFletchAuthor Commented:
Standard MFC libraries
dao35.lib
daouuid.lib
Other third party libraries.  I have source code too these and do not find any reference in them.

The GetLongPathNameW is referenced in <WinBase.h> which is in <Windows.h>
0
 
jkrCommented:
According to the MFC source code of VC8, this one does not use 'GetLongPathName()'. Chances are that the DAO libs do (you can chekc that by opening them in a text editor and searchig for that function). Yet if that applies, you have a problem...
0
 
VideoFletchAuthor Commented:
GetLongPathName was not found in my search of the DAO libs.
0
 
itsmeandnobodyelseCommented:
>>>> The GetLongPathNameW is referenced in <WinBase.h>
Yes but only if _UNICODE is defined for the project.  Is it a UNICODE project?

If not, I would assume that you mixed up VC6 and VC8 headers.

If it is UNICODE, you might consider to install the VC8 on the NT and build it there. Some of the WINAPI is dependent on the Windows Version. So compiling on NT may help.

Another attempt maybe to switch of Precompiled Headers. Sometimes when using PCH, project macros cannot be recognized properly as anything defined at file level maybe spoiled by the PCH.

Regards, Alex
0
 
jkrCommented:
>>GetLongPathName was not found in my search of the DAO libs.

Since neither MFC nor DAO uses that one, open your app with the DependencyWalker (from www.dependencywalker.com) to check whether another DLL that yur app requires imprts that function.
0
 
VideoFletchAuthor Commented:
It is not a UNICODE project. Changing the PCH option did not change issue.  
 I'm looking into the DLL imports.
0
 
jkrCommented:
Be sure to check that on the target machine.
0
 
itsmeandnobodyelseCommented:
>>>> It is not a UNICODE project.
If you look at the definition of GetLongPathNameW in Winbase.h you will see that the macro GetLongPathName was only mapped to GetLongPathNameW in case of UNICODE. Ok, there is a rare chance that some function calls GetLongPathNameW directly not using the macro GetLongPathName which would map to GetLongPathNameA in non-UNICODE. You can check that by changing GetLongPathNameW to GetLongPathNameXXX in Winbase.h and make a rebuild all. The compiler should complain if GetLongPathNameW was called somehow by any of your sources. If the compiler doesn't complain it is - as jkr already told - worse cause any of the libraries linked to your program made that call. If you are using a third-party library you may check if they have different libraries for UNICODE and non-UNICODE and change accordingly. If not you were lost ...

Regards, Alex
0
 
VideoFletchAuthor Commented:
I have stripped my program down to remove all third party LIB and headers.  I am not linking any defined libs.  I have found that if I Compile project with "Use MFC in a Static Library" instead of "Use MFC in a Shared DLL" that it runs fine on the NT system.
Does this shed any light on the issue?  

I went back and tried the orginal project with the Static Library, but I get several linker errors using the Static vs. the Shared.

Is the <NewAPIs.h> not needed to resolve this issue?


Thanks.
0
 
jkrConnect With a Mentor Commented:
>>Is the <NewAPIs.h> not needed to resolve this issue?

If you are not directly calling that API in question, no. And even worse, it won't help when any library or DLL that your app uses links to it. I actually suspect that the runtime libraries of VC8 do.
0
 
itsmeandnobodyelseCommented:
>>>> but I get several linker errors using the Static vs. the Shared.
You could solve that by creating a new project and add the sources to this new project. If you move the old project to a new directory you can use the old name what might make things easier.

Regards
0
 
VideoFletchAuthor Commented:
>>You could solve that by creating a new project and add the sources to this new project. If you move the old project to a new directory you can use the old name what might make things easier.

Sorry, I do not understand what you mean.  Whatever, my issue is with GetLongPathNameW it seems to be related to the MFC80 dlls.   Another thought on this is that maybe I don't have all the needed runtime libraries installed in the NT machine.  The VC2005 MFC8 distribution program does not run on NT because the MSI for NT is version 2.0 and the MFC8 installer needs version 3.0.  Version 3.0 will not install on NT.  

DependencyWalker basiclly shows the same thing... A conflict with an invalid entry point in Kenrel32.dll.

I thought this was going to be an easy one compared to my dao35 issue. 8-]


0
 
VideoFletchAuthor Commented:
Ok.  Here is my final solution to the issue.  Not perfect, but it'll do.

After much trial and effort, I was never able to find a solution that allowed my EXE built in VC2005 to run on a WinNT platform.   I found some references on the web suggesting that by rebuilding the CRT libraries, the EXE might work on NT.  I did not attempt this and don't want to.

I have resolved to maintain two EXE versions.  I have modified my source code to compile under VC6 and VC8.  I have placed "#if _VC6" compiler definitions around areas of the code that were modified specificly to work with VC8, but not compatible with VC6.  This allows the same code to be built in the two different enviroments.  I will continue to support my NT client base with EXE files built in VC6 and do all my development work and support of XP clients on VC2005.   Not the best senerio, but at least I can move forward with technology until my clients update their OS.

All the comments above and this link were helpful in understanding several of the limitations I was running into:
http://www.codeproject.com/cpp/vcredists_x86.asp

Thanks for everyone's input on this!  Hopefully, this topic will reduce the stress and headache of anyone else stuck on this issue.  

Best Regards,
Steve
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.