-DSTRICT warning fixes

[Patrik Stridvall]

> > If we do that can just do
> > s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/
> > on the handle types on by one and fix the warnings.
> 
> That's precisely the plan, and it is just the opposite of what you are
> doing with your patch (you are turning DECLARE_HANDLE back into
> DECLARE_OLD_HANDLE). 

The reason I did that was that they can't be fixed as long as
HANDLE/HGLOBAL is the wrong types. When they become the right
types the warnings will automatically disappear and we can
do s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/. But there is no
reason to have a lot of warnings that can't be fixed
otherwise until then.

> Yes you get a number of warnings if you turn
> -DSTRICT on, most of them should disappear once the conversion is
> complete; fixing them before that is a waste of time.

Since we can't fix before that why show them at all?

People that want to fix for example output messages can do,
s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/ in their tree,
fix them and submit the patches (without the
s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/).

> This is the
> reason why -DSTRICT is not the default yet.  Read bug report #90,
> Francois explains everything there.

OK. I have read bug report #90 now.

> And don't forget the number one rule of the -DSTRICT conversion is:
> *no* *typecasts*. If you have to add typecasts something is wrong.

No typecasts where the handle is used in conjuction with other handles,
certainly not, no argument there. The code some expect all handles to
be the of same type.

However for the debugging output I disagree. I orginally thought
as Francois (and you it seems) that handles are pointers and should
be treated as such. But then I realized that when we implement Win32 on
64-bit platforms we can't have handles as pointers even internally if
we wan't to support x86 emulation and even exposing a 64-bit
handle to Winelib application can only cause trouble since they
might store it is a 32-bit memory location. Sure we will probably be
able to handle 64-bit pointers truncated to 32-bit by storing all
objects in the lower 32-bit part of memory, but fear it might
cause trouble all the same.

Beside doing TRACE("(%p)", handle) on 64-bit platforms will needlessly
display the always the same presumably zero upper 32-bit part
of the handle. That why I decided to should use
TRACE("(0x%08lx)", (DWORD) handle) instead to avoid such issues.

In short, the code should IMHO support both 32-bit pointers as well
and 32-bit integers as handles presuming of course that all handles
use the same.

The real reason that we should support compiling Wine with -DSTRICT
is not because handles becomes pointers but because callbacks gets
the correct prototype.

I case not you haven't realized the obvious, it doesn't matter if
the handles are 32-bit integer or 32-bit pointers as long as
all handles are the same. The code either
1. Just pass them around as the same type of handles of other types
   of handles (HANDLE/HGLOBAL).
2. Tries to access the underlying object, in such case a void pointer
   will not do use any good, we must use a cast either after calls to
   functions like GlobalLock or alone.