reference

[worlman385@yahoo.com]

The prototype of GetExitCodeThre ad is like this -

GetExitCodeThre ad(
__in HANDLE hThread,
__out LPDWORD lpExitCode
);

=============== ==============
why we put &dwExitCod in the parameter? like -

DWORD dwExitCode;
GetExitCodeThre ad( hth2, &dwExitCode );

=============== ==============
digging further i found -
typedef DWORD near *PDWORD;
typedef DWORD far *LPDWORD;

=============== ==============
So DWORD* "equals" LPDWORD ???

then above
LPDWORD lpExitCode
should be taking parameter of
DWORD* lpExitCode

(Given DWORD* "equals" LPDWORD) ???

=============== ==============
that's why &dwExitCode ? since &dwExitCode "returns" a pointer to
DWORD.

[Eberhard Schefold]

[OT] Windows types (WAS: reference)

James Kanze wrote:

The few times I've programmed against the Windows interface,
I've found just the opposite to be true: MS doesn't seem to have
enough different data types to keep things straight. It's nice
to say that everything is a HANDLE, but it's even nicer to get a
compiler error if I try to lock a mutex using a handle returned
from CreateFile.

I don't really mean to try and defend the Windows intrinsics, but it's a
little more complex than that. In some contexts, a file handle is
distinct from a mutex handle, but there are instances where both are
treated equally, e.g. there are "wait" functions that accept either
type. With the Windows API being largely defined in terms of C and thus
limited in support for polymorphism, I don't think you can do much
better than that.

[Sam]

Re: [OT] Windows types (WAS: reference)

Eberhard Schefold writes:

James Kanze wrote:
>

>The few times I've programmed against the Windows interface,
>I've found just the opposite to be true: MS doesn't seem to have
>enough different data types to keep things straight. It's nice
>to say that everything is a HANDLE, but it's even nicer to get a
>compiler error if I try to lock a mutex using a handle returned
>from CreateFile.

>
I don't really mean to try and defend the Windows intrinsics, but it's a
little more complex than that. In some contexts, a file handle is
distinct from a mutex handle, but there are instances where both are
treated equally, e.g. there are "wait" functions that accept either
type. With the Windows API being largely defined in terms of C and thus
limited in support for polymorphism, I don't think you can do much
better than that.

Crikey.

Recent Linux kernels have introduced some Linux-specific gizmos like
eventfd, timerfd, and signalfd, which, based on how I parse the above, end
up implementing the same thing -- a unified file I/O-based access to
signals, timers, and events. So, as an example, instead of setting up a
signal handler to catch a signal, a signal gets mapped to a file descriptor,
so by plugging all of that into poll(), or the Linux-specific epoll(), your
application can simultaneously "wait" for signals and application-specific
timers or events to fire off, whichever comes first.

The difference is that this is done in a sane, logical manner, instead of
the tangled, hairy mess that the Windows API comes up with, to do the same
thing.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBH/VeOx9p3GYHlUOIR ApinAJ0TjXbq0Gq kqqhihCR68fp7U8 p5iwCdGye4
loggepLWsv51Spj dpjZfmcA=
=HukG
-----END PGP SIGNATURE-----

[Pete Becker]

Re: reference

On 2008-04-10 05:40:27 -0400, James Kanze <james.kanze@gm ail.comsaid:

>
I don't think so. I think it's more along the lines as to why
we need an address here. And that, of course, we can only know
if we know the real type of LPDWORD, and can see its
constructors.

Or if you know the Windows API's naming conventions. LPDWORD is a
pointer (that's the LP part; the L actually stands for long, as in far,
but it's irrelevant now) to a DWORD (32-bit value, if I remember
correctly).

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)