Migrate to amd64

I am trying to migrate a win32 Driver to a amd64 Driver.

Now I have got a Problem:

VideoDataBuf.hpp(70) : error C2220: warning treated as error - no object
file generated
VideoDataBuf.hpp(70) : warning C4311: 'type cast' : pointer truncation from
'PVOID' to 'long'
VideoDataBuf.hpp(70) : error C4312: 'type cast' : conversion from 'LONG' to
'void *' of greater size

The Code:

PVOID GetBufAddr(LONG lOffset = 0 ) const { return PVOID(lOffset +
LONG(GetSrb()->CommandData.DataBufferAry->Data)); }

How Should I convert this to make it amd64 compliant?

Bryan
Fri Nov 05 14:45:02 CST 2004

I've never done this type of convert but you may want to try:

return PVOID(lOffset + (ULONG_PTR)
GetSrb()->CommandData.DataBufferAry->Data);

Chris
Fri Nov 05 15:04:54 CST 2004

Remember that pointers will now be 64 bits, but a long will still be 32.
Hence the truncation error.
See "64-Bit Issues" in the DDK.

Chris

"Longkong" <Longkong@discussions.microsoft.com> wrote in message
news:0490A1AC-F75B-47FA-B496-E4EA9051DCF5@microsoft.com...
>I am trying to migrate a win32 Driver to a amd64 Driver.
>
> Now I have got a Problem:
>
> VideoDataBuf.hpp(70) : error C2220: warning treated as error - no object
> file generated
> VideoDataBuf.hpp(70) : warning C4311: 'type cast' : pointer truncation
> from
> 'PVOID' to 'long'
> VideoDataBuf.hpp(70) : error C4312: 'type cast' : conversion from 'LONG'
> to
> 'void *' of greater size
>
> The Code:
>
> PVOID GetBufAddr(LONG lOffset = 0 ) const { return PVOID(lOffset +
> LONG(GetSrb()->CommandData.DataBufferAry->Data)); }
>
> How Should I convert this to make it amd64 compliant?

Longkong
Fri Nov 05 16:01:02 CST 2004

Thx for Your Help, it worked now.
But this thing is more heavy then I thought. My Next Error:

error C4312: 'type cast' : conversion from 'unsigned long' to 'DWORD *' of
greater size

The Code:
void SaveRegister( DWORD dwReg ) { *((PDWORD)( achSavedRegs + dwReg )) =
READ_REGISTER_ULONG ( PDWORD(dwReg + dwBaseAddress) ); }

Thx for your help in advance :D

Bryan
Fri Nov 05 16:25:24 CST 2004

I'm not sure if it was my comment or his that was 'helpful', but this
looks like the same issue. Cast your variables to DWORD_PTR explicity
such as (DWORD_PTR) dwBaseAddress.

Longkong
Fri Nov 05 16:48:06 CST 2004

Your Post was very "helpful", thx ;)

I tryed it with
void SaveRegister( DWORD dwReg ) { *((PDWORD)( achSavedRegs + dwReg )) =
READ_REGISTER_ULONG ( (DWORD_PTR)(dwReg + dwBaseAddress) ); }


Now I have got the following Error:

error C2664: 'READ_REGISTER_ULONG' : cannot convert parameter 1 from
'DWORD_PTR' to 'volatile ULONG *'
Conversion from integral type to pointer type requires
reinterpret_cast, C-style cast or function-style cast

Sorry, if this questions seem stupid to you, but I never tried to compile
something on another Platform then i386 ;)


"Bryan.Berns@gmail.com" wrote:

> I'm not sure if it was my comment or his that was 'helpful', but this
> looks like the same issue. Cast your variables to DWORD_PTR explicity
> such as (DWORD_PTR) dwBaseAddress.
>
>

Bryan
Fri Nov 05 17:34:05 CST 2004

I'm new here, too but I've see alot of casting issues in my days. I
don't have a compiler on had and I don't recognize these functions, but
I believe you're running into issues where sizeof(DWORD_PTR) !=
sizeof(DWORD). Try:
READ_REGISTER_ULONG(PULONG(dwReg + dwBaseAddress));

Maxim
Fri Nov 05 19:42:17 CST 2004

Use LONG_PTR instead of LONG.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Longkong" <Longkong@discussions.microsoft.com> wrote in message
news:0490A1AC-F75B-47FA-B496-E4EA9051DCF5@microsoft.com...
> I am trying to migrate a win32 Driver to a amd64 Driver.
>
> Now I have got a Problem:
>
> VideoDataBuf.hpp(70) : error C2220: warning treated as error - no object
> file generated
> VideoDataBuf.hpp(70) : warning C4311: 'type cast' : pointer truncation from
> 'PVOID' to 'long'
> VideoDataBuf.hpp(70) : error C4312: 'type cast' : conversion from 'LONG' to
> 'void *' of greater size
>
> The Code:
>
> PVOID GetBufAddr(LONG lOffset = 0 ) const { return PVOID(lOffset +
> LONG(GetSrb()->CommandData.DataBufferAry->Data)); }
>
> How Should I convert this to make it amd64 compliant?

