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/


NPFormatNetworkName

OSR_Community_UserOSR_Community_User Member Posts: 110,217
Hello All:

This is rather a question for Windows 98 as I am not aware of a list
dedicated for Windows 95/98 drivers. So, I am hoping that someone has an
answer for this apparently simple question. The question is regarding the
API NPFormatNetworkName to be implemented in network provider DLL. The API
has the form:

NPFormatNetworkName(LPWSTR lpRemoteName, LPWSTR lpFormattedName,
LPDWORD lpnLength,DWORD dwFlags,DWORD dwAveCharPerLine)

For Windows 95, and also for the corresponding API on Windows NT/2000, if
the remote name is of form \\hostname\sharename and flag is WNFMT_INENUM,
then I simply extract the sharename from lpRemoteName and return that for
lpFormattedName. Windows then display the mapped driver as:

sharename on hostname (<driveletter>:)

However, on windows 98, windows displays it only as:

sharename (<driverletter>:)

(i.e, 'on hostname' part isn't displayed). Also, when Windows 98 calls this
API, dwAveCharPerLine is set to 0. The DDK documentation states that this
means no character limit is being applied on lpFormattedName. So what should
mean? Does Windows 98 expects me to return \\hostname\sharename for
lpFormattedName, when dwAveCharPerLine is 0, instead of just sharename? Or
am I supposed to return 'sharename on hostname'?

Thanks
Qasim

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Thanks for the information. As it turned out, Windows 98 is inconsistent
    with regard to this API when compared
    with Windows 95, NT and 2000.

    Specifically, Windows explorer behaves differently for Windows 95/NT/2000
    and Windows 98.

    Under Windows 95, NT and 2000, it is sufficient to return last component of
    the share name as lpFormattedName.
    For instance, given \\hostname\export\dir, you can only return 'dir'.
    Explorer would then display:

    'dir on hostname\export(driveletter:)'

    This is what my driver currently does. Under Windows 98, however, returing
    only 'dir' would cause Explorer to display only:

    dir (driverletter:)

    Hence, one needs to return the entire input lpRemoteName as lpFormattedName
    which would cause Windows 98 Explorer to display
    network name same as for Windows 95 etc, that is:

    'dir on hostname\export(driveletter:)'

    Doing this therefore solved the problem for me!

    Thanks
    Qasim


    -----Original Message-----
    From: Aleksandr Ryabin [mailto:[email protected]]
    Sent: Tuesday, May 16, 2000 6:30 AM
    To: Qasim Zuhair
    Cc: Aleksandr Ryabin
    Subject: Re: [ntfsd] NPFormatNetworkName


    At 10:34 PM 5/15/00 , you wrote:


    >Hello All:
    >
    >This is rather a question for Windows 98 as I am not aware of a list
    >dedicated for Windows 95/98 drivers. So, I am hoping that someone has an
    >answer for this apparently simple question. The question is regarding the
    >API NPFormatNetworkName to be implemented in network provider DLL. The API
    >has the form:
    >
    >NPFormatNetworkName(LPWSTR lpRemoteName, LPWSTR lpFormattedName,
    > LPDWORD lpnLength,DWORD dwFlags,DWORD dwAveCharPerLine)
    >
    >For Windows 95, and also for the corresponding API on Windows NT/2000, if
    >the remote name is of form \\hostname\sharename and flag is WNFMT_INENUM,
    >then I simply extract the sharename from lpRemoteName and return that for
    >lpFormattedName. Windows then display the mapped driver as:
    >
    >sharename on hostname (<driveletter>:)
    >
    >However, on windows 98, windows displays it only as:
    >
    >sharename (<driverletter>:)

    I've never seen the case when Win98 calls this API with WNFMT_INENUM set.
    It usually called with WNFMT_CONNECTION in which case Windows takes care
    of formatting it. If it did not pass to you WNFMT_INENUM you should simply
    return
    the input lpRemoteName in lpFormattedName.

    Although I've noticed that if you are given something like \\host\export\dir
    then explorer
    gets confused by multi-component share name and will show "dir on
    host\export"
    instead of expected "share\dir on host". To get around this problem you can
    change
    directory delimiter to lets say '/' that is you return in that case:
    "\\host\export/dir",
    then explorer will show "export/dir" on host".

    I hope this helps.
    Aleks


    >(i.e, 'on hostname' part isn't displayed). Also, when Windows 98 calls this
    >API, dwAveCharPerLine is set to 0. The DDK documentation states that this
    >means no character limit is being applied on lpFormattedName. So what
    should
    >mean? Does Windows 98 expects me to return \\hostname\sharename for
    >lpFormattedName, when dwAveCharPerLine is 0, instead of just sharename? Or
    >am I supposed to return 'sharename on hostname'?
    >
    >Thanks
    >Qasim
    >
    >
    >
    >
    >---
    >You are currently subscribed to ntfsd as: [email protected]
    >To unsubscribe send a blank email to $subst('Email.Unsub')

    >----------------------------------------------------------------------
    Aleksandr Ryabin
    work: [email protected] (aka [email protected])
    home: [email protected]
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