[Bf-committers] AMD64 bit support issues
ton at blender.org
Mon Nov 14 15:17:02 CET 2005
> > It wouldn't be hard to typedef things in winstuff.h to make it
> > following that standard too.
> Can you give an example? I can't see how to do this without either
> (a) changing all the casts from int or long to void *
> (b) creating a new datatype which is the same size as a long,
> consistent on each platform
> (c) typedef-ing long to be long long for windows, which AFAIK is not
I have no windows coding experience, so don't know the trick. I also
don't know which variable type in windows is standard 32 bits in 32
bits OS, and 64 in 64 OS (is that intptr_t?). That's what the 'long' in
Blender is for now, it can be either size, depending on how it
In Blender code is the "long long" typedeffed as 64 bits btw.
Now, can't you just put in winstuff.h somthing like;
typedef long intptr_t;
> I personally don't mind just changing everything to use a long, since
> it will work for me, but it doesn't help 64-bit Windows developers.
> On the other hand maybe I'm just really dense; is this is non-issue on
> Win64? Is a long really 64-bits there?
>>> and I'm trying to decided the best way to get this into the
>>> necessary files and include search paths. Currently I've changed
>>> about 8 makefiles and 6 SConscript files
>> I'd appreciate if you would first mail the list what you exactly want
>> to do?
> Trust me, I'll be thrilled to get everyone else's blessing before I
> make any permanent changes :-) I'd like to make as few as possible.
>>> but I'm planning today to examine the various search paths more
>>> closely to see what the current settings are. It looks like the
>>> most painless way right now would be add or modify include files in
>>> blender and the game engine; I don't see any common include path
>>> which both use consistently.
>> No idea what you try... the 64 bits versions we did in past didn't
>> need much tweaks in .h or makefiles...
> Again, I believe you, but do the Windows developers care?
>>> So what's the preferred approach? Duplicate header files with no
>>> change to the builds, or one header file and changes to the builds
>>> (which will
>>> involve the other platform maintainers)?
>>> (Actually, if someone (ton?) can give me a definitive direction to
>>> take, this could still make it before the cvs freeze)
>> This is definitely for after 2.40 is out!
> No problem; but in the meantime I'd like to be able to work on this,
> and would appreciate some direction. I discovered today that two old
> .blend files which work fine on my 32-bit machine give memory
> corruption warnings and segfaults on my 64-bit machine. So I'm
> motivated to work on the 64-bit port; otherwise I may as well install
> a 32-bit version of the OS.
> Bf-committers mailing list
> Bf-committers at projects.blender.org
Ton Roosendaal Blender Foundation ton at blender.org
More information about the Bf-committers