Compiling Netfix

[TH300]

I thought that it could possibly be helpful if I were able to build my own NetFix with added debug features (such as packat dumps).

I managed to build ForcedExports.lib and compile the NetFix sources into obj files. But when linking, I'm getting a lot of those:

Code: [Select]

OPUNetTransportLayer.obj : error LNK2016: Absolute symbol '?scr_snprintf@OP2ForcedExport@@YAHPADIPBDZZ' used as target of REL32 relocation

I am using Codeblock with the VC++ Toolkit 2003. For the forced exports library I also used recent nasm.

[Hooman]

I use Visual C++ 6.0. I've never encountered this error before, but I suppose it doesn't surprise me too much. It might be there is more strict error checking with new compilers that don't like what I was fooling it to do. I have felt the linking issue with the ForcedExports project needs to be better dealt with though. I just haven't found a particularly favourable solution.

I've done some experiments trying to get a solution that worked in C++ alone, and would have natural syntax for users of the library. I sort of got that to work, but trying to define the export addresses became exceedingly painful. I also wanted a solution that would handle relocations. I was trying to solve those last two problems when I last worked on it.

I believe Arklon was also working on a fork of the library with similar goals, but I don't recall the details anymore.


I suppose some of those concerns could be handled easier if I had settled for pointer syntax rather than reference syntax, but this pushes a bit more on the users of the library. I'd welcome any thoughts people have on the issue. My time to work on things as of late is somewhat limited, and I'm not really expecting that to change very much, although, it should get a little better soon.
 

[TH300]

I use Visual C++ 6.0.

That solved the issue for me. Thanks.

A bad solution, but it compiled. And it works. Outpost2 loads it, at least, without errors.

Edit: using the linker option "/force" with the VC++2003 linker will still show errors, but output a working dll

I suppose some of those concerns could be handled easier if I had settled for pointer syntax rather than reference syntax, but this pushes a bit more on the users of the library. I'd welcome any thoughts people have on the issue. My time to work on things as of late is somewhat limited, and I'm not really expecting that to change very much, although, it should get a little better soon.

I like how force-exported classes can be used just like all other classes. That shouldn't change.

[Arklon]

I believe Arklon was also working on a fork of the library with similar goals, but I don't recall the details anymore.

Mine worked as a DLL that replaced the Export Address Table of Outpost2.exe in memory. (Well, technically, the original EAT is still there in memory, I just allocate some memory to put the new EAT in and change the exe's header in memory to point to the address of the new EAT.)