dll call ???

[AlienStar]

hello everybody

I've read this topic about creating dll files in vb.net

http://www.trap17.com/index.php/ways-create-dlldll-vbnet-part-1_t62071.html

now after doing that how can I call it from autoit ???

thanks for help

[PsaltyDS]

DllCall()?

[Richard Robertson]

AutoIt cannot call .Net dlls.

[bo8ster]

AutoIt cannot call .Net dlls.

I had no idea.

Why not? What is different with a .net dll compared to the user32.dll?

Are there any other restrictions?

[AlienStar]

where is the problem when using like this

DllCall("user32.dll", "int", "MessageBox", "hwnd", 0, "str", "Some text", "str", "Some title", "int", 0)

but changing user32.dll to any dll ??

and what is the deference between .Net dll and others ??

Edited December 17, 2009 by AlienStar

[Authenticity]

.NET dll is not compiled into executable byte code but into intermediate code called MIL (Microsoft Intermediate Language) or just IL which the .NET interpreter then convert to machine code specific to the machine the .NET program is running on. What this implies is that the structure of the .NET dll is different than the structure of Win32 executable dll. In short you can't call LoadLibrary and then GetProcAddress because these functions do not recognize the .NET dll as a Win32 executable dll. I might be wrong though.

[Richard Robertson]

Authenticity, you are close enough to being right.

Also, .Net is object oriented, which means that no functions can be called without an object reference. You would have to have the assembly registered as a COM object (not hard to do) and use COM to access the objects.

[Authenticity]

For my limited knowledge about IL, many things that cannot be done in any of the .NET language can be done in IL. For example, global variable, IL code encryption and much more. So I guess that global functions are well possible but require coding in IL only which in turn requires solid understanding of IL and the file structure. Correct me if I'm wrong.

[ProgAndy]

For my limited knowledge about IL, many things that cannot be done in any of the .NET language can be done in IL. For example, global variable, IL code encryption and much more. So I guess that global functions are well possible but require coding in IL only which in turn requires solid understanding of IL and the file structure. Correct me if I'm wrong.

Right. There even were some efforts in the german forum to modify the IL code in order to have it callable by native Code. This resultet in a small app to do this.

I think, it is based on an article like this one on CodeProject.

Edit: You still need .NET-framework in order to use the dll.

Edited December 17, 2009 by ProgAndy

[AlienStar]

thanks all for help and attention

I think it's closing to be little difficult

is there any way easier than this ??

even if I had to use another language ( no problem )

I just wanna make dll files including simple functions

thanks again

[JohnOne]

thanks all for help and attention

I think it's closing to be little difficult

is there any way easier than this ??

even if I had to use another language ( no problem )

I just wanna make dll files including simple functions

thanks again

Glad you like the attention allen, you are a star.

To answer your question there is nothing easy about dlls to those of us who are not familiar with them.

Just stick with the learning curve and it will come, there are no shortcuts.

[Richard Robertson]

Yes, IL does permit the use of global functions. However IL is still not callable because it isn't technically compiled.

[AlienStar]

@JohnOne

thanks for nice words you've embarrassed me

Not hand trick

I've to learn more about dll's after that doing like these works

thanks for all anyway

Edited December 17, 2009 by AlienStar

[bo8ster]

.NET dll is not compiled into executable byte code but into intermediate code.

Thanks, I guess it does not always do JIT compiling. Something has to force the JIT compiler?

Also, .Net is object oriented, which means that no functions can be called without an object reference.

Don't really get why object oriented is a factor. Moving .Net aside, is there really a difference between a Standard C (with a structure and functions) and C++ (with a class and (public) member functions) in a compiled dll? One does not have OO and the other does but I wouldn't expect the computer knows the difference once compiled into machine code. Or is this .Net specific?

Edit: Added the public clause.

Edited December 21, 2009 by bo8ster

[jchd]

Don't really get why object oriented is a factor. Moving .Net aside, is there really a difference between a Standard C (with a structure and functions) and C++ (with a class and (public) member functions) in a compiled dll? One does not have OO and the other does but I wouldn't expect the computer knows the difference once compiled into machine code.

