def file is outdated
def file is outdated
CreateIpcQueue@8 = CreateIpcQueue @36;
CreateIpcQueueEx@16 = CreateIpcQueueEx @47;
While code defines a different function:
_imp__CreateIpcQueue@24
And these functions are not there anymore: CreateIpcQueueEx, SetInjectionMethod
CreateIpcQueueEx@16 = CreateIpcQueueEx @47;
While code defines a different function:
_imp__CreateIpcQueue@24
And these functions are not there anymore: CreateIpcQueueEx, SetInjectionMethod
Re: def file is outdated
As well function InitializeMadCHook and function FinalizeMadCHook are not exposed in def file
Re: def file is outdated
I think I should delete the def file, anyway. Or do you have any use for it? Many years ago I offered a madCodeHook DLL version, but it proved to be a very bad idea because malware devs just copied that dll and misused it for their bad purpose. So I got rid of the madCodeHook DLL many years ago. So the def file should be mostly useless now, or not?
Re: def file is outdated
I use this def file with some fixes of course
Currently, I have C++ project which just exports MadCodeHook API and C# program which uses MadCodeHook.
This way I need only dll in C++ and the rest code can be in any language I want.
Currently, I have C++ project which just exports MadCodeHook API and C# program which uses MadCodeHook.
This way I need only dll in C++ and the rest code can be in any language I want.
Re: def file is outdated
No, *PLEASE* don't do this!!!
I understand why you'd want to do it, but it's really bad for me, and it isn't allowed by the madCodeHook license agreement.
Let me explain: If you create a DLL which exports the madCodeHook APIs, then basically any malware developer could just copy your DLL and distribute it with the malware and call the APIs and he'd have full access to the whole madCodeHook functionality! And it's not even limited to malware misuse: Basically any developer (malware or not) could just copy your DLL and have full unlimited access to madCodeHook.
This is why the license agreement says:
I'm sorry for the inconvenience, but I'm sure you understand why I have to insist on this, right?
I understand why you'd want to do it, but it's really bad for me, and it isn't allowed by the madCodeHook license agreement.
Let me explain: If you create a DLL which exports the madCodeHook APIs, then basically any malware developer could just copy your DLL and distribute it with the malware and call the APIs and he'd have full access to the whole madCodeHook functionality! And it's not even limited to malware misuse: Basically any developer (malware or not) could just copy your DLL and have full unlimited access to madCodeHook.
This is why the license agreement says:
I do understand the problem with C++ vs C# etc. I have no problem with you creating a helper DLL in C++ and accessing it from C#, but you need to be careful not to make the general purpose madCodeHook APIs available like that. What you could do is export a function in your DLL like "CreateIpcQueue()", but without most the parameters. You'd hard code most of the parameters in the C++ DLL. This way your DLL could only be used to create an IPC queue with one specific IPC name. Or you could export a function like "LoadDriver()", but without any parameters, and the driver names and paths would be hard coded in the C++ DLL. Etc etc. By hard coding most of the parameters, you can still achieve your goal of making madCodeHook available to C#, but at the same time you're not making it possible for other developers to just copy your DLL and make use of the full madCodeHook functionality for their own (good or bad) purposes.The products owned by the licensee into which the licensed software is built does not offer any ways for third party developers to get access to the functionality of the licensed software.
I'm sorry for the inconvenience, but I'm sure you understand why I have to insist on this, right?
Re: def file is outdated
Thank you for clarification.
What is the purpose of def file then ? Shoudn't it be removed from the package ?
What is the purpose of def file then ? Shoudn't it be removed from the package ?
Re: def file is outdated
Thanks for your understanding. I suppose it should be removed. At least I don't see a purpose right now.