Re: Need help with decoding and understanding bgt's network implementation
OK, so to clear things up a bit
yeah, bgt can't in any way, form or shape access dll structs reliably. Note here that I say reliably because, as my previous posts on the matter show, it's possible, but in a very hacky and horible way which I won't recommend to try, even to my most vicious enemies.
now, about a dll written in c# being accessed from any non .net language, I'd suggest you better forget about it. As @camlorn said, you should better try to implement a unix stile socket for the separate c# executable to communicate the required data to the main application, piping the stdin and stdout through it. I guess the windows specific version of this is a named pipe? I am really not sure anymore, to be honest.
If you, however, really want to bite the bullet and try making a c# dll be called by other programs, there is a way, though I can't write in words just how much I disscourage even thinking of it, like, if you want to do such a thing, better do us all a favour and go learn rust or something. Let's say that I'm putting this here just for completeness sake, kind of just for giggles. So kids, don't try this at home! lol
so, this is basically a thing where you tag your function with a DllExport attribute, like you would do in normal p-invoke, I guess that's what you were refering to with reverse p-invoke, @14.
For the curious, this adds x86/64 assembly in your c# dll, starting from the fakt that a c# dll is not so different from a regular one written in c++ or something like that. So, I guess it wraps your function in some custom assembly to manually load some clr thing, then pass controll to it with the recieved parameters from unmanaged code, if I remember correctly.
Limitations:
As with anything in this world, there are some limitations, some obvious, some not.
1. No recurssion. I sincerely don't know why is it so, but I guess that due to the way the function got called, it doesn't know its own address, so can't call itself.
2. Only x86/64. Because only this kind of assembly is supported by the author, it won't work by just changing to any cpu and end of the problem.
3. I guess it only supports .net framework, but because of what you're using that for, I guess that's not so big a problem if you were willing to jump to this in the first place.
4. The only relevant info I found about it is three or four years old. That makes me seriously think it's unsupported, so use at your own risk!
sources:
https://bountify.co/call-c-dll-from-c-application
that's it. So you can see, again, how obscure this is.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