Let's move .NET alone since it's something else entirely.

The big difference between C and C++ (from the point of view of mixed calls between both) is just OO. A C program will know nothing about the methods that need to be invoked to perform any action with/on any object. There are zillions of ways to implement an object like, say a DAG (directed acyclic graph). How could a C program do anthing with/to a DAG object if one is passed by ref on the stack? Trying to butcherize inside the object would lead absolutely nowhere but segfault or worse. C can't imagine there is a whole inheritance tree behind a given object because such things are just beyond C possibilities.

[bo8ster]

I understand OO well, but does it make a difference when calling the dll?

In code it is important as a member function is apart of the object but I am not talking about code.

[trancexx]

I understand OO well, but does it make a difference when calling the dll?

If we talk about DllCall() then no, there is no difference.

Regardless of what language is used for writing or what technique is used to write, if they do the same thing (it should be clear what I'm saying here) they will be turned to similar set of instructions. Incredibly similar.

I said turned and not compiled because the C# code will also end that way eventually.

[jchd]

I understand OO well, but does it make a difference when calling the dll?

In code it is important as a member function is apart of the object but I am not talking about code.

It makes several big differences. First, C++ functions names are "mangled". Google for that to find out.

Now, if you're not talking about code, what else? Describe a practical situation involving C calling C++. Note that you can call C functions from C++ without any problem.

If you're talking of DllCall-ing a C++ dll from AutoIt, then which "object" are you going to pass back and forth and where do you think the method code will reside?

If you pass a reference, say, a void* (ptr) then what will that pointer be refering to? How would you create an object in AutoIt if it isn't a native AutoIt type? If the object is created by the dll, then how can AutoIt know how to deal with it? Either situation, you have to violate the encapsulation (at the very least), which is an absolute no-no because it defeats the very purpose of OO in the first place.

[danielkza]

It makes several big differences. First, C++ functions names are "mangled". Google for that to find out.

Name mangling was added to C++ because of function overloading, not OO.

Now, if you're not talking about code, what else? Describe a practical situation involving C calling C++. Note that you can call C functions from C++ without any problem.

Simple one: a C program using AutoItX.

If you're talking of DllCall-ing a C++ dll from AutoIt, then which "object" are you going to pass back and forth and where do you think the method code will reside?

If you pass a reference, say, a void* (ptr) then what will that pointer be refering to? How would you create an object in AutoIt if it isn't a native AutoIt type? If the object is created by the dll, then how can AutoIt know how to deal with it? Either situation, you have to violate the encapsulation (at the very least), which is an absolute no-no because it defeats the very purpose of OO in the first place.

You can (and probably should) use opaque handles in these situations, when you need to cross {language|address} boundaries.

[bo8ster]

It makes several big differences. First, C++ functions names are "mangled". Google for that to find out.

Now, if you're not talking about code, what else? Describe a practical situation involving C calling C++. Note that you can call C functions from C++ without any problem.

If you're talking of DllCall-ing a C++ dll from AutoIt, then which "object" are you going to pass back and forth and where do you think the method code will reside?

If you pass a reference, say, a void* (ptr) then what will that pointer be refering to? How would you create an object in AutoIt if it isn't a native AutoIt type? If the object is created by the dll, then how can AutoIt know how to deal with it? Either situation, you have to violate the encapsulation (at the very least), which is an absolute no-no because it defeats the very purpose of OO in the first place.

I think you totally missed by point, I think trancexx is more on the ball with what I am referring to. From what I understand (and I could be totally wrong) C and C++ code get compiled down to basically the same thing - so if you look at the assembly or machine code there would be really no difference between them. Concepts like OO, encapsulation only apply when creating the dll and have no meaning to the computer only to the compiler and the coder.

I raised the point to address Richard's comment and he is correct in his statement but I don't see how a dll being OO or not should make any different in calling it. The API will dictate what is required regardless of how it is implemented.

Edited December 22, 2009 by bo8ster