Microsoft VisualStudio2005 and NT4

NT4 is no longer supported by Microsoft, and it's most likely to not support several features in the latest runtimes.

The msot important question should be: Why the hell are you running NT4? It's obsolete.

Toolmaker

So is Win98 but people still run it.

If it says missing entry point, then it's not available on WinNT4. Maybe you can try the non-unicode build. I'm assuming you are using unicode.

If it is a crash, then there is a bug on NT4.

You might want to try VC++6 or .NET 2002 (or whatever came just after)

Question 1.
Why the hell are you running NT4? It's obsolete.
My job's in industrial automation. My firm have many PC installed (>300) with SO NT4.

Question 2.
I try, from codeguru forum (http://www.codeguru.com/forum/showthread.php?p=1411693#post1411693):
- Insert include, #include , in stdafx.h
- Compiled in Release Win32
- Copy in target PC (with SO NT4 SP6) .exe file and mfc80u.dll, msvcr80.dll

but error persist, "... entry point GetLongPathNameW in Kernel32.dll".

Now i try non-unicode build.

Thank

I try non-unicode build, steps:

- Command row:
/O2 /GL /D "WIN32" /D "_WINDOWS" /D "NDEBUG" /D "_AFXDLL" /FD /EHsc /MD /Yu"stdafx.h" /Fp"Release\PV_filename.pch" /Fo"Release\\" /Fd"Release\vc80.pdb" /W3 /c /Wp64 /Zi /TP ".\filename.cpp"

- Copy in target dir mfc80.dll

- Copy .exe file.

But error persist, "... entry point GetLongPathNameW in Kernel32.dll".

Using NT4 isn't adviseable, but I see the problem now. I remember this from my Win32 programming book by Petzhold:

Both NT4 and Windows 98 do not support Unicode applications. Any function that ends with W is most-likely NOT supported in either operating system. Windows 98 has a few of those functions, where NT4 completely lacks support for anything remotely unicode.

You're using Visual Studio 2005, and any 2005 projects compile to unicode by default. You should browse the project settings and change it to Ascii.

I don't have access to any Visual Studio 2005 product right now, but it's somewhere in the project settings. Changing it to Ascii should resolve the problem, as the function it will look for will not be "GetLongPathNameW" but "GetLongPathNameA".

Toolmaker

NT4 is the very first Windows to really do Unicode (after NT3.51 of course).

The problem is the function GetLongPathName. It is simply not available on NT.

If you're calling that function yourself you have to find a workaround. If something from inside MFC is calling it, you may have to revert to an older version of MFC (and Visual Studio probably).

Thank for reply.

I find in PageProperty but not found any item for changing in Ascii mode.
I find in C/C++ or Linker tree ?

--- C/C++ Command row ---
/O2 /GL /D "WIN32" /D "_WINDOWS" /D "NDEBUG" /D "_AFXDLL" /D "_MBCS" /FD /EHsc /MD /Yu"stdafx.h" /Fp"Release\PV_SerTFT.pch" /Fo"Release\\" /Fd"Release\vc80.pdb" /W3 /nologo /c /Wp64 /Zi /TP /errorReport:prompt

--- Linker Command row ---
/OUT:"C:\Documents and Settings\Administrator\Documenti\Visual Studio 2005\Projects\PV_SerTFT\Release\PV_SerTFT.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"Release\PV_SerTFT.exe.intermediate.manifest" /DEBUG /PDB:"c:\Documents and Settings\Administrator\Documenti\Visual Studio 2005\Projects\PV_SerTFT\release\PV_SerTFT.pdb" /SUBSYSTEM:WINDOWS /OPT:REF /OPT:ICF /LTCG /MACHINE:X86 /ERRORREPORT:PROMPT

I try, suggest from CodeGuru forum, Dependency Walker program for find version of kernel32.dll and check if GetLongPathNameW exists.

Report is:
--- System Information ---
Dependency Walker: 2.1.3623 (32-bit)
Operating System: Microsoft Windows NT Professional (32-bit)
OS Version: 4.00.1381 Service Pack 6
Processor: x86 Family 5 Model 8 Stepping 1, GenuineIntel, ~267MHz
Number of Processors: 1
Computer Name: SCCI4
User Name: Administrator
Local Date: martedì 20 giugno 2006
Local Time: 10.44.53 ora legale Europa occ. (GMT+02:00)
OS Language: 0x0410: Italian (Standard)
Memory Load: 0%
Physical Memory Total: 133.615.616 (128 MB)
Physical Memory Used: 98.770.944
Physical Memory Free: 34.844.672
Page File Memory Total: 1.194.180.608
Page File Memory Used: 173.637.632
Page File Memory Free: 1.020.542.976
Virtual Memory Total: 2.147.352.576
Virtual Memory Used: 27.906.048
Virtual Memory Free: 2.119.446.528
Page Size: 0x00001000 (4.096)
Allocation Granularity: 0x00010000 (65.536)
Min. App. Address: 0x00010000 (65.536)
Max. App. Address: 0x7FFEFFFF (2.147.418.111)

--- Module List (only KERNEL32.DLL) ---
Module: KERNEL32.DLL
File Time Stamp: 30/11/1999 12.06
Link Time Stamp: 21/07/1999 0.19
File Size: 83.248
File Ver : 4.0.1381.300
...
Product Ver: 4.0.1381.300
Image Ver: 4.0
Linker Ver: 3.10
OS Ver: 4.0
Subsystem Ver: 4.0


Not found of GetLongPathNameW function.

Addon: Just found the following remark in the MSDN description of GetLongPathName:

Windows NT and Windows 95: Include an additional header file called NewAPIs.h to make GetLongPathName available on these operating systems. The function is not implemented natively, but by a wrapper that utilizes other native functions on these systems. See the header file for details of the use of preprocessor directives that make the function available. If you do not have this header file, it can be obtained by downloading the most recent SDK from the SDK Update Site.

Thank for hint.

The include file NewAPIs.h in MVC2005 is present in directory .\Microsoft Visual Studio 8\VC\PlatformSDK\Include.

Look into NewAPIs.h header:
/*
* Copyright (c) 1997-2004, Microsoft Corporation
*
* Wrapper module that "stubs" APIs that were not implemented
* on Windows 95 or Windows NT versions less than 4.0 SP 3.
*
* By using this header, your code will run on older platforms.
*
* To enable a particular wrapper, define the corresponding symbol.
*
* Function Symbol
*
* GetDiskFreeSpaceEx WANT_GETDISKFREESPACEEX_WRAPPER
* GetLongPathName WANT_GETLONGPATHNAME_WRAPPER
* GetFileAttributesEx WANT_GETFILEATTRIBUTESEX_WRAPPER
* IsDebuggerPresent WANT_ISDEBUGGERPRESENT_WRAPPER
*
* Exactly one source file must include the line
*
* #define COMPILE_NEWAPIS_STUBS
*
* before including this file.
*
*/
....

Then i try at insert:

#define COMPILE_NEWAPIS_STUBS
#define WANT_GETLONGPATHNAME_WRAPPER
#include

but "... entry point GetLongPathNameW in Kernel32.dll". (!!!!!@#?^|$%... sorry)


Look function GetLongPathName.

...
*****************************************************************************
*
* GetLongPathName
*
*****************************************************************************/

#ifdef WANT_GETLONGPATHNAME_WRAPPER

#include

#undef GetLongPathName
#define GetLongPathName _GetLongPathName

extern DWORD (CALLBACK *GetLongPathName)(LPCTSTR, LPTSTR, DWORD);

/*
* Exactly one file should define this symbol.
*/
#ifdef COMPILE_NEWAPIS_STUBS

/*
* The version to use if we are forced to emulate.
*/
static DWORD WINAPI
Emulate_GetLongPathName(LPCTSTR ptszShort, LPTSTR ptszLong, DWORD ctchBuf)
{
LPSHELLFOLDER psfDesk;
HRESULT hr;
LPITEMIDLIST pidl;
TCHAR tsz[MAX_PATH]; /* Scratch TCHAR buffer */
DWORD dwRc;
LPMALLOC pMalloc;

/*
* The file had better exist. GetFileAttributes() will
* not only tell us, but it'll even call SetLastError()
* for us.
*/
if (GetFileAttributes(ptszShort) == 0xFFFFFFFF) {
return 0;
}

/*
* First convert from relative path to absolute path.
* This uses the scratch TCHAR buffer.
*/
dwRc = GetFullPathName(ptszShort, MAX_PATH, tsz, NULL);
if (dwRc == 0) {
/*
* Failed; GFPN already did SetLastError().
*/
} else if (dwRc >= MAX_PATH) {
/*
* Resulting path would be too long.
*/
SetLastError(ERROR_BUFFER_OVERFLOW);
dwRc = 0;
} else {
/*
* Just right.
*/
hr = SHGetDesktopFolder(&psfDesk);
if (SUCCEEDED(hr)) {
ULONG cwchEaten;

#ifdef UNICODE
#ifdef __cplusplus
hr = psfDesk->ParseDisplayName(NULL, NULL, tsz,
&cwchEaten, &pidl, NULL);
#else
hr = psfDesk->lpVtbl->ParseDisplayName(psfDesk, NULL, NULL, tsz,
&cwchEaten, &pidl, NULL);
#endif
#else
WCHAR wsz[MAX_PATH]; /* Scratch WCHAR buffer */

/*
* ParseDisplayName requires UNICODE, so we use
* the scratch WCHAR buffer during the conversion.
*/
dwRc = MultiByteToWideChar(
AreFileApisANSI() ? CP_ACP : CP_OEMCP,
0, tsz, -1, wsz, MAX_PATH);
if (dwRc == 0) {
/*
* Couldn't convert to UNICODE. MB2WC uses
* ERROR_INSUFFICIENT_BUFFER, which we convert
* to ERROR_BUFFER_OVERFLOW. Any other error
* we leave alone.
*/
if (GetLastError() == ERROR_INSUFFICIENT_BUFFER) {
SetLastError(ERROR_BUFFER_OVERFLOW);
}
dwRc = 0;
} else {
#ifdef __cplusplus
hr = psfDesk->ParseDisplayName(NULL, NULL, wsz,
&cwchEaten, &pidl, NULL);
#else
hr = psfDesk->lpVtbl->ParseDisplayName(psfDesk, NULL, NULL,
wsz, &cwchEaten, &pidl, NULL);
#endif
#endif

if (FAILED(hr)) {
/*
* Weird. Convert the result back to a Win32
* error code if we can. Otherwise, use the
* generic "duh" error code ERROR_INVALID_DATA.
*/
if (HRESULT_FACILITY(hr) == FACILITY_WIN32) {
SetLastError(HRESULT_CODE(hr));
} else {
SetLastError(ERROR_INVALID_DATA);
}
dwRc = 0;
} else {
/*
* Convert the pidl back to a filename in the
* TCHAR scratch buffer.
*/
dwRc = SHGetPathFromIDList(pidl, tsz);
if (dwRc == 0 && tsz[0]) {
/*
* Bizarre failure.
*/
SetLastError(ERROR_INVALID_DATA);
} else {
/*
* Copy the result back to the user's buffer.
*/
dwRc = lstrlen(tsz);
if (dwRc + 1 > ctchBuf) {
/*
* On buffer overflow, return necessary
* size including terminating null (+1).
*/
SetLastError(ERROR_INSUFFICIENT_BUFFER);
dwRc = dwRc + 1;
} else {
/*
* On buffer okay, return actual size not
* including terminating null.
*/
lstrcpyn(ptszLong, tsz, ctchBuf);
}
}

/*
* Free the pidl.
*/
if (SUCCEEDED(SHGetMalloc(&pMalloc))) {
#ifdef __cplusplus
pMalloc->Free(pidl);
pMalloc->Release();
#else
pMalloc->lpVtbl->Free(pMalloc, pidl);
pMalloc->lpVtbl->Release(pMalloc);
#endif
}
}
#ifndef UNICODE
}
#endif
/*
* Release the desktop folder now that we no longer
* need it.
*/
#ifdef __cplusplus
psfDesk->Release();
#else
psfDesk->lpVtbl->Release(psfDesk);
#endif
}
}
return dwRc;
}

/*
* The stub that probes to decide which version to use.
*/
static DWORD WINAPI
Probe_GetLongPathName(LPCTSTR ptszShort, LPTSTR ptszLong, DWORD ctchBuf)
{
HINSTANCE hinst;
FARPROC fp;
DWORD dwRc;
DWORD (CALLBACK *RealGetLongPathName)(LPCTSTR, LPTSTR, DWORD);

hinst = GetModuleHandle(TEXT("KERNEL32"));
#ifdef UNICODE
fp = GetProcAddress(hinst, "GetLongPathNameW");
#else
fp = GetProcAddress(hinst, "GetLongPathNameA");
#endif

if (fp) {
*(FARPROC *)&RealGetLongPathName = fp;
dwRc = RealGetLongPathName(ptszShort, ptszLong, ctchBuf);
if (dwRc || GetLastError() != ERROR_CALL_NOT_IMPLEMENTED) {
GetLongPathName = RealGetLongPathName;
} else {
GetLongPathName = Emulate_GetLongPathName;
dwRc = GetLongPathName(ptszShort, ptszLong, ctchBuf);
}
} else {
GetLongPathName = Emulate_GetLongPathName;
dwRc = GetLongPathName(ptszShort, ptszLong, ctchBuf);
}

return dwRc;

}

DWORD (CALLBACK *GetLongPathName)(LPCTSTR, LPTSTR, DWORD) =
Probe_GetLongPathName;

#endif /* COMPILE_NEWAPIS_STUBS */
#endif /* WANT_GETLONGPATHNAME_WRAPPER */
...

Make sure to have these lines after every other window-API related includes! I.e.

Will not work, due to stupid macro-hackery inside the NewAPIs header.

HTH,
Pat.

Move up BLOCK in stdafx.h, now:

------------------ start stdafx.h
#pragma once

#ifndef _SECURE_ATL
#define _SECURE_ATL 1
#endif

#ifndef VC_EXTRALEAN
#define VC_EXTRALEAN
#endif

#ifndef WINVER
#define WINVER 0x0501
#endif

#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0501
#endif

#ifndef _WIN32_WINDOWS
#define _WIN32_WINDOWS 0x0410
#endif

#ifndef _WIN32_IE
#define _WIN32_IE 0x0600
#endif

#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS

#define _AFX_ALL_WARNINGS

///<<<<<<<<<<<<<<<<<<<<<<< BLOCK in new position
#define COMPILE_NEWAPIS_STUBS
#define WANT_GETLONGPATHNAME_WRAPPER
#include
///<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

#include
#include

#include

#ifndef _AFX_NO_OLE_SUPPORT
#include
#endif
#ifndef _AFX_NO_AFXCMN_SUPPORT
#include
#endif // _AFX_NO_AFXCMN_SUPPORT

#ifdef _UNICODE
#if defined _M_IX86
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")
#elif defined _M_IA64
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='ia64' publicKeyToken='6595b64144ccf1df' language='*'\"")
#elif defined _M_X64
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"")
#else
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
#endif
#endif
------------------ end stdafx.h


Rebuil all and generate Compiler ERROR.

1>------ Inizio generazione: Progetto: PV_SerTFT, Configurazione: Release Win32 ------
1>Compilazione in corso...
1>stdafx.cpp
1>D:\Programmi\Microsoft Visual Studio 8\VC\atlmfc\include\afxv_w32.h(16) : fatal error C1189: #error : WINDOWS.H already included. MFC apps must not #include


What can I do ?

It seems to compile for me when i don't include the lines in stdafx.h but directly in the .cpp file i want to use those functions in.

Well, beside a weird method declaration error, claiming that:

c:\Programme\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\NewAPIs.h(325) : error C2440: '=': 'BOOL (__stdcall *)(LPCTSTR,LPTSTR,DWORD)' kann nicht in 'DWORD (__stdcall *)(LPCTSTR,LPTSTR,DWORD)' konvertiert werden
Diese Konvertierung erfordert einen reinterpret_cast-Operator oder eine Typumwandlung im C- oder Funktionsformat

I daresay, you might add a cast to the header file but usually that is a BAD IDEA (TM).

Problem NOT solved.
Any info http://www.codeguru.com/forum/showthread.php?t=391283