Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


RE: Searching for Computers in Windows 2000

OSR_Community_UserOSR_Community_User Member Posts: 110,217
Hello All:

I posted the following query a while ago. However, I have now resolved the
issue and thought I should share
the resolution with others as well.

The problem was in my implementation of NPGetResourceInformation.
Apparently, in Windows NT, it
is sufficient to return WN_SUCCESS for this API if we find that the resource
belongs to us.
Windows NT then treat the search operation for that resource as successful.

Windows 2000 is a bit strict about the expected behavior of this API. The
API has the form:

NPGetResourceInformation(LPNETRESOURCE lpNetResource,
LPVOID lpBuffer,LPDWORD lpBufferSize, LPWSTR *lplpSystem)

If lpNetResource is in form \\hostname, which it is when explorer is
searching for computers, and
our provider recognizes this resource, then it MUST set *lplpSystem to NULL
and set
(LPNETRESOURCE) lpBuffer->lpRemoteName to \\hostname before returning
WN_SUCCESS.

If lpNetResource is in form \\hostname\share_name, and
our provider recognizes this resource, then it MUST set *lplpSystem to NULL
and set
(LPNETRESOURCE) lpBuffer->lpRemoteName to \\hostname\share_name before
returning WN_SUCCESS.

Finally, If lpNetResource is in form \\hostname\share_name\some_dir, and
our provider recognizes this resource, then it should set *lplpSystem to
\some_dir and set
(LPNETRESOURCE) lpBuffer->lpRemoteName to \\hostname\share_name before
returning WN_SUCCESS.

If we do not follow the above behavior in Windows 2000, then search
operation is treated
as a failure.

Hope this helps
Qasim



-----Original Message-----
From: Qasim Zuhair [mailto:[email protected]]
Sent: Thursday, April 20, 2000 4:49 PM
To: File Systems Developers
Subject: [ntfsd] Searching for Computers in Windows 2000




Hello:

I am porting a network redirector/remote file system driver from Windows NT
to Windows 2000. The allows you to map network drives to a specific type of
remote systems. I am currently experiencing a problem with Search tool used
to search for computers (for instance, when you right-click on My Network
Places icon). The problem is that this tool is not able to find the systems
recognized by my network provider. The same network provider work just fine
under Windows NT when the corresponding Find tool is used. While debugging,
I noticed that NPGetResourceInformation routine of my network provider is
invoked when Search tool is used. This routine is passed the name of the
computer system being search for. The routine returns WN_SUCCESS after
successfully recognizing the passed computer system. Still, the Search tool
claims that it failed to find that computer. This happens intermittently.

Other network providers such as NWCWorkstation for Netware network and
LanmanWorkstation for Microsoft Network are always able to find the computer
in their respective networks.

Did something change for this routine in Windows 2000? Has anyone else
found this problem with W2K?

Thanks
Qasim

---
You are currently subscribed to ntfsd as: [email protected]
To unsubscribe send a blank email to $subst('Email.Unsub')
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE