12 replies to this topic

[WSCPorts]

described best at this link... who agrees?

http://www.codeproject.com/csharp/unmanagedtomanaged.asp

[w0uter]

i would like to comment but i dont know what the code does

care to give us a small rundown on how this will be usefull for autoit ?

[Valik]

If we need this feature, why is this the first time I've ever seen anybody mention it?

[WSCPorts]

ManagedCode Execution through a managed dll/exe through unmanaged autoit doesnt sound good to you?
its a basic CallManagedCodeFromUnManagedCode....
this could be that autoit .Net DllCall and ExeCall functionality that ppl are looking for
i would be most gracious if a plugin for this functionalitywhere outthere.
if anyone can help that would be great!

[WSCPorts]

This is what i get so far :/ Cause's a hard crash "the instruction at 0x00423236 referenced memory at 0x80029c4a" The memory could not be read.

heres my code

$CLSID_CorRunTimeHost = "CB2F6723-AB3A-11d2-9C40-00C04FA30A3E"
$IID_ICorRuntimeHost = "CB2F6722-AB3A-11d2-9C40-00C04FA30A3E"
$MsCorDll = DllOpen("Mscoree.dll")
Func LoadTypeLib($szFile)
    Dim $Object
    $OleAut32 = DllOpen("Oleaut32.dll")
    $Return = DllCall($OleAut32, "long", "LoadTypeLib", "str",$szFile, "long",$Object)
    DllClose($OleAut32)
Return $Return[2]
EndFunc
$MsCorTlb = LoadTypeLib("mscoree.tlb")
$MsCorLib = LoadTypeLib("mscorlib.tlb")
Dim $FarPtr
$ret = DllCall($MsCorDll, "int", "CorBindToCurrentRuntime", "str", "CorBind.xml", "str", _ $CLSID_CorRunTimeHost, "wstr", $IID_ICorRuntimeHost, "ptr", $FarPtr)
MsgBox(0, "Bind Success/Fail", $ret[4])

Here is CorBind.xml

<configuration>
   <startup>
      <requiredRuntime version="v2.0.50727.42" safemode="false"/>
   </startup>
</configuration>

Edited by WSCPorts, 27 March 2006 - 03:13 AM.

[CoePSX]

.NET is evil. We passed so much time developing better processors, faster systems, better compilation, etc and ect.

Then comes this new Microsoft product that offers an easier way to program, but also slower and totally dependant on lots of DLLs, called .NET framework. I'm sorry if i'm saying stupid things here, as I don't know much of how .NET works, but I do know you have to download lots of files for .NET compiled programs to work. It would be just fine if all those DLLs came with most versions of windows, like kernel32.dll and user32.dll.

AutoIt is also an interpreted language, but it's not dependant on external libraries. You can redistribute compiled scripts around and be sure people will run it with no problems. And also this "managed" code sounds like the work is being done for you. Having learned a little bit of ASM and about how the computer works gave me a lot of understanding of memory and code execution, and made me program a lot better. People who start using .NET don't have this understanding, so they might never understand why isn't the program working.

.NET I believe is useful when using Oracle databases, SQL connections and stuff like that. But that's limited to be used inside companies, noone I know uses Oracle database server at home.

WSCPorts' avatar just reminded me of a game I play which uses GameGuard. I was analyzing how GameGuard works after I saw the game process didn't show up in Task Manager. It does a lot of evil stuff around. It's just like a virus or a rootkit with all those hooks and manipulation of other processes. GameGuard sometimes crash other processes and other times even boot the computer.

Back to the topic, I honestly don't think AutoIt should incorporate this "technology". Also, all of this is Microsoft's property, and Autoit is a free tool not directly connected to Microsoft. It should stay that way.

[sohfeyr]

I just had to reply.

I'm sorry if i'm saying stupid things here, as I don't know much of how .NET works, but I do know you have to download lots of files for .NET compiled programs to work. It would be just fine if all those DLLs came with most versions of windows, like kernel32.dll and user32.dll.

Apology accepted

Look, .NET is no more "evil" than the other DLLs used in programming - system.dll, kernel32.dll, user32.dll, gdi32.dll, comctl32.dll come readily to mind. These are simply inescapable because they are part of the operating system. The .Net Common Language Runtime adds overhead, yes, but it is no more intrusive than the Java Runtime Environment or the Flash Control or Acrobat Reader or any number of other things that, if it isn't on your computer already, it probably will be in the next few months.

You'll notice that you can find some version of Acrobat Reader on most commercial program CDs. Your web browser automatically gets Flash updates (ideally). I'll grant you this much: if a .NET program is distributed on CD or DVD, it should include the .NET CLR. For downloads, though, this becomes vaguely absurd as bandwidth, time and disk space get taken up distributing components that most people will already have from Windows Update.

AutoIt is also an interpreted language, but it's not dependant on external libraries. You can redistribute compiled scripts around and be sure people will run it with no problems.

That's how it is packaged, yes, but it depends a lot on what you are doing with COM objects, DLLCall... whether your target OS and the commands you use require you to use psapi.dll (included in the autoit directory).

