Mombu the Microsoft Forum sponsored links

Go Back   Mombu the Microsoft Forum > Microsoft > WINDOWS PROGRAMMING (NNTP) > VS2005 and NT4
User Name
Password
REGISTER NOW! Mark Forums Read

sponsored links


Reply
 
1 23rd August 20:17
heike vollmer
External User
 
Posts: 1
Default VS2005 and NT4


Hi,

I'm really annoyed about what MS did with VS2005 regarding NT4:

this infamous GetLongPathNameW-import symbol is something absolutely
useless.

We have to support all platforms (including NT4). We also (of course)
want to shift to VS2005 but we don't feel like having to maintain our
EXEs with two different build environments, i.e. VC6 for NT4 and VS2005
for all successors.

Is there any way to intercept the import of GetLongPathNameW and replace
that thing with an "home-made" version of equivalent code?

I know MS does wants us to force to not support NT4 any more, but a
large scale of customers still use this platform and they want to
upgrade only for MS`s money sake.
  Reply With Quote


  sponsored links


2 23rd August 20:17
heike vollmer
External User
 
Posts: 1
Default VS2005 and NT4


Hi,

I'm really annoyed about what MS did with VS2005 regarding NT4:

this infamous GetLongPathNameW-import symbol is something absolutely
useless.

We have to support all platforms (including NT4). We also (of course)
want to shift to VS2005 but we don't feel like having to maintain our
EXEs with two different build environments, i.e. VC6 for NT4 and VS2005
for all successors.

Is there any way to intercept the import of GetLongPathNameW and replace
that thing with an "home-made" version of equivalent code?

I know MS does wants us to force to not support NT4 any more, but a
large scale of customers still use this platform and they do not want to
upgrade only for MS`s money sake.
  Reply With Quote
3 23rd August 20:17
carl woodward
External User
 
Posts: 1
Default VS2005 and NT4


Well, there are several things that you could do (assuming I understood your
post):

1. Hook the IAT entry for GetLongPathNameW for each of your modules and
replace it with an identically prototyped routine that calls
kernel32!GetLongPathNameW if OS > NT4 or executes bespoke code if OS == NT4.
2. Retrieve the address of GetLongPathNameW dynamically using
GetProcAddress and use a function pointer instead. If OS > NT4 then your
function pointer would point to kernel32!GetLongPathNameW. If OS == NT4 have
the function pointer point to your custom implementation of
GetLongPathNameW. This means that you would always be calling a function
pointer and the function pointer would either be to
kernel32!GetlongPathNameW or custom code depending on the OS.

Hope that helps,

Carly
  Reply With Quote
4 23rd August 20:17
heike vollmer
External User
 
Posts: 1
Default VS2005 and NT4


Hi Carly,

thanks for your hints!

Unfortunatelly both of them won't work :-(


IAT hooking came to my mind early, but: GetLongPathNameW is referenced
from within the DLL-init-code of msvcrt80.dll.

So the loader tries to resolve the import even before a oiece of code of
mine gets the chance of executing .... or am I wrong?

So the only way would be to somehow tell the loader to replace the
reference to above symbol with one of my symbols.

Is that feasible, at all?
  Reply With Quote
5 25th August 05:32
carl woodward
External User
 
Posts: 1
Default VS2005 and NT4


Hi Helke,

Here is one possible solution for you. I assume from your post that you are
redistributing MSVCRT80.DLL with your binaries. I dont think that MSVCRT80
is designed to work on NT4. But, if I understand your predicament correctly
you could try the following:

Change the CRT linkage in "Configuration Properties", "C\C++", "Code
Generation", "Runtime Library" to "Multi-Threaded (\MT)" from
"multi-threaded DLL (\MD)". Your binary will be bigger ofcourse, but the
static library does not use GetLongPathNameW so your problem should go away

Hope that helps,

Carly
  Reply With Quote
6 25th August 19:42
chl
External User
 
Posts: 1
Default VS2005 and NT4


hmmm.... Windows NT is listed on

http://msdn2.microsoft.com/en-us/library/ws0swas0.aspx

"The C run-time libraries support Windows 98, Windows Me, Windows NT, Windows 2000, Windows XP, and Windows Server 2003, ..."


Can anybody clarify?
  Reply With Quote
7 26th August 10:07
carl woodward
External User
 
Posts: 1
Default VS2005 and NT4


One clarification coming up...

The C runtime library will work on NT, but MSVCR80.dll is not just a CRT. It
is a dll which contains the crt, but also has a bunch of extra code in
there, GetLongPathNameW being an import of this extra code. If you look at
the the static lib file, msvrt.lib, GetLongPathNameW is not imported. It is
for this reason that I speculated that using the static lib might work on
NT4.

It also worth noting that there are several crts. The web do***ent you link
to does not specify which crt. I suspect that it means the crt in
msvcrt.dll. if you were to convince VS2005 to link to msvcrt.dll instead (as
VC6 will) then yes, the binary would definately work on NT4. This may not be
the case if you dynamically or statically link to the VC8 crt, it may
require features of the OS that aren't present on earlier platforms.

Hope that helped,

Carly
  Reply With Quote


  sponsored links


Reply


Thread Tools
Display Modes




Copyright 2006 SmartyDevil.com - Dies Mies Jeschet Boenedoesef Douvema Enitemaus -
666