«

Hi all

Still working with my 64-bit researching and conversions, now I've
found myself stucked on an error where the _CONTEXT struct in Winnt.h
is involved. The following two fields are only long in that struct, but
as you probably know a pointer in x64 is 64-bit and not 32... So, I'm
afraid of that the previos cast from Context.Eip and Context.Ebp to a
pointer would not work so very well...
Eip
Ebp

So, how to workaround this problem? I've tried to find a simple fix but
in that research I find myself more and more convinced that it isn't so
easy. I'm pretty convinced now that there is some other way to handle
the information in that struct in x64, but how?

I'm programming in VS2005 but the code is supposed to be platform
independant.

TIA


--
Burtraskkutaren
------------------------------------------------------------------------
Burtraskkutaren's Profile: http://www.64bit-world.com/forums/member.php?u=1984
View this thread: http://www.64bit-world.com/forums/sh...ad.php?t=21320

Perhaps I am totally wrong, I am more than rusty - but you are not supposed
to cast pointers to data-types, or vice-versa (are you?) Pointers have a
fixed size on each platform, and are having no problems pointing to data of
any size. It is what pointers do!

You might find far better info in a developer NG - this one is more of a
'general use' group. And if you get specific errors, do tell the good people
about them.


Greetings, Tony. . .


"Burtraskkutaren" <>
wrote in message
news:...
>
> Hi all
>
> Still working with my 64-bit researching and conversions, now I've
> found myself stucked on an error where the _CONTEXT struct in Winnt.h
> is involved. The following two fields are only long in that struct, but
> as you probably know a pointer in x64 is 64-bit and not 32... So, I'm
> afraid of that the previos cast from Context.Eip and Context.Ebp to a
> pointer would not work so very well...
> Eip
> Ebp
>
> So, how to workaround this problem? I've tried to find a simple fix but
> in that research I find myself more and more convinced that it isn't so
> easy. I'm pretty convinced now that there is some other way to handle
> the information in that struct in x64, but how?
>
> I'm programming in VS2005 but the code is supposed to be platform
> independant.
>
> TIA
>
>
> --
> Burtraskkutaren
> ------------------------------------------------------------------------
> Burtraskkutaren's Profile:
> http://www.64bit-world.com/forums/member.php?u=1984
> View this thread: http://www.64bit-world.com/forums/sh...ad.php?t=21320
>

Hi Ton

Thanks for the reply, I've been trying to find good places concernin
64bit development and then this one probably ain't the best either..
Regarding your answer, well the prolem is that the main idea with x6
architecture and also development is that you should be able to ru
both x86 and x64 binaries with the same code, just differen
compilations. And that's the reason why I'm asking the question,
might have to find replacement functionality and hiding it in th
library with ifdef's for different architectures but I haven't gotte
that far in that matter yet

--
Burtraskkutare
-----------------------------------------------------------------------
Burtraskkutaren's Profile: http://www.64bit-world.com/forums/member.php?u=198
View this thread: http://www.64bit-world.com/forums/showthread.php?t=2132

I'd suspect, if your compiler is enabled for 64bit (mine isn't - it's the
free version) it would have some documentation or links to such about
'porting'. The 32/64bit issue is handled in the OS by way of a compatibility
layer, and I interpret that as saying: "all you need to worry about is
writing a program that works within it's own framework", the OS and the
compiler takes care of the rest. The x64 installer is specifically written
to set things up to work in co-ordinance with this compatibility layer and
the rest probably is left to conventions that you need to know about to get
started. I can understand that the documentation for all this may not seem
to be laying around everywhere, questions of this sort pop up frequently, if
not regularly. I wish I could be of more assistance.

Someone having studied litterature about programming for the 'Itanium', I
can understand being confused because in all prbability all the conventions
about '64bit' would be totally 'other'.

Two 'groups' I can find that may be of more help:

microsoft.public.vstudio.general
microsoft.public.vstudio.development

other than that, it seems that 'googling' is a talent as resourcefull as
anything, no matter what business you're in!

