Should DWORD map to int or uint?

Question

When translating the Windows API (including data types) into P/Invoke, should I replace DWORD with int or uint?

It's normally unsigned, but I see people using int everywhere instead (is it just because of the CLS warning? even the .NET Framework itself does this), and so I'm never really sure which one is the correct one to use.

Privet

Answer 1

Well according to the MSDN DWORD is an unsigned integer with a range of 0 to 4294967295.

So ideally you should replace it with uint rather than int.

However, as you have spotted uint is non-CLS compliant so if your method is publicly visible you should use int and do the conversion. The corollary to that is that if your method isn't used outside your assembly you should mark it as internal rather than public. Then you'll be able use a uint.

Brazee

I guess what worries me is that it's (1) inconsistent with the framework, and (2) non-CLS-compliant. Should I just ignore that? – Privet

Answer 2

It's unsigned so map it to uint.

Istic

Answer 3

A DWORD is, by (Microsoft's) definition, an unsigned 32-bit integer. It should map to whichever type your compiler uses to represent that.

These days it's most likely an unsigned int, but that's not a portable implementation. I know you're using C#, but to give you an example in a language I'm more familiar with, a typical implementation in C might be:

#if defined(SOME_HARDWARE_IMPLEMENTATION)
#define DWORD unsigned int
#elif #defined(SOME_OTHER_IMPLEMENTATION)
#define DWORD unsigned long
#elif #defined(YET_ANOTHER_IMPLEMENTATION)
#define DWORD something_else
#else
#error Unsupported hardware; cannot map DWORD
#endif

Laundress

However, in C#, uint and int are 32-bit integers. You are correct, though, that in C, primitive data types such as int and long are not consistent between compilers. This, however, will only be an issue here if DWORD is used in a function or API not defined by Microsoft, where by its definition, DWORD is a 32-bit unsigned integer. – Chengteh

C int and long are always 32 bit on windows – Istic

Answer 4

The CLS compliance warning applies only if the P/Invoke method is visible outside the assembly, which generally means the call is public. If the method is not externally visible, then it is acceptable to use uint.

Chengteh

Answer 5

Use int. Reason being, if I change "AutoRestartShell" with a uint variable:

regKey.SetValue("AutoRestartShell", uintVariable);

the data type in the Registry Editor changes to "REG_SZ". If I ask for that value to be returned with:

regKey.GetValue("AutoRestartShell");

a string gets returned.

If, however, I change "AutoRestartShell" with an int variable:

regKey.SetValue("AutoRestartShell", intVariable);

The data type stays as "REG_DWORD".

Why does this happen? No idea. All I know is that it does. Logic certainly would tell us that uint should be used but that changes the data type which we don't want.

Manns

How does the behaviour or a completely unrelated part of .NET relate to marshalling a WinApi type? – Shabbir

For the same reason that two apps cannot communicate with each other by one sending integers where the other expects strings and vice versa. As for whether or not uint or int would make an actual difference here, I don't know. It was just an observation. I figured it was best to not change what doesn't need to be changed. – Manns

It looks like the culprit is the private CalculateValueKind method. It simply doesn't acknowledge uint, but also doesn't know short or other numeric types. But I see the point - public API should handle CLS-compliant types more importantly than non-CLS-compliant types. The CLR actually doesn't differentiate between an int and uint. – Shabbir

Answer 6

According to official Platform invoke data types mapping table DWORD corresponds to System.UInt32 in C#.

Visitor

Answer 7

Sadly,read Registry must use int otherwise throw exception.this microsoft code:

private static void Get45or451FromRegistry()
{
    using (RegistryKey ndpKey = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry32).OpenSubKey("SOFTWARE\\Microsoft\\NET Framework Setup\\NDP\\v4\\Full\\")) {
        if (ndpKey != null && ndpKey.GetValue("Release") != null) {
            Console.WriteLine("Version: " + CheckFor45DotVersion((int) ndpKey.GetValue("Release")));
        }
      else {
         Console.WriteLine("Version 4.5 or later is not detected.");
      } 
    }
}

although release is REG_DWORD

Flowerdeluce