My program which worked with everything prior to Windows 7, no longer starts up, giving an error message of "failed to locate the procedure entry point NetApiBufferAllocate in netutils.dll". netutils.dll is also a proprietary dll, however there
are no references to NetApiBufferAllocate anywhere in its code (there are plenty of references to NetApiBufferFree however). Netutils is relying on netapi32.dll, which has changed with Windows 7. With XP and Vista, netapi32.dll was 300+ KB, in Windows 7 its
size has been reduced to 55.5 KB.
I have verified that if I place an older version of netapi32.dll in Win7's system32 folder that my program works again (either from Vista or XP). I can also place such a version in the same directory as my own program and not replace Win7's version,
and that will allow my program to work -- but unfortunately, I can't repackage different versions of netapi32.dll around, it's MS's dll after all.
I've tried looking for docs on winapi32.dll and for NetApiBufferAllocate, but there doesn't seem to be any references to changes introduced in Win7. Any ideas would be appreciated.
EDIT: Upon doing some more research, I did a wildcard search for Net*Enum, since evidently some functions like NetGroupEnum allocate memory which must be freed by NetApiBufferFree, and what I came up with:
In my program: no matches (there are three references to NetApiBufferFree however)
In Netutils: calls to 1) NetLocalGroupEnum, 2) WNetOpenEnum, 3) WNetEnumResource, 4) WNetCloseEnum
And again, there are plenty of NetApiBufferFree calls in netutils, but no actual calls to NetApiBufferAllocate :/
Netutils.dll is also the name of a new system32 file included in Windows 7. The 7 version of Netapi32.dll has a dependency upon it to import, amongst other things, NetApiBufferAllocate. No doubt your dll is already loaded and the Windows loader has matched
up netapi32's exports to your netutils.dll instead of the one from system32.
The easiest way around it is to change the name of your dll. That may not be feasible for a number of reasons, but since netapi32.dll isn't a
known dll the only other way around it I can see involves a lot of meddling the delay-loading functionality of Visual Studio. Of course if you keep the names the same and any
code (either yours or MS's) calls GetModuleHandle("netutils.dll") it's unspecified which of the two will be returned which could cause all manner of weird bugs.