-DSTRICT warning fixes

[Patrik Stridvall]

> Patrik Stridvall <ps at leissner.se> writes:
> 
> > Sure Win64 should use 64-bit pointers as handles that is
> > without questions, but forcing it on Win32 on 64-bit
> > is totally unnessary
> 
> This may be the root of your misunderstanding: there is no such thing
> as Win32 on 64-bit platforms. Wine (and Winelib) implement Win32 on
> 32-bit platforms, and Win64 on a 64-bit platform. 

Well, actually Win32 does exist (or rather existed, it has been
discontinue by Microsoft) on Alpha. But, never mind, it doesn't
matter.

The point is somebody has souce code for a Windows application 
and wishes that it will run on Alpha. He or she doesn't care
whether Win32 on 64-bit exists or not he wished to port his
application with as little effort as possible.

He or she doesn't care what magic Winelib does as long as it works
and he has to change the source as little as possible.

> If you want to
> compile your apps as Win32, you need a 32-bit compiler.

Sure thats an idea, but doing that is a little awkard,
no 32-bit compiler currently exists for 64-bit platforms AFAIK.

While this might work, at least in theory, if you only call the
Win32 API, how do you suggest calls to 64-bit Unix libraries
should be handled?

> Then you use
> the same compiler to build Wine as a Win32 library, and everything
> works fine. If you use a 64-bit compiler, some types (including
> handles) become 64-bit, and you have to deal with it.

Since you refuse to make it easier for the porter, sure he or she will
have to deal with it, that is pretty obvious isn't it?

The question is what can we do to make it easier for the porters.
We can almost always say "We don't care, its your problem", so
that is not an argument by itself. Sure we can't do the impossible,
and some things takes to much effort, but still.
 
> The only possible exception would be running existing Win32 binaries
> on ia64. And I'm not even convinced it needs an exception, it's
> probably easier to simply build a version of Wine with the 32-bit gcc
> than to try to come up with a translation layer.

Well, that is a future problem. I don't know exactly how to handle it
either, but as you pointed out earlier since we need to convert
32-bit pointers to 64-bit pointers we might as well convert 32-bit
handlers to 64-bit handlers the same way.

Of course that doesn't mean that being able to compile Winelib with
handle as 32-bit integers won't help, but I really can't say whether
or not right now.