Ideas for API improvement

[Dal]

NWNX is great, but I'd like to discuss a few refactoring ideas for the NWNX API..

1) Making the NWN process DLL injection and hooking a responsibility of the DLL itself - where it rightly belongs, rather than in the GUI/watcher - would make things easier for 3rd parties who want to develop alternatives: Server manipulation over the web, windows services, etc. (Or atleast prettier by removing the inelegance of them having to in link the madcodelib as well as nwnx-dll)

2) Some linkable way of overriding the PayLoad (or parts of it) would allow a more efficient way to interop with .NET (and maybe Java)

None of this should conflict with the existing NWNX plugins, but open up a lot more possibilities. This probably doesn't sound very important, but it'd make my day

[JeroenB]

1) It is not possible to make the DLL link itself dynamically to the server process. NWN doesn't realy do anything with the DLL, so it will not load it, or use any functions in it at all. So, there must be an external program that loads it for you in the NWN process, otherwise it keeps sitting there doing nothing.

2) That might be an idea, but is difficult for several reasons. The most important part is that NWNX DLL is written in C, not C++. It is written to optimise speed, which is not possible when going to overload etc. What you can do it writting your custom plugin thta handles .NET (somebody else already wrote an java plugin).

But it is great that you come up with idea's! Keep that going

[Dal]

1) In 10 minutes I'v just moved the process-handling global functions from the NWNX exe project into the NWNX-module DLL, added a .def file exposing them and now the server process starts fine.

I am getting an unhandled exception from the DLL - after return - I presume it's down to the __std calling convention unless I'm missing something.

- .NET process watcher P/invokes StartServerDummyThread
- StartServerDummyThread uses MadCodeLib's custom CreateProcess to start and inject. (no error returned)

An alternative I'v played with is interoping with both the MadCodeLib and NWNX, but this is incredibly messy since I have to reconstruct internal Win32 structures (such as STARTUPINFO and PROCESS_INFORMATION), which I have a feeling foreits my platform-independence.

2) I have difficulty distinguising between C and C++ (Until I see Mallocs, which I dont in this case), but surely it'd not slow things down to add one extra function pointer, and some external definitions to access it.

Thanks for your response.

[JeroenB]

About the first point. Could you tell me how the DLL is loaded? If you have sources available, I would be very interested in this.

EDIT: now I see, I read you post wrong
Yes, it's ofcourse possibe to move the code to the DLL, but that is not so elegant as you think. I assume you load the DLL also in NWNX so that the hooking procedure can be started, the DLL won't do that itself as I stated above. And linking an extra library isnt a very bad habit.

[Dal]

Right, I'll explain myself a bit better:

Dot NET apps are compiled into something called the Common Language Runtime (CLR), this is interpretted when the app runs but turned into native code (ie. a x86, win32 application) rather than staying in a slow byte-code VM. As a result, it is difficult to simply link normal native code to it, since it is not in any recognisable form. The easiest alternative -I can find- is to have the CLR client application tell a natively compiled application (NWNX for Windows) what it should link to by linking to it first, ie. marshalling it a function pointer to the now-running CLR application.

So, a .NET client executible is a requirement to get a .NET plugin working. The .NET executible would either have to be run at the same time as the normal NWNX, or do the job of NWNX (start the process). As I mentioned earlier, that'd forfiet platform independence: Unless the NWNXdll did the job of NWNX instead; I claim this is elegant whether it was done for the reasons mentioned above or not, since it would isolate functionality into nice application layers.

I'd have no problem having a seperate app for private use, but i'd never release it publicly.

[Dal]

Ok, seems I misunderstood a few things too. The NWN and NWNX client processes aren't related at all, so function pointers are out. At the moment I'd have to use named pipes or something similar to pass on the NWNX.net commands.

I think I'll investigate those java plugins, write a .net equivelant.. and a nice little background service to delegate things out.

Thanks for the chat.

[JeroenB]

No problem! If you manage to build something like this, I would be very interested in to give it try. I never used the .NET languages (only native language).

I would also be interested in speed measures as the .NET code is interpreted. I would expect some decreases in speed. You might also want to compare it with Java

Good luck!