The historical perspective is interesting. But…
If the header tells me there will be Length bytes at Buffer, and implies
that none of those bytes will have the value zero, then I might write a
bunch of code that, “from an implementation standpoint” would ultimately
fail because the Buffer in fact contains quite a few null bytes. Like
using _str… functions, or DbgPrint with %s instead of %S, or calling
RtlAnsiStringToUnicodeString.
Saying that “\0F\0o\0o” is a six-byte character string is too blatant
a defiance of convention for me to accept it. I’ve never noticed any
effort to get developers to treat [UNICODE_|ANSI_]STRING Buffers as
opaque.
So, if what Curt says is true, I’d argue that ntifs.h is wrong.
Dave Cox
Hewlett-Packard Co.
HPSO/SSMO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox
-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Wednesday, June 21, 2000 10:08 PM
To: File Systems Developers
Subject: [ntfsd] RE: Redux: IO_STACK_LOCATION.Parameters.QueryDirectory
st ruct members
Curt,
From an implementation standpoint, a counted byte string is
indistinguishable from a counted unicode string. That is because the Length
and MaximumLength fields (for both STRING and UNICODE_STRING) indicate the
number of BYTES.
Thus, it is operationally impossible to distinguish the string “\0F\0o\0o”
and the wide character string L"Foo" (assuming each is counted based upon
the number of bytes.) So, that would indicate it is more likely the case
that we have a “doesn’t matter”.
This is more an historical oddity than anything sinister or important - the
decision to go with 16 bit unicode in the file systems interface was clearly
one that was not made “at the beginning” and instead evolved over time.
Practically speaking there is only one place where you must handle 8-bit
characters: the names of extended attributes.
Thus, I’d argue that both ntifs.h and Windows 2000 are correct and
consistent with respect to one another.
Regards,
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:
-----Original Message-----
From: xxxxx@omnishift.com [mailto:xxxxx@omnishift.com]
Sent: Thursday, June 22, 2000 12:56 AM
To: File Systems Developers
Subject: [ntfsd] Redux: IO_STACK_LOCATION.Parameters.QueryDirectory struct
members
Hi:
In late May, xxxxx@Satyam.com asked about the nature of the structure
members of the QueryDirectory Parameters structure in the IO stack location.
(This isn’t documented in the DDK headers, only in the IFS header.) It
doesn’t appear to me that this was ever answered.
Rajeev Nagar’s book shows the FileName parameter as a “PSTRING” (counted
single-byte string), and, now that I have the W2000 IFS kit, ntifs.h shows
the same type.
However, on W2000, I’ve observed empirically that the FileName is a
PUNICODE_STRING, and using it like this has been working for me.
So: Is the ntifs.h file wrong, at least for W2000?
Thanks,
Curt
—
You are currently subscribed to ntfsd as: david_cox2@hp.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)</http:>