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

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

Any support for creating UNICODE_STRINGs more easily?

Michael_RolleMichael_Rolle Member - All Emails Posts: 135

I want to do a simple thing like make a symbolic link containing a decimal number supplied at run time.
It seems that I have to allocate a buffer (nonpaged or paged, depending on the situation), set a UNICODE_STRING structure to point to the buffer and its length, then use something like RtlUnicodeStringVPrintf (destination, format, my number), then later I have to free the buffer. I also have to figure out how big to make the buffer.
Now all you people have been writing drivers for so many years, do you have to go through all this stuff every time, or is there something you use that makes this easier and less error-prone?
The KMDF String object looks like it might help a bit, but it doesn't seem to be something that can just grow its buffer to accommodate whatever I might want to put into it, and also know to release the buffer when it gets deleted.
Anyone found a way of simplifying this work???

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,914
    via Email
    On Feb 16, 2019, at 11:29 PM, Michael_Rolle wrote:
    >
    > I want to do a simple thing like make a symbolic link containing a decimal number supplied at run time.
    >
    > It seems that I have to allocate a buffer (nonpaged or paged, depending on the situation), set a UNICODE_STRING structure to point to the buffer and its length, then use something like RtlUnicodeStringVPrintf (destination, format, my number), then later I have to free the buffer. I also have to figure out how big to make the buffer.
    >
    > Now all you people have been writing drivers for so many years, do you have to go through all this stuff every time, or is there something you use that makes this easier and less error-prone?
    > ...
    > Anyone found a way of simplifying this work???

    Nope. Kernel drivers just don't do very much string processing, and have to be very explicit about memory management.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Michael_RolleMichael_Rolle Member - All Emails Posts: 135

    Pity, :'(, not just for myself, but for everyone else. But thanks for confirming my fears.

  • Don_BurnDon_Burn Member - All Emails Posts: 1,649
    via Email
    Actually, if you know the string size and it is not too long (like the symbolic link example you gave) just use DECLARE_UNICODE_STRING_SIZE() to create a local variable, then use RtlUnicodeStringVPrintf. Doron wrote about a number of these macros at https://blogs.msdn.microsoft.com/doronh/2006/02/27/how-to-correctly-initialize-a-unicode_string/ plus there is the old standby RTL_CONSTANT_STRING() which can be used to initialize a global to a constant string.

    UNICODE_STRING's do take a little more work than "C" strings, but not as much as so many of the old crufty samples do.


    Don Burn
    Windows Driver Consulting
    Website: http://www.windrvr.com
  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 182
    via Email
    "Grow buffer on demand and elease when it gets deleted" looks like a
    "I want the bad C++ stuff in the driver" :) I have a new colleague
    right now, who wants C++ exceptions in the drivers, so he need not
    free the local variables himself ;) (no, he is not allowed to touch
    any driver code for the next 2 years, I do not trust him to create a
    driver that just fails to load and nothing else :))

    You have to create your own function, which will check whether
    allocations failed, etc. and return error codes, rather than strings.

    File systems and filters do a heck of a lot of string manipulation,
    and we have to do that - create string handling APIs for our own
    purposes.


    On 2/17/19, Michael_Rolle wrote:
    > The KMDF String object looks like it might help a bit, but it doesn't seem
    > to be something that can just grow its buffer to accommodate whatever I
    > might want to put into it, and also know to release the buffer when it gets
    > deleted.
  • RourkeRourke Member Posts: 18

    If you do a lot of drivers, protocols, and APIs you'll encounter a surprising variety of strings types:

    • fixed length single byte strings (eg: UCHAR String[10])
    • fixed length double byte strings (eg: WCHAR String[10])
    • counted single byte strings
    • counted double byte strings
    • 0 terminated single byte strings (c string)
    • 0 terminated double byte strings
    • ANSI_STRING containers
    • UNICODE_STRING containers

    Unfortunately too often the need arises where you'll have to translate these from one type to another or manipulate them especially in the virtual world of things. I'm not a fan of long goofy macros in all caps in source code. They are ugly, illogical so the reader/implementer has to look them up to understand them, and what is available is very limited. We made a c++ exception free string class that allows translating between string types plus manipulating them with natural operators. It takes the headaches out of working with strings and actually makes it a joy. Mountains of source code often condenses down to a simple self readable single line of code per action. Having the ability to reuse this proven and tested class with type safety on different projects makes development a lot speedier.

    If you are doing drivers for a career, making a good string class early on might be a good investment. It certainly has been for our company.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,138

    We made a c++ exception free string class that allows translating between string types plus manipulating them with natural operators.

    Wouldn’t it be nice if you shared that with the community.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

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
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space