If you maintain a plugin for X-Plane, you can already take some of the steps necessary to go 64-bit. I am working on 64 bit code for 10.20; here’s what you can do to be ready for the beta:
Upgrade to the X-Plane SDK 2.1 headers. The 2.1 headers change the use of long to intptr_t to fix 64-bit issues. This will mean a one-time cut-and-paste pass over your code.
Note that you do not have to make your plugin v10-only (or 2.1 SDK only) to use the new headers. Your plugin will require the 2.1 SDK only if you #define XPLM210 to 1. By not defining the new APIs you don’t opt into them. Your plugin built against the 2.1 SDK will work with X-Plane 9 (or 8, 7 or 6 for API 1.0 plugins).
Find and fix any case where you cast a pointer to an int and back – in 64 bits that will fail. as you will see from the 2.1 headers, widget properties are now intptr_t to ensure that the property can hold a pointer.
Once you have have fixed these new header issues and int <-> ptr issues you’ll be in good shape to go to 64 bits when a sim is available.
Update: to clarify, with the 2.1 SDK you can write code that will be 64-bit safe, and you can probably even compile in 64 bits. But you can’t link your 64-bit plugin – we have not released library files or documentation on the appropriate fat packaging structure. So you can get ready by cleaning your C/C++ code, but you can’t actually finish a 64-bit plugin. (And if you could, how would you test it?)
Hooray! Maybe just some more weeks (?) and at least those of us waiting with 32GB of RAM will finally get the opportunity to bypass the 4GB 32-bit limit! Two big thumbs up to the crew (sorry for OT)!
Hello Ben,
And what about making the whole sdk compatible with 32 bits, but add functions and possibility to people use 64 bits too?
So for example, while communicating between (pluginx-plane) it could keep with 32 bits stuff, and x-plane handle the conversion of those 32bits pointers to 64bits.
And if developer want to go forward into 64bits, then he got ability to use 64 bits natively by few implementations that would allow that.
What´s my point, there´s lot of stuff and plugins around, most of them probably will crash if you go and change actual way of work, so would be cool to maintain a compatibility between 32bits and 64bits, so it could work like a transition and not like a punch into old plugins.
This is not possible. Plugins operate _inside_ X-Plane’s address space – if X-Plane is 64 bits, then the plugin is living in a 64 bit address space and must be prepared for 64 bit pointers.
To be clear: the SDK _is_ going to be 32 and 64 bit compatible – we are NOT dropping 32-bit support!!!
But we are NOT providing a 32-64 bit bridge – as far as I can tell this isn’t possible given how the SDK works.
Oh,
That sounds great so, basically old 32 bits plugins will run at no problem?
What i´m afraid is that all plugins need to be modified and recompiled to make compatible, that would hurt lot of developers.
But if 32 bits compability is kept, then the transition will be smooth and as developers do new plugins they can go and change their stuff to 64bits.
Wait – I think you may have totally misunderstood what’s going on.
When we go 64 bit, there will be SIX x-plane apps instead of 3. There will be a 32 and 64 bit X-Plane for each OS – thus two apps for each OS.
The user will be able to pick which app he or she wants to run – 32 or 64 bits.
Each app will ONLY load plugins that match the ABI of the running sim. So if you make a:
-32 bit only plugin (ALL shipping plugins are 32-bit only now) then your plugin will ONLY loaded by 32-bit x-plane.
-64 bit only plugin (you’d have to be a bit nuts to drop 32-bit support now I think) then your plugin will ONLY be loaded by 64-bit X-Plane or
-A 32 and 64-bit fat plugin (this is what we recommend going forward) then your plugin will be loaded y EITHER version of x-plane.
So your existing 32-bit plugins will ONLY work if the user runs the 32-bit version of x-plane. Over time, since users will be able to run with higher rendering settings without crash on the 64-bit version of x-plane, they will come to you and ask you to port your plugin to 64 bits as well so that they don’t have to choose between your plugin and maxing out rendering settings.
Oh, now i totally got your point.
Thanks for explanation Ben.
As a plugin author I can’t wait till I can move my plugin to the next level with 32/64 bit support.
I have already made it 64 bit safe and has been that way for a few releases. I want to thank you for keeping the communications open.
Bill Xsaitekpanels
Already done a while ago, waiting for what’s next.
PhM
Can plugins made be tested against 10.10R3, or was the expected the beta 11/ Final needed first? Theres some plugins I’m interested in
Chris: as I have said before: ONE COMMENT!!
64-bit plugins cannot be tested against 10.10 and they cannot be linked against the 2.1 SDK. Plugin authors can’t get past the compile stage until there is a new SDK and they can’t run without a beta of 10.20 in 64 bits.
No news and nothing to announce on ETA – as I have said before: please do NOT repeatedly ask about ETA on the blog; future “are we there yet” comments will be deleted.
others have asked about the eta. it would help us users know what to expect. frustrating to use x-plane when it constantly has crashes / indefinite wait which usually ends up being much longer than hoped for. Can;t you just say if it is likely to be weeks or few months or even not till 2013? Nothing finite, just an idea for encourage users holding off for 10.20 I and many see this is a major page turner for xplane eye candy wise and 64bit. A little insight to when and images of art assets would do all well.
I’m going to take a day off from coding and copy and paste every comment you’ve ever made on this blog into one long document so you can see what a broken record you are. 🙂 Your anxiousness is understandable, your excitement is admirable but seriously you need to stop asking ETAs. Developers need a heads up so they can have their plugins ready to go. These developers who follow this developer’s blog will get this information as soon as we feel its trust worthy. Users need to know when its available exactly one second after we make it live.
you don’t have to do that, alright. developers developer developers. Trying to not inquire as others do also, however it is just un assuring in an infinite wait with no details of when the sim will be functionally enhanced greatly and visually enhanced, a few images of art assets would be great. We have been waiting since the March post on City visuals. Which of course, seem to need 64bit to run memory wise. x-plane is my favorite software as is many others, that is why idling in wait with significant drawbacks going on without knowing more details is unappealing. Just hope its not far out. In the mean time I have downloaded some developer tools to try an learn how to use them and such to get better understanding of projects from that side of the fence.
Have a good day
Thank you,
We tell everyone else the same thing I’m telling you…it’s just that they only have to be told once. We do not give out dates until we’re fairly certain of them. We do not provide screenshots until we’re fairly certain that they’ll be indicative of what we’re actually going to ship. When we do have these details, we release them here…the fact that you have not heard anything or seen anything means it’s not ready to be disclosed yet.
alright yeah that makes perfect sense Chris, hate to show images of what may not ship and be wrong about the date by a year! again like v10 release. so fair enough, just hope it doesnt come to that. Still this is a hard to be patient for patch due to all the goods and problem fixes with little info. I and many others cant say enough to please make it fast.
Holding steady till info and release. Thanks, good night, no need to delete or worry about follow up negative comments or
are we there yet”?
Give the developers a break, would you? I’m also interested in screenshots and tech info but that will come when the time is ready.
yes yes, ok. nice to read 10.10 is final though, let 10.20 progress ramp up.