The first reason is causing more efforts for apps. Nearly all apps I know have hard-coded the DLL file name, wpcap.dll by implicitly linking the .lib or LoadLibrary call. If I changed this name, all apps will need modification for NPcap. LoadLibrary is easy to change, just add another file name for its argument, but changing the implicit linking to NPcap will be much more pain, needs changing the SDK, changing the SDK means to give up WinPcap, and even NPcap don't have a SDK yet, he has to compile with NPcap from source. I don't see any softwares except Wireshark and nmap would like to do this for NPcap. Because as you said, WinPcap can still work under Win10, there's no indispensable reason for other apps to do that much for NPcap.
Second reason is that from what I see, most apps use the Windows DLL search order, while I didn't test much, but at least nmap and WinDump does. Only Wireshark has hard-coded DLL folder for now. Perhaps system32 is a "standard" way we know to put DLLs, however using another DLL path and adding it to Environment Variable %PATH% is also a "standard" way, it's not less secure than system32 way because a user needs Administrator right to modify machine-wide options in Environment Variable. You may think that a malicious user can mess with his own user-wide options, adding some malicious path to his own %PATH%, but in that condition Wireshark will probably also run under that user (Non-administrator right). So still no harm to the Administrator-protected resources. Of course, if the malicious user is an Administrator, he can do whatever he wants, including modifying Environment Variable and messing with system32.
BTW, I found that apps all like to hard-coded some names in WinPcap. Nmap and Wireshark hard-coded the "npf.sys" driver name, Wireshark even hard-coded the adapter binding name (like "\Device\NPF_{XXXX}", but we have changed it to "\Device\NPCAP_{XXXX}"). I have changed this adapter binding name back to "NPF" for compatibility, but the driver name NPcap uses is "npcap.sys" and cannot be changed back to "npf.sys", because driver names are system-global. So I think the logic checking "npf.sys" in Wireshark also needs some change.
Cheers,
Yang
