VS2005 and NT4
in [Win32 API]
|
Prev: eject cd?
Next: how to find source of conflicting dll
From: Heike Vollmer on 22 Aug 2006 05:52 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.
From: Carl Woodward on 22 Aug 2006 06:12 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 "Heike Vollmer" <HeiVom(a)onlineNOSPAM.de> wrote in message news:44ead3ae$0$484$bfcc4b32(a)reader.news.celox.de... > 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.
From: Heike Vollmer on 22 Aug 2006 08:52 > 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 > 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?
From: Carl Woodward on 24 Aug 2006 21:12 "Heike Vollmer" <HeiVom(a)onlineNOSPAM.de> wrote in message news:44eafe18$0$481$bfcc4b32(a)reader.news.celox.de... >> 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 >> > 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? 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
From: chl on 25 Aug 2006 04:53
"Carl Woodward" <no(a)way.com> wrote in message news:58sHg.21954$oa4.19480(a)newsfe1-gui.ntli.net... > > redistributing MSVCRT80.DLL with your binaries. I dont think that MSVCRT80 is designed to work on NT4. But, if I understand your > predicament correctly 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? |