My favorite authors on 'C/C++' Petzold; Prosise; Eckel; - if they have
written anything on 64bit yet, that stuff would be invaluable to you, I'm
sure. They don't just teach you how to write programs (something you already
do), they teach you why you want to write it in a certain way.

And you are probably right - porting, probably is quite a lot about
pre-compiler directives. (;0/


Tony. . .


"Burtraskkutaren" <>
wrote in message
news:...
>
> Hi Tony
>
> Thanks for the reply, I've been trying to find good places concerning
> 64bit development and then this one probably ain't the best either...
> Regarding your answer, well the prolem is that the main idea with x64
> architecture and also development is that you should be able to run
> both x86 and x64 binaries with the same code, just different
> compilations. And that's the reason why I'm asking the question, I
> might have to find replacement functionality and hiding it in the
> library with ifdef's for different architectures but I haven't gotten
> that far in that matter yet.
>
>
> --
> Burtraskkutaren
> ------------------------------------------------------------------------
> Burtraskkutaren's Profile:
> http://www.64bit-world.com/forums/member.php?u=1984
> View this thread: http://www.64bit-world.com/forums/sh...ad.php?t=21320
>

The CONTEXT structure is #ifdef specified based on the selected platform.
That is, the CONTEXT structure is different for a x86 build and a x64 build.

In x64 the Eip and Esp are not present, their x64 counterparts are Rip and
Rsp respectively.
So, for example, i have code to do a stack trace that uses the following:

CONTEXT thdctx;
memset(&thdctx, 0, sizeof(thdctx));

thdctx.ContextFlags = CONTEXT_FULL;
::RtlCaptureContext(&thdctx);

frame.AddrPC.Mode = AddrModeFlat;
frame.AddrFrame.Mode = AddrModeFlat;
frame.AddrStack.Mode = AddrModeFlat;

#ifdef _WIN64
frame.AddrPC.Offset = thdctx.Rip; // program counter
frame.AddrFrame.Offset = thdctx.Rbp; // frame pointer
frame.AddrStack.Offset = thdctx.Rsp; // stack pointer
#else
frame.AddrPC.Offset = thdctx.Eip;
frame.AddrFrame.Offset = thdctx.Ebp;
frame.AddrStack.Offset = thdctx.Esp;
#endif


Note:
RtlCaptureContext is a new function available on XP up.
It allows you to get an accurate context for the current running thread
(GetThreadContext does not).
It is portable across platforms and gets rid of the inline assembly (or
throwing an exception) that was used on x86 to get the eip/ebp/esp values.


cmk

Thanks Chris, I suspected something like that but obviously I've been
too lazy to search well enough in winnt.h to find it. At least that
part compiles better now, but I haven't been able to test it yet but I
believe it will work.

Tony, depending on the code it really shouldn't be so much precompiler
directives. Some yes, and if you get a little bit deeper (like this
example) you obviously have to use it but mostly you don't have to.


--
Burtraskkutaren
------------------------------------------------------------------------
Burtraskkutaren's Profile: http://www.64bit-world.com/forums/member.php?u=1984
View this thread: http://www.64bit-world.com/forums/sh...ad.php?t=21320

Thanks, that is both good and bad all at once - I'll bare that in mind if
ever time will allow me to get my feet wetted in those waters again. Pension
is not so far away, so there may still be hope.

Tony. . .


"Burtraskkutaren" <>
wrote in message
news:...
>
> Thanks Chris, I suspected something like that but obviously I've been
> too lazy to search well enough in winnt.h to find it. At least that
> part compiles better now, but I haven't been able to test it yet but I
> believe it will work.
>
> Tony, depending on the code it really shouldn't be so much precompiler
> directives. Some yes, and if you get a little bit deeper (like this
> example) you obviously have to use it but mostly you don't have to.
>
>
> --
> Burtraskkutaren
> ------------------------------------------------------------------------
> Burtraskkutaren's Profile:
> http://www.64bit-world.com/forums/member.php?u=1984
> View this thread: http://www.64bit-world.com/forums/sh...ad.php?t=21320
>