As to distributing AutoIt scripts without problems, that's just naive. If you are doing anything that involves timing, matching a particular visible color, uses administrator-specific privileges, or that might be run at different resolutions, you owe it to your constituents to test the script on as many different speeds, cards, and resolutions as possible.

And also this "managed" code sounds like the work is being done for you. Having learned a little bit of ASM and about how the computer works gave me a lot of understanding of memory and code execution, and made me program a lot better. People who start using .NET don't have this understanding, so they might never understand why isn't the program working.

It's really funny how self-righteous ASM guys can get before they realize that the whole reason we've moved on from ASM is the speed and ease. There is no way on God's green earth my boss would wait for us to do stuff in ASM. He thinks AutoIt is taking too long! Don't get me wrong, ASM still has a place with low-level disk operations, memory managers and device drivers, but for application development? You're not only "reinventing" the wheel, you're doing it in the most obscure way imaginable that still uses a latin alphabet.

Yes, it is something people should probably know. Lots of people take Health class with no intention of ever becoming surgeons.

I honestly don't think AutoIt should incorporate this "technology". Also, all of this is Microsoft's property, and Autoit is a free tool not directly connected to Microsoft. It should stay that way.

That ship has sailed. AutoIt is already Windows-specific, has commands that do an NTFS link to files, and most of the controls it can automate are owned by Microsoft and held in Microsoft libraries. It may not be a direct connection, but it's a pretty strong association. If Windows tanked, AutoIt would be without a market.

I think AutoIt should support whatever technology it has to, to meet the needs of its users. If those users need .Net interoperability, I see little reason philosophically not to expand in that direction, and every reason technologically to do so: in the relatively near future, automation will be greatly influenced by the .Net 3. If AutoIt starts moving to support managed code execution now, it should be able to keep pace. See http://msdn2.microsoft.com/en-us/library/ms747327.aspx

Edited by sohfeyr, 31 December 2006 - 10:43 PM.

[Richard Robertson]

I'm going to take this project up. I will create a DLL that can be called from AutoIt (or anything else for that matter) that will communicate with .Net assemblies.

I will try to have a DLL very soon, as this is something simple actually.

[sohfeyr]

I'm going to take this project up. I will create a DLL that can be called from AutoIt (or anything else for that matter) that will communicate with .Net assemblies.

I will try to have a DLL very soon, as this is something simple actually.

Call the drug police, when you said that my eyebrows shot up
You mean also something that gets away from needing to be registered as a COM assembly? (A lot of native .Net classes are COM-visible, but nowhere near enough of them to do much that AutoIt couldn't handle natively or with DLLCall to the Win32 API... See .net framework objects and scripts)

Edited by sohfeyr, 02 January 2007 - 07:38 AM.

[Richard Robertson]

I have the dll nearly finished, I'm trying to finish up the exports and maybe fix some parameters.

[Locodarwin]

.NET is evil. We passed so much time developing better processors, faster systems, better compilation, etc and ect.

While I can understand a less-than-excited opinion of .NET, I have a hard time understanding why people would consider it "evil," as it without a doubt makes writing applications simpler, faster, and easier to manage. If I'm not mistaken, Vista will ship with the .NET framework as part of the system, so in that case the argument against .NET based on a "need to download additional runtime files" will be moot sooner than later.

Perhaps the "evil" suggestion has more to do with the .NET adoption campaign Microsoft is running, which to some (especially the younger crowd) may seem Draconian. How quickly we forget that we had this very same argument with the release of Windows 95 and its new-at-the-time SDK. Oh my, how we complained! "The Borg are assimilating us!" we cried. Yet the Win32 API soon became the best thing since sliced bread to anyone and everyone, once we *got* it. We should know by now that the future of programming, just like the future of anything else outside our personal spheres of influence, is not something we as individuals get to decide. It's an evolutionary process that we cavemen don't always fully understand at the time.

Eventually we have to evolve.

Like it or not, .NET or some further evolution of it is going to be the way developers write code for Windows in the future. The era of Win32 SDK and VC6 is fading fast. It may be unfortunate, but it is a reality. It'll all be managed code someday. Out in the real world (i.e. the business world), companies are moving to .NET at a brisk and increasing rate. It has always been true that what big name corporations use is what becomes standard.

Of course, no one need be convinced of .NET's advantages in the first place, as the old adages nonetheless apply: if you can't beat 'em, join 'em; resistance is futile; join us or die; and so on, and so forth.

There will still be those pockets of Win32/VC6 programmers out there, pining about the good old days, just as there are still dinosaurs out there wondering whatever happened to the beloved Abacus.

Personally, I thought GEOS was a better DOS-based OS than Windows 3.x, but eventually I stopped complaining and got with the program.

-S

[Zoli1972]

Sorry, but I wasn't logged in before, so I am double-posting now. Apologies...

I'd like to know about any progress on developing the dll. I need something to control a .net window (and its controls) from AutoIT.

Zoli

Edited by Zoli19721, 14 October 2007 - 12:24 AM.