The problem:
- switch the new Excel’s FileOpen window to “My Computer”, then hit our mapped
network drive serviced by our NP DLL. - nothing happens, instead of a message box of “Operation completed normally”.
The dialog does not go down next level. - the usual Windows FileOpen box (like Notepad) works fine.
This is the only known bug in our NP DLL. All other functionality works fine -
Explorer, NET USE and so on. The redirector itself is not at guilt - no files
are opened on it in the process, the whole process is working with NETRESOURCEs
in user mode only.
I have checked our NP DLL to behave exactly the same as NTLANMAN.DLL in terms
of NETRESOURCES returned. I have monitored all calls made by the FileOpen
dialog to the NP DLLs. All work fine and the same.
The detailed examination resulted in different SFGAOF flags returned by
IShellFolder::GetAttributesOf. Looks like Windows’ standard box is more
permittable on these flags, while the Excel’s one is not such.
So, the root cause is - how SHELL32 builds IShellFolder on top of the mapped
network drive letter serviced by the NP DLL, and on what the SFGAOF flag are
dependent? The only calls to NP DLL from the shell are NPGetConnection and
connected disk resource enumeration. All work the same for both our DLL and
NTLANMAN.DLL.
No new fancy functions of NTLANMAN are called. The Terminal Services
redirector’s NP DLL works fine in Excel.
Have anybody experienced the same?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com