Longkong
Sat Nov 06 02:57:01 CST 2004

Hmm, good Idea, but it does not work :(

error C4312: 'type cast' : conversion from 'unsigned long' to 'ULONG *' of
greater size

Very strange... :/




"Bryan.Berns@gmail.com" wrote:

> I'm new here, too but I've see alot of casting issues in my days. I
> don't have a compiler on had and I don't recognize these functions, but
> I believe you're running into issues where sizeof(DWORD_PTR) !=
> sizeof(DWORD). Try:
> READ_REGISTER_ULONG(PULONG(dwReg + dwBaseAddress));
>
>

Chris
Mon Nov 08 12:51:43 CST 2004

I could be wrong but is an ULONG still 32 bits in 64-Bit Windows? If so,
the compiler error makes sense.
I think what you need to do is change dwReg and dwBaseAddress to values that
can actually hold 64-bit address values.

So perhaps something like (I haven't tried to compile this):

void SaveRegister(DWORD_PTR dwReg){
*((PULONG)(achSavedRegs + dwReg))=READ_REGISTER_ULONG((PULONG)(dwReg +
dwBaseAddress));
}


The problem that many people (including myself) are going to run into when
going to 64-bits is that integer, long, etc. types do not increase to
64-bits like pointers do. So, for a very long time we've all been assuming
that a pointer will fit into a DWORD, ULONG, etc. but this assumption is no
longer valid.

Hope this helps/works, Chris

"Longkong" <Longkong@discussions.microsoft.com> wrote in message
news:CAB17CC2-F22E-410F-94B8-E635C8461AB6@microsoft.com...
> Hmm, good Idea, but it does not work :(
>
> error C4312: 'type cast' : conversion from 'unsigned long' to 'ULONG *' of
> greater size
>
> Very strange... :/
>
>
>
>
> "Bryan.Berns@gmail.com" wrote:
>
>> I'm new here, too but I've see alot of casting issues in my days. I
>> don't have a compiler on had and I don't recognize these functions, but
>> I believe you're running into issues where sizeof(DWORD_PTR) !=
>> sizeof(DWORD). Try:
>> READ_REGISTER_ULONG(PULONG(dwReg + dwBaseAddress));
>>
>>

Don
Mon Nov 08 12:57:54 CST 2004

This is why Microsoft about 5 years ago started pushing people to new
datatypes such as ULONG_PTR so that hopefully there wouldn't be these
problems.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

"Chris" <cdore.connecttech.com> wrote in message
news:Om8j%23PcxEHA.3416@TK2MSFTNGP09.phx.gbl...
> I could be wrong but is an ULONG still 32 bits in 64-Bit Windows? If so,
> the compiler error makes sense.
> I think what you need to do is change dwReg and dwBaseAddress to values
that
> can actually hold 64-bit address values.
>
> So perhaps something like (I haven't tried to compile this):
>
> void SaveRegister(DWORD_PTR dwReg){
> *((PULONG)(achSavedRegs + dwReg))=READ_REGISTER_ULONG((PULONG)(dwReg +
> dwBaseAddress));
> }
>
>
> The problem that many people (including myself) are going to run into when
> going to 64-bits is that integer, long, etc. types do not increase to
> 64-bits like pointers do. So, for a very long time we've all been
assuming
> that a pointer will fit into a DWORD, ULONG, etc. but this assumption is
no
> longer valid.
>
> Hope this helps/works, Chris
>

pavel_a
Mon Nov 08 14:44:07 CST 2004

"Longkong" wrote:
> Hmm, good Idea, but it does not work :(
> error C4312: 'type cast' : conversion from 'unsigned long' to 'ULONG *' of
> greater size
> Very strange... :/

Not strange at all. Every good advise in this group usually requires
half dozen others on how to follow the original advise.

Integer is not a pointer, DWORD is not a pointer, ULONG is not a pointer!
Please repeat this mantra several times and you will be enlightened.
( The compiler will never get tired, but it never will be enlightened... )

Regards,
--PA

Ray
Mon Nov 08 19:18:18 CST 2004

Here's a (non-facetious) question for people: is there some reason why
LONG_PTR is superior to PVOID? You're going to have to cast that puppy
in order to use it either way...

Maxim S. Shatskih wrote:
> Use LONG_PTR instead of LONG.
>

--
../ray\..

pavel_a
Mon Nov 08 23:50:02 CST 2004

"Ray Trent" wrote:
> Here's a (non-facetious) question for people: is there some reason why
> LONG_PTR is superior to PVOID? You're going to have to cast that puppy
> in order to use it either way...

(U)LONG_PTR is integer type, so no need to cast it for arithmetic operations.
For pointer arithmetics it is more like PUCHAR.

--PA

Ray
Tue Nov 09 16:06:15 CST 2004

Sure... but you can't really do pointer arithmetic anyway without
knowing the type of the object, at which point you're back to a cast.

If you're assuming it's more convenient for it to act like a PUCHAR for
pointer arithmetic reasons, then why not make it that?

I kind of see the point if we're talking about an API where a parameter
can be passed either a pointer or an integer, depending on some other
parameter, and where it's "usually" an integer (making casting it a tiny
bit of an unnecessary pain). I tend to think that's a bad idea in
general, BTW.

But in the vast majority of cases, wouldn't it be better to pass an
actual pointer? Especially if you're having to change those lines of
code anyway to get 64-bit compliance?

Pavel A. wrote:
> "Ray Trent" wrote:
>
>>Here's a (non-facetious) question for people: is there some reason why
>>LONG_PTR is superior to PVOID? You're going to have to cast that puppy
>>in order to use it either way...
>
>
> (U)LONG_PTR is integer type, so no need to cast it for arithmetic operations.
> For pointer arithmetics it is more like PUCHAR.
>
> --PA
>

--
../ray\..

Peter
Tue Nov 09 16:42:31 CST 2004

However PUCHAR is a typed pointer, and its presence in an API would suggest
to me that it was supposed to provide a character array to the function.

To me pointer arithmatic (using the actual math operators) is just plain
evil. It's bad enough on typed pointers (though i prefer to use array
notation where i can). If i have to cast an untyped pointer to do math on
it i'd rather cast it to the integer domain. To me this is cleaner than
casting it into a typed pointer simply for the convenience of later
dereferencing it.

-p

ps. it always surprises me that some of the same people (not necessarily
anyone on this thread) who vehemently hate operator overloading accept the
fact that PFOO + 1 is not necessarily the same value as ((ULONG) PFOO) + 1.


--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ray Trent" <ratrent@nospam.nospam> wrote in message
news:OxDXWhqxEHA.2172@TK2MSFTNGP14.phx.gbl...
> Sure... but you can't really do pointer arithmetic anyway without knowing
> the type of the object, at which point you're back to a cast.
>
> If you're assuming it's more convenient for it to act like a PUCHAR for
> pointer arithmetic reasons, then why not make it that?
>
> I kind of see the point if we're talking about an API where a parameter
> can be passed either a pointer or an integer, depending on some other
> parameter, and where it's "usually" an integer (making casting it a tiny
> bit of an unnecessary pain). I tend to think that's a bad idea in general,
> BTW.
>
> But in the vast majority of cases, wouldn't it be better to pass an actual
> pointer? Especially if you're having to change those lines of code anyway
> to get 64-bit compliance?
>
> Pavel A. wrote:
>> "Ray Trent" wrote:
>>
>>>Here's a (non-facetious) question for people: is there some reason why
>>>LONG_PTR is superior to PVOID? You're going to have to cast that puppy in
>>>order to use it either way...
>>
>>
>> (U)LONG_PTR is integer type, so no need to cast it for arithmetic
>> operations.
>> For pointer arithmetics it is more like PUCHAR.
>>
>> --PA
>>
>
> --
> ../ray\..

Chris
Wed Nov 10 08:49:30 CST 2004

"Peter Wieland [MSFT]" <peterwie@online.microsoft.com> wrote:
> ps. it always surprises me that some of the same people (not necessarily
> anyone on this thread) who vehemently hate operator overloading accept the
> fact that PFOO + 1 is not necessarily the same value as ((ULONG) PFOO) +
> 1.

You mean ((ULONG_PTR) PFOO) + 1 right? :)

Chris

Peter
Wed Nov 10 09:11:02 CST 2004

touche

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Chris" <cdore.connecttech.com> wrote in message
news:ukOr9RzxEHA.2876@TK2MSFTNGP12.phx.gbl...
> "Peter Wieland [MSFT]" <peterwie@online.microsoft.com> wrote:
>> ps. it always surprises me that some of the same people (not necessarily
>> anyone on this thread) who vehemently hate operator overloading accept
>> the fact that PFOO + 1 is not necessarily the same value as ((ULONG)
>> PFOO) + 1.
>
> You mean ((ULONG_PTR) PFOO) + 1 right? :)
>
> Chris
>
>

Pavel
Wed Nov 10 18:00:54 CST 2004

Talking of pointer arithmetics, by the way, not to be forgotten
is size_t ( aka ptrdiff_t ) - it becomes ULONG_PTR as well.

--