rbhkamal

Perfect! that's exactly what I needed I tried to use Obfuscator before but it was including some functions multiple times, at that time I didn't want to troubleshoot it and ended up not using it. Thanks a lot!

Thanks for the fast reply. I understand that my exe cannot be decompiled, however, that is not my goal. just fyi [Edit] I'm sure there is a way to make au2exe not delete that temp file. Right now I'm trying to modify the security settings to not allow delete.

My understanding is that when compiling scripts, autoit joins all the included libraries into a single file then compiles it. How can I get that file? I'm getting a runtime error at line 9130 and 5448 and really have no idea how to trace it back to the source code. Thanks, RK

Right

But my very simply question still stands, is there any way for a COM service to get the path of the callers process? How? Valik, even though I would love to spill my guts here, there are some details that I cannot disscus here so please understand. In my case, path-based protection is the fastest and the most secure (and its not up to me anyway).

I agree with you 100%.... I really didn't want to open this can of worms but here we go.. [DELETED] [DELETED] So now I'm forced to modify the code for the COM service to do one of the following: 1- Accept calls *only* from processes running from my installation folder (protected using the filter) 2- Protect the IPC with a shared secret (somehow) I'm trying number 1

I'm creating my first COM service ever using this (http://www.codeguru.com/cpp/com-tech/activex/tutorials/article.php/c5567) which is great. But I need to know if there is anyway for the COM service to get the process path of the COM clients. So for example: c:\client-au3-testing-*.exe is allowed access everything else is blocked. The next step is to verify the executables signature but that would be easy once I have the process path. Thanks (its been a while) RK

Yes and no, I was looking for something simple... just like visual studio configuration variables but your suggestion solves the problem. The reason why I want this is because everytime I want to do a 64bit build or a 32bit build, I must change the output path manually. Now, other people have to do the build and they are not doing it correctly... which resulted in the 64bit versions getting shipped off to testing... and waisting money.

You do not know what 42 is?! OMG google the following: what is the answer to life the universe and everything?

I have a level of interest in almost anything, the real question is how much interest do I have in your script. The next logical question is , how do you quantify interest? The answer is almost certainly dependent on relativity which brings me to ask the question, what are the two things that the difference between them is exactly one? Lets theorize that there are such two things and lets call the difference kuku Base on the above, I believe my interset in your script is almost exactly 42 kuku which is also the answer to life the universe and everything

What I would do is the following: 1- Set a trigger that will boot up the PC on demand, this is normally in the BIOS using the WAKE On LAN feature (if any) 2- Set a small script that will launch and start sending UDP brodcasts the minute the machine is fully booted. Then all you need to do is trigger the WAKE-ON-LAN from another computer, start a timer and wait for these broadcast messages. You could also try starting the timer until a ping is received from the host.

When compiling autoit scripts into exe, is there a way to make the output path dependent on the target CPU architecture? Something like this? .\out\win.$(arch)\theFile.exe Thanks

I just tried it and couldn't get it to work either... and for some reason the COM error handler failed to trap the error. Sorry can't help you with this one, but I've always used vboxmanage.exe to do all of my automation. Its safer and more portable that way.

I agree, but I'm still in denial simply because the idea that UDFs force me to register my error handler through their functions bothers me. btw Wiedmann, If you ever use IE.au3 or any other UDF which depends on COM, make sure that you register your error handler using their functions. And on a different note, your for loop will also crash your program if $IMachine = $IVirtualBox.Machines doesn't return the list of machines. So you'll have to do the following: $IMachine = $IVirtualBox.Machines $aMachine = "" For $i=0 to Ubound($IMachine)-1 $aMachine = $IMachine[$i] ConsoleWrite($aMachine.Name & @CRLF) Next

Well... there was a COM error during runtime and AutoIt crashes when that happens. I suggest you register an AutoIt error handler to trap the error, look in the help file. The error handler they have there is perfect. Personally, I allways thought autoit needs try/catch...... but