Hi,
is there any documented or undocumented maximum length of the dbcc_name and dbcp_name they can have e.g. something like file objects can have MAX_PATH maximum length of charcaters. Is there anything like that?
K.
Why?
d
debt from my phone
From: xxxxx@arcor.de
Sent: 5/14/2012 7:02 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Max len of DEV_BROADCAST_PORT:dbcp_name and DEV_BROADCAST_DEVICEINTERFACE:dbcc_name
Hi,
is there any documented or undocumented maximum length of the dbcc_name and dbcp_name they can have e.g. something like file objects can have MAX_PATH maximum length of charcaters. Is there anything like that?
K.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>Why?
Because i use the .NET Framework and there is no explicit managed “wchar_t dbcc_name[1]” equivalent to it. I can use unsafe context to access that information or i can use something like:
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 255)]
public String dbcp_name;
or
public IntPtr dbcp_name;
The first variant would be the preferred version, so i can totally skip the unsafe context. The second is managed too, but i have to walk the buffer until i get a “\0”, but the first SizeConst version would be the best and fastest.
K.
xxxxx@arcor.de wrote:
> Why?
Because i use the .NET Framework and there is no explicit managed “wchar_t dbcc_name[1]” equivalent to it. I can use unsafe context to access that information or i can use something like:[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 255)]
public String dbcp_name;
or
public IntPtr dbcp_name;The first variant would be the preferred version, so i can totally skip the unsafe context. The second is managed too, but i have to walk the buffer until i get a “\0”, but the first SizeConst version would be the best and fastest.
There’s no way to win here. The size is given by dbcp_size earlier in
the structure, so there doesn’t have to be a defined limit. The IntPtr
option isn’t right – it’s not a pointer to the characters, but rather
the actual characters themselves.
The marshalling doesn’t allocate any memory, so you might as well use
SizeConst=65535 and not worry about it.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>The marshalling doesn’t allocate any
memory, so you might as well use SizeConst=65535 and not worry about it.
Thanks for the answer. But if you have complex structures and the runtime encounters internal limitations on structures size and data you will get a MarshalDirectiveException (so do i) in the case the SizeConst is a huge value like 65535. I also found the length “255” documented on the pinvoke website, but 8192 works fine for me here ranging from W2K to Win8, i also see any sense in having longer names here:
http://www.pinvoke.net/default.aspx/Structures/DEV_BROADCAST_PORT.html
The IntPtr option isn’t right – it’s not a pointer to the characters, but rather the actual characters
themselves.
If this is the case (as it seems by code usage and raw memory analyse), then the documentation is wrong here:
From MSDN:
“A pointer to a null-terminated string specifying the friendly name of the port or the device connected to the port”
Variable length structiures always have been some problematic issue here from C to C#. One either works with structure offsets or with pointers or in this case with fixed lenghts. Too bad the .NET marshaler doesnt support structures with variable length size :-(. Mostly you have to implement your own access mechnism with self-made classes e.g. by using Marshal.OffsetOf() or by various raw memory copy and conversion functions.
xxxxx@arcor.de wrote:
> The marshalling doesn’t allocate any
> memory, so you might as well use SizeConst=65535 and not worry about it.
Thanks for the answer. But if you have complex structures and the runtime encounters internal limitations on structures size and data you will get a MarshalDirectiveException (so do i) in the case the SizeConst is a huge value like 65535. I also found the length “255” documented on the pinvoke website, but 8192 works fine for me here ranging from W2K to Win8, i also see any sense in having longer names here:
65,535 is hardly “huge”. I don’t understand why there would be an
exception; this is not allocating any memory. It is merely telling the
managed subsystem exactly how the unmanaged memory is laid out. In this
case, the only purpose for that number is to enable the runtime to do
validation on the array subscript. However, whatever works…
The IntPtr option isn’t right – it’s not a pointer to the characters, but rather the actual characters
themselves.
If this is the case (as it seems by code usage and raw memory analyse), then the documentation is wrong here:From MSDN:
“A pointer to a null-terminated string specifying the friendly name of the port or the device connected to the port”
The documentation is wrong. It’s not a pointer. This is a variable
length structure. The string itself begins at dbcp_name. If you read
the documentation for ByValTStr, you’ll see that’s what it defines.
I’ll put a note on the web page.
Variable length structiures always have been some problematic issue here from C to C#. One either works with structure offsets or with pointers or in this case with fixed lenghts
Absolutely (and critically) true. In fact, this is the primary issue
that has kept me from becoming a complete C# convert. In our line of
work, we constantly find ourselves parsing weird structures from
drivers, or handling odd data types read in from files, or writing
arbitrary data structures to other places, and those kinds of things are
ugly, tedious, error-prone, and slow in C#. I would rather work in
Python with the “struct” module then write up all that code to marshal
fields back and forth.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.