[Bf-committers] 64 bits migration, windows/unix

Ton Roosendaal ton at blender.org
Sat Apr 30 13:22:48 CEST 2005


We'll have to define the Blender standard for migrating to 64 bits for  
all platforms... unfortunately the unix and windows worlds haven't  
adopted the same standard...

Check this diagram;

The key difference is that;

- Windows keeps the "long" 32 bits in all cases, for unix it is 32 or  
64 bits.
- Windows doesn't have a "long long" (int64 instead).

With Blender's unix origins - already tested for 32/64 bits in the past  
- it would be simplest to investigate if we can typedef/define the  
Windows version to follow the LP64 standard.
If we can do that, no further #ifdef exceptions are needed to patch our  
code to be 32/64 bits compliant for all platforms.

So, I would like a Windows 64 bits developer to check on the following;

1) Patch BLI_winstuff.h

Something like this could work: (blenloader/intern/genfile.c uses it)

#ifdef WIN32
typedef long long __int64;

#ifdef WIN64
typedef long long __int64;
typedef long __int64

One note though... the BLI_winstuff.h is only included in the  
blender/source/ tree, not for our blender/intern/ and blender/extern/  
libraries. These each have to be checked on 32/64 issues as well.

2) Cleanup of platform #defines

We now already use a mix of WIN32 and _WIN32 to patch OS specific code,  
this is in all cases not 32 bits related, so we need a new generic  

I hope Microsoft / Cygwin has another standard already. This better not  
gets patched in the BLI_winstuff.h, since we also have an intern and  
extern libraries to take care of.

3) Verifying DWORD referrals

In the Blender code are a couple of windows-only functions or C files.
Check the MSDB website for the porting guides for 64 bits, with several  
notes on proper 32/64 bits code.


Ton Roosendaal  Blender Foundation ton at blender.org  

More information about the Bf-committers mailing list