Fix Heap Alloction issues in QTFred

[TheForce172]

There have been multiple heap crash issues with QTFred on that have been traced to the fact that QT Distributes its libraries with dynamic linking while we are using static linking. We most likely can't distribute statically linked version of QT due to licencing issues between QT and FSO's licenses. So are only option is to compile dynamically if we are building QTFRED.

[JohnAFernandez]

I don't think anyone else is going to look at this. Hold on to your butts.

[wookieejedi]

Given Cyborg approved and TheE says it looks fine, I'll plan to merge tomorrow.

[Goober5000]

This does look like the best solution, from a design standpoint, but this PR only touches MSVC. We'll need to build QtFRED dynamically regardless of whatever build environment we use or what OS we build on.

[notimaginative]

This does look like the best solution, from a design standpoint, but this PR only touches MSVC. We'll need to build QtFRED dynamically regardless of whatever build environment we use or what OS we build on.

I'm pretty sure this is an issue specific to MSVC (or using that toolchain). So this shouldn't be a problem on other platforms and/or toolchains. I'm not sure whether it applies to cross-compilation though (don't think so?).

[Goober5000]

This does look like the best solution, from a design standpoint, but this PR only touches MSVC. We'll need to build QtFRED dynamically regardless of whatever build environment we use or what OS we build on.

I'm pretty sure this is an issue specific to MSVC (or using that toolchain). So this shouldn't be a problem on other platforms and/or toolchains. I'm not sure whether it applies to cross-compilation though (don't think so?).

But licensing issues would apply regardless of platform. Or do the other platforms already link dynamically?

[notimaginative]

This does look like the best solution, from a design standpoint, but this PR only touches MSVC. We'll need to build QtFRED dynamically regardless of whatever build environment we use or what OS we build on.

I'm pretty sure this is an issue specific to MSVC (or using that toolchain). So this shouldn't be a problem on other platforms and/or toolchains. I'm not sure whether it applies to cross-compilation though (don't think so?).

But licensing issues would apply regardless of platform. Or do the other platforms already link dynamically?

Oh no, this isn't about linking with Qt, it's about how linking is done with the Windows runtime. Qt links the Windows runtime dynamically, while FSO links it statically. And you can't safely mix the two methods. And it's much easier to just change how FSO links than Qt does.

[Goober5000]

Ok, fair enough.

EDIT: A quick search shows that MSVC_USE_RUNTIME_DLL is used in several places across the codebase, including to determine whether MFC itself is linked dynamically. I'm wondering if MSVC_USE_RUNTIME_DLL should be set based on FSO_BUILD_QTFRED, rather than adding this one special case here.

[MjnMixael]

What needs to happen to move this one forward?

[wookieejedi]

KNet associated PR has been merged, so we can plan to merge this once the next KNet version is out. Per Goober's inquiry about if MSVC_USE_RUNTIME_DLL should be set based on FSO_BUILD_QTFRED on Discord, taylor stated the following in response to Personally, no, I don't think it should do that. Primarily since FSO would use a different runtime depending on whether FSO_BUILD_QTFRED was enabled and might affect debugging and ability to reproduce bugs. But I'm not up on Windows internals enough to confidently say it would be a problem

[wookieejedi]

Update, next KNet version is planned to come out in about two weeks, so will plan to merge this PR when that happens as noted above.

[wookieejedi]

Given discussion here and on Discord, approving and will also dismiss stale reviews and plan to merge once KNet 1.3.5 releases in the near future.

[Goober5000]

I had lost track of this PR, so it was good to get the ping. Given Taylor's response, I'm happy to approve it.

[wookieejedi]

KNet 1.3.5 is out so will merge this later today, thanks all!