Solved

GetLongPathNameW error - VC8 Build for NT4 Target

Posted on 2007-03-26
18
878 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 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
Flexible connectivity for any environment

The KE6900 series can extend and deploy computers with high definition displays across multiple stations in a variety of applications that suit any environment. Expand computer use to stations across multiple rooms with dynamic access.

 
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
 

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

Free Tool: Postgres Monitoring System

A PHP and Perl based system to collect and display usage statistics from PostgreSQL databases.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Learn how to PXE Boot both BIOS & UEFI machines with DHCP Policies and Custom Vendor Classes
This article summaries thoughts and ideas from two years of sustained use. It provides good reasoning to make the jump to Windows 10.
This Micro Tutorial will give you a basic overview of Windows DVD Burner through its features and interface. This will be demonstrated using Windows 7 operating system.
The viewer will be introduced to the member functions push_back and pop_back of the vector class. The video will teach the difference between the two as well as how to use each one along with its functionality.

749 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