Solved

GetLongPathNameW error - VC8 Build for NT4 Target

Posted on 2007-03-26
18
856 Views
Last Modified: 2013-12-28
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>  
--------------------------------------------------

0
Comment
Question by:VideoFletch
  • 7
  • 6
  • 5
18 Comments
 
LVL 39

Expert Comment

by:itsmeandnobodyelse
ID: 18792888
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
 
LVL 86

Expert Comment

by:jkr
ID: 18793032
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
 

Author Comment

by:VideoFletch
ID: 18793101
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
 
LVL 86

Expert Comment

by:jkr
ID: 18793132
What libraries are you linking with?
0
 

Author Comment

by:VideoFletch
ID: 18793244
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
 
LVL 86

Expert Comment

by:jkr
ID: 18793312
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
 

Author Comment

by:VideoFletch
ID: 18793384
GetLongPathName was not found in my search of the DAO libs.
0
 
LVL 39

Expert Comment

by:itsmeandnobodyelse
ID: 18793426
>>>> 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
 
LVL 86

Expert Comment

by:jkr
ID: 18793459
>>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
Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

 

Author Comment

by:VideoFletch
ID: 18793682
It is not a UNICODE project. Changing the PCH option did not change issue.  
 I'm looking into the DLL imports.
0
 
LVL 86

Expert Comment

by:jkr
ID: 18793729
Be sure to check that on the target machine.
0
 
LVL 39

Expert Comment

by:itsmeandnobodyelse
ID: 18793870
>>>> 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
 

Author Comment

by:VideoFletch
ID: 18795748
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
 
LVL 86

Assisted Solution

by:jkr
jkr earned 100 total points
ID: 18795769
>>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
 
LVL 39

Expert Comment

by:itsmeandnobodyelse
ID: 18795913
>>>> 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
 

Author Comment

by:VideoFletch
ID: 18800039
>>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
 
LVL 39

Accepted Solution

by:
itsmeandnobodyelse earned 400 total points
ID: 18800561
>>>> 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
 

Author Comment

by:VideoFletch
ID: 18858797
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

Featured Post

Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

The use of stolen credentials is a hot commodity this year allowing threat actors to move laterally within the network in order to avoid breach detection.
Our Group Policy work started with Small Business Server in 2000. Microsoft gave us an excellent OU and GPO model in subsequent SBS editions that utilized WMI filters, OU linking, and VBS scripts. These are some of experiences plus our spending a lo…
This video Micro Tutorial explains how to clone a hard drive using a commercial software product for Windows systems called Casper from Future Systems Solutions (FSS). Cloning makes an exact, complete copy of one hard disk drive (HDD) onto another d…
The Task Scheduler is a powerful tool that is built into Windows. It allows you to schedule tasks (actions) on a recurring basis, such as hourly, daily, weekly, monthly, at log on, at startup, on idle, etc. This video Micro Tutorial is a brief intro…

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now