Delta Virtual Airlines Water Cooler - P3Dv4 - Why aren't things compatible?

Delta Virtual Airlines Water Cooler | PC Support | P3Dv4 - Why aren't things compatible?

DVA3220
Captain, B737-800
OLP

Joined on May 19 2006
DVA Five-Year Anniversary
B737 50 Club

Southeastern United States

78 legs, 129.9 hours
73 legs, 122.3 hours online
76 legs, 127.3 hours ACARS
31 legs, 57.3 hours event

Posted onPost created on June 01 2017 13:54 ET by Tyler Devereaux

Hi. I know this is a stupid question, but I haven't really been able to find a concise answer -- most links I click on lead to troubleshooting specific issues rather than theory.

Why would things -not- be compatible with P3Dv4? I get that it's 64-bit. I thought I was fairly knowledgeable about architecture and computer hardware, but I'm either having a really dumb moment or I'm a lot more clueless than I thought I was. What's the missing link here? I've spent an hour or so now digging through the internet, but I haven't found an article that really applies to my question. As I understand it, WOW64 allows Windows to do its magic to seamlessly run the vast majority of applications that are 32-bit, and provide them with the environment they expect. So, that's why we can still run pre-v4 FS. I also read that it's not only possible, but quite common for 64-bit apps to contain 32-bit code. It seems like our systems very routinely handle 32- and 64-bit processes and code without issue.

So why does P3Dv4, being compiled as a 64-bit process, automatically break everything and require developers to produce compatibility updates? Why doesn't the aforementioned black magic allow the 32-bit addons to mingle with v4 by default?

Obviously, I understand the benefits of producing 64-bit addons. I just don't understand why the existing 32-bit ones won't work.

Thanks!

DVA043
Senior Captain, MD-11
OLP

Joined on June 10 2001
Event Half Century Club
Online Double Century Club
50 State Club
DVA Twenty-Year Anniversary
Everett 1500 Club
Bi-Millennium Club
Four Million Mile Club

"Col. Panic"
Marietta, GA

2,324 legs, 9,352.8 hours
240 legs, 553.9 hours online
1,982 legs, 8,145.9 hours ACARS
75 legs, 196.3 hours event
2,360 legs, 9,487.7 hours total
91 legs dispatched, 66.4 hours
CURRENTLY LOGGED IN

Posted onPost created on June 01 2017 16:08 ET by Luke Kolin

Tyler Devereaux wrote:

I also read that it's not only possible, but quite common for 64-bit apps to contain 32-bit code. It seems like our systems very routinely handle 32- and 64-bit processes and code without issue.

This is the part that's incorrect. At a process level, you're either 32-bit or 64-bit. In the 32-bit world, processes are either 32-bit or 16-bit; x64 drops support for Virtual X86 mode so if you want to run 16-bit windows apps on an x64 operating system you need to run Windows XP in a virtual machine.

That's what breaks things; GAU files are just DLLs, and those need to be 64-bit in order to be loaded into a 64-bit processes' address space. It's why ACARS, despite being a .NET app that could run in 64-bit mode without ANY recompilation, is explicitly 32-bit because the Level-D shim DLL we use is 32-bit only.

Cheers!

Luke Kolin

Senior Captain, MD-11

Posted onPost created on June 02 2017 17:28 ET by Tyler Devereaux

Luke Kolin wrote:

Tyler Devereaux wrote:

I also read that it's not only possible, but quite common for 64-bit apps to contain 32-bit code. It seems like our systems very routinely handle 32- and 64-bit processes and code without issue.

This is the part that's incorrect. At a process level, you're either 32-bit or 64-bit. In the 32-bit world, processes are either 32-bit or 16-bit; x64 drops support for Virtual X86 mode so if you want to run 16-bit windows apps on an x64 operating system you need to run Windows XP in a virtual machine.

That's what breaks things; GAU files are just DLLs, and those need to be 64-bit in order to be loaded into a 64-bit processes' address space. It's why ACARS, despite being a .NET app that could run in 64-bit mode without ANY recompilation, is explicitly 32-bit because the Level-D shim DLL we use is 32-bit only.

Cheers!

Thanks so much for the explanation. That makes sense. I guess, in my ignorance, I thought it was possible to design an app (64-bit) that "uses" components without necessarily "consuming" them, but I guess this isn't the case. I was thinking that the app could "execute" (or otherwise "activate") the 32-bit gauges and let them do their thing in an isolated (32-bit) manner, just providing their result back to the 64-bit app.

Thanks!

For flight simulation purposes only. Not a commercial website. In no way are we affiliated with Delta Air Lines, its affiliates, or any other airline. All logos, images, and trademarks remain the property of their respective owners. Delta Virtual Airlines is a non-profit entity engaged in providing an avenue for flight simulation enthusiasts.