I want/need to use "appLoadFileToArray" for loading a .dds into memory so I can check if it's a proper magic number, and load it into a buffer and so on..

Is there some proper way to trick the compiler to link properly for UT binaries?

If not, a workaround would suffice for this instance.

Despite.. why don't you use a UFactory?

Can you post the link erorrs? I'm not at home and right now have no access to msvc 2013...  I suggested the UFactory as you already get the file data passed in and you wont need to use the appLoadfimetoarray this way. Otherwise you could use the filemanager to geg the filesize, appalloc and Ar.Serialize( ptf, size ). Or directly create the appropreciate structures for serializing the header.

1>TextureMergerMain.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall TArray<unsigned char>::Remove(int,int)" (__imp_?Remove@?$TArray@E@@QAEXHH@Z)
1>TextureMergerMain.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall TArray<unsigned short>::Remove(int,int)" (__imp_?Remove@?$TArray@G@@QAEXHH@Z)
1>TextureMergerMain.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __thiscall TArray<unsigned char>::AddItem(unsigned char const &)" (__imp_?AddItem@?$TArray@E@@QAEHABE@Z)
1>TextureMergerMain.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __thiscall TArray<unsigned char>::Add(int)" (__imp_?Add@?$TArray@E@@QAEHH@Z)
1>TextureMergerMain.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: unsigned char & __thiscall TArray<unsigned char>::operator()(int)" (__imp_??R?$TArray@E@@QAEAAEH@Z)
1>TextureMergerMain.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall TArray<unsigned char>::~TArray<unsigned char>(void)" (__imp_??1?$TArray@E@@QAE@XZ)
1>TextureMergerMain.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall TArray<unsigned char>::TArray<unsigned char>(void)" (__imp_??0?$TArray@E@@QAE@XZ)
1>TextureMergerMain.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: unsigned short & __thiscall TArray<unsigned short>::operator()(int)" (__imp_??R?$TArray@G@@QAEAAGH@Z)
1>TextureMergerMain.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall TArray<unsigned short>::~TArray<unsigned short>(void)" (__imp_??1?$TArray@G@@QAE@XZ)
1>TextureMergerMain.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall TArray<unsigned short>::TArray<unsigned short>(void)" (__imp_??0?$TArray@G@@QAE@XZ) 

[]KAOS[]Casey wrote on Sep 7^th, 2016 at 12:21am:

The first question is: why are definitions of all these template specializations have to be obtained from dll? Why do you suppress implicit instantiation of these specializations?

The second question is: what code do you use to instantiate and export these specializations (for the given lists of template arguments) in that dll?

ENGINE_API is just a macro which is expanded to __declspec(dllimport). When applied to a class, it is automatically applied to all its member functions. When applied to a member function of a class template, implicit instantiation of definition of the given member function will be suppressed, because the definition of a member function of a class template specialization is then supposed to be obtained from an external library. If external library does not provide the definition having exactly the same signature (which is distinguished by mangled function name), linking to the function fails.

When a member function of a class template is declared with dllexport (which can be achieved by declaring the whole class with dllexport), presence of the generic definition of the function is not sufficient for exporting any of its specializations. If you want to export a specialization (an instance) of a member function of a class template with a particular template-argument-list, you have to instantiate it. I don't remember if implicit instantiation is enough, but explicit instantiation should work. For a particular function it would be something like this:

template void TArray<unsigned char>::Remove(int, int);
// instantiates the definition of the member function of TArray<unsigned char> from the generic definition 

It is also possible to explicitly instantiate the whole class:

template class TArray<unsigned char>;
// instantiates the whole class TArray<unsigned char> from the class template definition 

Not sure if __declspec(dllexport) has to be present in either case.

Now about removing ENGINE_API. By removing __declspec(dllimport) for a particular function you allow implicit instantiation of the function definition from the generic definition available in the corresponding header file (so the current module will use its own definition of the function rather than expect that an external library will provide it). Then you must ensure that if several modules operate on the same object, the operations are consistent across modules. In particular, all modules shall use the same heap for memory allocations and deallocations.

han wrote on Sep 7^th, 2016 at 2:27pm:

I never worked on native mods for Unreal/UT, so I can't tell how much the existing code base of U/UT relies on the specific behavior of MSVC 6. Nevertheless, I worked with MSVC 6 per se, and, from what I remember, it's an old piece of sh... with a lot of bugs and poor support of C++ features (even for '98 year) - especially with regard to templates. Nowadays I can't consider it other than as a museum specimen. Modern compilers offer much better language support and quality of generated code.

han wrote on Sep 7^th, 2016 at 4:08pm:

That library covers very few needs, and, for example, where possible, I'd rather use C++11/14 std::vector instead of nonsense like TArray.

Quote:

You probably used a very small subset of language features. I faced with compiler bugs regularly. Sometimes compiler just crashed when trying to compile a valid code. In some cases I got hard-to-find bugs in compiled programs due to erroneously performed overload resolution or missing initialization of objects that had to be done according to the language rules.

Quote:

I don't think so. Optimizers were improved a lot since those ancient times. E.g. new compilers can inline more functions. IIRC, link time code generation was not supported by VC++ 6 at all. Better inlining alone already can give a noticeable performance boost.

Quote:

I wonder what problems could arise there. Does that old code base rely on specific compiler bugs and/or undocumented behavior so much or what?