hungerian notation

hi all,
I am facing one problem, While going through the WinCE code I
didn't understand many data types for example HANDLE,LP,DWORD etc
there are so many in fact...
Basically I have done some programming in linux environment so this
field(WinCE ) is very new to me . please help me out.
Thanks and regards,
prasi

Ulrich
Wed Jan 04 03:38:36 CST 2006

Note up front: it's Hungarian, with a capital letter and two 'a' and it
usually applies to identifiers not types, so your questions have nothing
really to do with it.

prasi wrote:
> I am facing one problem, While going through the WinCE code I
> didn't understand many data types for example HANDLE,LP,DWORD etc
> there are so many in fact...

HANDLE: an opaque datatype that represents various things, just like a void*
in normal C. Things it represents are files, events, mutexes, threads,
modules and probably some more.

LP: a prefix for types. The 'L' is for 'long', from the old days where there
were long and short pointers. This is obsolete now but still used often.
The 'P' then stands for pointer.

DWORD: win32 (falsely) defines a WORD to be 16bit and a DWORD (double-word)
to 32 bits accordingly. It's just an integral type, in other words. If you
want 32 bits explicitly, rather use uint32_t (C99/POSIX?) or UINT32
(win32).

TCHAR: this one you will also come across, like its relatives
LPTSTR/LPCTSTR. It resolves to either CHAR or WCHAR, depending on the
_UNICODE macro. Under CE, this macro is usually set so it becomes a WCHAR
(equivalent to wchar_t). A TCHAR string literal is obtained like
_T("text") or TEXT("text"), which then resolves to "text" or L"text",
depending on _UNICODE.
There are several related functions that are also TCHAR aware so you don't
have to assume TCHAR is either char or wchar_t, e.g. _tcscpy as replacement
for strcpy/wcscpy.

Uli

gerrit
Wed Jan 04 09:43:35 CST 2006

I have found the following to be particulary helpfull in deciphering
the windows data types.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog/winprog/windows_data_types.asp

Good luck,
gerrit


Ulrich Eckhardt wrote:
> Note up front: it's Hungarian, with a capital letter and two 'a' and it
> usually applies to identifiers not types, so your questions have nothing
> really to do with it.
>
> prasi wrote:
> > I am facing one problem, While going through the WinCE code I
> > didn't understand many data types for example HANDLE,LP,DWORD etc
> > there are so many in fact...
>
> HANDLE: an opaque datatype that represents various things, just like a void*
> in normal C. Things it represents are files, events, mutexes, threads,
> modules and probably some more.
>
> LP: a prefix for types. The 'L' is for 'long', from the old days where there
> were long and short pointers. This is obsolete now but still used often.
> The 'P' then stands for pointer.
>
> DWORD: win32 (falsely) defines a WORD to be 16bit and a DWORD (double-word)
> to 32 bits accordingly. It's just an integral type, in other words. If you
> want 32 bits explicitly, rather use uint32_t (C99/POSIX?) or UINT32
> (win32).
>
> TCHAR: this one you will also come across, like its relatives
> LPTSTR/LPCTSTR. It resolves to either CHAR or WCHAR, depending on the
> _UNICODE macro. Under CE, this macro is usually set so it becomes a WCHAR
> (equivalent to wchar_t). A TCHAR string literal is obtained like
> _T("text") or TEXT("text"), which then resolves to "text" or L"text",
> depending on _UNICODE.
> There are several related functions that are also TCHAR aware so you don't
> have to assume TCHAR is either char or wchar_t, e.g. _tcscpy as replacement
> for strcpy/wcscpy.
>
> Uli

Steve
Wed Jan 04 10:35:47 CST 2006

>>DWORD: win32 (falsely) defines a WORD to be 16bit and a DWORD
>>(double-word)
>>to 32 bits accordingly.
That is correctly not "falsely". Remember - before there was Win32 there was
Win16! Altering that definition would break all prior code. Besides there is
no industry wide absolute definition of WORD. In the old 16 bit days when
the "native machine word size" ( a term that only came along after the
concept of WORD=16 bits already existed) was 16 bits there wasn't much of a
distinction, however as 32 and 64 bit machines came along the distinction
between a 16 bit value and the native machine word size became more of an
issue. In the land of the x86 a WORD was still considered 16 bits for
historical reasons. In the RISC world WORD meant the native machine word
size. It's another one of those idiosyncratic terminology issues we face
every day as embedded developers. I recommend never using DWORD, and WORD
types myself and instead always use the size specific typedefs UINT32,
INT16, etc... the lack of native support for such size specific types in
C/C++ is a big flaw in the design of those languages in my view.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

Ulrich
Wed Jan 04 11:32:11 CST 2006

Steve Maillet (eMVP) wrote:
>>>DWORD: win32 (falsely) defines a WORD to be 16bit and a DWORD
>>>(double-word)
>>>to 32 bits accordingly.
> That is correctly not "falsely". Remember - before there was Win32 there
> was Win16! Altering that definition would break all prior code. Besides
> there is no industry wide absolute definition of WORD. In the old 16 bit
> days when the "native machine word size" ( a term that only came along
> after the concept of WORD=16 bits already existed) was 16 bits there
> wasn't much of a distinction, however as 32 and 64 bit machines came along
> the distinction between a 16 bit value and the native machine word size
> became more of an issue. In the land of the x86 a WORD was still
> considered 16 bits for historical reasons. In the RISC world WORD meant
> the native machine word size. It's another one of those idiosyncratic
> terminology issues we face every day as embedded developers.

I'm aware of these issues, though I couldn't tell whether 'native machine
type' or '16 bit' came earlier.

> I recommend
> never using DWORD, and WORD types myself and instead always use the size
> specific typedefs UINT32, INT16, etc...

Definitely, yes. 'word' is flawed and thus not useful except in a very
restricted context.

> the lack of native support for such size specific types in C/C++ is a
> big flaw in the design of those languages in my view.

C has them since C99 in stdint.h. Proposals to adopt that header for C++
exist, otherwise such a header is easily retrofitted to common systems or
you can use Boost's collection of according typedefs. Seems you were not
the only one that considered these a neat feature ;)

Uli

Steve
Wed Jan 04 12:37:23 CST 2006

>C has them since C99 in stdint.h
due to compatibility and huge amounts of existing code prior to C99... C99
is mostly irrelevant. (E.g. too little too late.) anyone that cared about
the size specific versions created their own, and generally incompatible
with anyone else's, types already and it's still not natively part of the
language in C99, it's part of the standard library. There's a difference. It
always astounded me that a language intended for low level system
development didn't define size specific data types natively nor define the
actual ordering of bits for structure bit fields. (Since bit ordering of bit
fields is officially undefined they are mostly useless for code that needs
to work under multiple compilers. If my memory of those days is still
clear - They got both of those parts right when designing PL/1)

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com