14 hours ago, Egbert Drenth said:

Only add-ons containing C++ programming code (and interacting with P3D) have to be migrated, all others not (like scenery)
Except of course updated installers.

In the past no one has said that all add-ons needed to be migrated.
Also LM apparently decided to keep the legacy BGL files and not develop a whole new scenery graphics engine (yet?)

 

It's not C++, it's DLL's (in whatever language - usually C++) used by the P3D exe that have to be converted from 32-bit to 64-bit.  Add-ons that are exe's do not have to be converted to 64-bit.  The coatl.exe from FSDT and the AS16.exe from Hi-Fi Tech for P3D v4 are still 32-bit apps.  

You can see if a running app is 32 or 64-bit in Task Manager.  In Windows 7 there will be *32 after the executable name.  In Windows 10 it will have (32 bit) after the executable name.  Another way without starting the app is to open the properties on the .exe and look at the Compatibility tab.  If there's nothing older than Vista in the list then it's 64-bit.  If you see XP, ME, 98, etc. then it's 32-bit.

12 hours ago, LRW said:

It's not C++, it's DLL's (in whatever language - usually C++) used by the P3D exe that have to be converted from 32-bit to 64-bit.  Add-ons that are exe's do not have to be converted to 64-bit.

Yes and no...

The 'in-process' dlls, running insight the P3D framework need to be converted anyway (and these dll's are written in C++ by definition since P3D in written in C++).
Most likely the out-of-process executables too, because they interact/interface with P3D too. Most likely these interfaces go directly to memory addresses locations and those have changed in P3D

4 hours ago, Egbert Drenth said:

Yes and no...

The 'in-process' dlls, running insight the P3D framework need to be converted anyway (and these dll's are written in C++ by definition since P3D in written in C++).
Most likely the out-of-process executables too, because they interact/interface with P3D too. Most likely these interfaces go directly to memory addresses locations and those have changed in P3D

A C++ executable can call a C DLL, although the C++ would have to use extern 'c' which I think is unlikely.  That's why I wrote "usually C++".  Although with .NET the managed DLLs can be in C++, C#, or even VB.

I'd be surprised if there were any add-on exe's using direct memory access to P3D.  I think that would require P3D to create named shared memory objects.  I haven't come across any of those in the SDK.  P3D expects external processes to use SimConnect.  Do you know of any that are doing something different?

I'm a lead engineer of a big software project. Here's the thing: both sides are correct. I'll speak to two things, the internal P3D architecture and external parties.

C++ is what is called an unmanaged language. In other words, the programmer has to specifically allocate memory for things as well as explicitly tell the program to unallocate those things. This is where the term "memory leak" comes from: the programmer has allocated objects, but later has forgotten to delete them. In managed languages (Java, JS, C#, Python, etc), the deletion of objects is taken care of for you. When nobody is using those objects anymore, a process called the garbage collector comes in and deletes them. It's all obviously hugely more complicated than that, but that's the general gist from FL350. C++ guys know that there are newer ways of dealing with this stuff these days with smart pointers and other things, but I'm going to stick with the basics.

In a 32bit application, you have chiefly two limitations:

• The magnitude and/or precision of numbers you can represent
• The amount of object memory you can grab before the allocator throws an Out Of Memory exception
• Surprise! The second limitation is actually the same as the first one.

Wait, what? That's right, 32bit memory limitation all goes back to numbers. When a process starts in Windows, Windows creates what is called a virtual address space. You can think of it as a big array of bytes, and that's the memory your process gets to access. So, if you wanted to access the memory, you could do:

byte firstByte = memory[0];
byte lastByte = memory[4294967295];

Now, this doesn't actually work in C++, as there isn't a magic array called memory. But it illustrates the problem: in 32bit land, you can't use a number higher than that. That's the maximum unsigned (only positive numbers) integer available to you. Because under the hood the memory allocator actually does work somewhat like that, and therefore once it runs out of numbers, it can't store any more bytes in memory. It has no more address space available. Once the allocator sees that all the space is used up, bam! Out Of Memory exception. Now, there are other practical limitations that mean the real space is closer to 3.5GB instead of 4, due to the kernel loading things into the front of the process memory as well as memory fragmentation.

Memory fragmentation is particularly challenging as you get close to the memory limit. For example, lets pretend my whole memory is only 8 bytes. If I have two 4 byte things I want to load, no problem, right?

1 1 1 1 2 2 2 2 <- Two items side by side

But what if I load something that's 1 byte, load 4 bytes, delete the first object, then load another 4 bytes?

1 - - - - - - - <- Loaded object 1
1 2 2 2 2 - - - <- Loaded object 2, 3 bytes free
- 2 2 2 2 - - - <- Deleted object 1, 4 bytes free
- 2 2 2 2 - - - <- Try to load object 3 (4 bytes), get OOM

Even with 4 bytes free, there aren't 4 contiguous bytes free. Trying to load another 4 bytes results in an OOM exception. We can't just move object 2, because the program may be using the pointer to that object currently, and that would cause Big Problems^(tm) with the program. This is why sometimes you get OOMs way before other times. It all depends on that specific run, and how memory got fragmented during that run. However, there's good news! Fixing the allocator to address more memory requires only one step: change the compile target to 64bit instead of 32bit, and recompile the program (and associated libraries). Now you can access 16 Exabytes of RAM! You might need a bigger case, though. That's where the "it's not so hard" camp is correct. Recompiling to 64bit is super easy.

The bigger problem is the underlying architecture. In the video game world, every collection of objects is on a pretty strict diet. So, oftentimes you would budget maximums for each kind of item. You would take an inventory and say, ok, each tree looks like the following:

struct Tree
{
  byte type;
  float x;
  float y;
  float z;
}

Each floating point position is 32bits (4 bytes), and the type is 1 byte. So, each tree is 13 bytes. Doesn't sound like a lot, but consider how many can end up on screen. Each item type is going to be tracked in the program inside some collection. Those collections are likely fixed size given how old FS is as an engine, and what kind of memory targets it was up against. Once you go 64bit, all these different budgets have to be adjusted up, and it's a balancing act, because even though you can use 16 Exabytes, it's pretty likely Joe Simmer doesn't have that kind of memory in their machine. They likely only have an 8Gb-16Gb budget.

So, you still need to come up with either algorithms to dynamically adjust the budgets, rebalance them by hand, or just deal with the fact that if someone busts the budget, they're going to be getting massive stutters when they hit the disk for swap memory. Going 64bit doesn't mean you get to ignore practical memory limitations of current machines. And dynamic management scaling algorithms are not simple stuff, and they all fight against each other. So, that's where the "it's really hard" camp is correct. The real world still exists.

From a third party side, you're supplied with a library that you can link your library or program against that supplies you with all the functions that you can call in the SDK. If the SDK DLL changes platforms (i.e. to 64bit), you need to recompile your software against the new DLL, because the actual memory locations of the SDK functions may have changed, and you need your software to run the correct code. It is also possible, although unlikely, that some vendors are dynamically loading the SDK DLL (in which case you wouldn't need to recompile), but I doubt it, as it is a ton more work for no particular benefit. This is the easy case.

However, if the SDK changed some aspect of their functions, then it becomes more difficult. This could be relatively simple, for example, a function called ChangeAircraftPosition may have taken 3 32bit floats as parameters, and now it takes 3 64bit floats (doubles). That would likely be a pretty small change. But if they change how you move your aircraft completely, then things might be a lot more difficult. This is where the "difficult" camp was going with their thinking: that the move to 64bit would also be a large API breaking situation if LM decided to make big changes.

In the end, it looks like LM chose a pretty reasonable path for third parties. The SDK API hasn't really changed, and all the various file formats still appear to be using 32bit ints and floats, as far as I can tell. So, scenery designers don't have to really do much, and people using the SDK get by with minimal effort. Most of the changes are under the hood.

3 hours ago, LRW said:

 That's why I wrote "usually C++".  Although with .NET the managed DLLs can be in C++, C#, or even VB.

What are managed DLL's?
C++ needs to be compiled, and so does C#. They are doing that in a whole different way. C# is a managed language, C++ is not.
Basically a C# dll is just a text file (open it with notepad) which is compiled to MSIL and then JIT compiled to something the CLR understands.
The C runtime doesn't understand anything of .NET related languages hence there is no way a C# 'dll' can run in process (like a module) within Flight Simulator/P3D

This discussion now gets academic, so lets leave it as it is.