TCP and Encryption included or not?

[layer]

The original intention of AutoIT and still my intention for using it is to script installs or changes on the computer.  File Size plays a huge importance because the bigger it is the longer it takes for my scripts to run across a network.  Believe it or not AutoIT isn't just for local computer scripting tasks.

red

<{POST_SNAPBACK}>

Thanks for the explanation

[Valik]

The original intention of AutoIT and still my intention for using it is to script installs or changes on the computer.  File Size plays a huge importance because the bigger it is the longer it takes for my scripts to run across a network.  Believe it or not AutoIT isn't just for local computer scripting tasks.

red

<{POST_SNAPBACK}>

Until AutoIt gets so big that it becomes quicker to physically walk to the machine and do the task yourself, this is not a compelling argument to limit the size by cutting features or writing extraordinaryly complex code to shave a few KB here and there. Unless your network is linked via a 14.4K modem, I would bet that AutoIt is still being transferred before you can get your ass out of the seat once you initiate a transfer.

[Angel]

Thats definitely not what I was saying at all.  There is a fundamental difference in trying to execute a DLL located only in memory and trying to execute an unknown file type in memory.

<{POST_SNAPBACK}>

What do you mean by unknown filetype? I was refering to a DLL or an EXE or an Icon or a PNG...

Angel

[redndahead]

Until AutoIt gets so big that it becomes quicker to physically walk to the machine and do the task yourself, this is not a compelling argument to limit the size by cutting features or writing extraordinaryly complex code to shave a few KB here and there.  Unless your network is linked via a 14.4K modem, I would bet that AutoIt is still being transferred before you can get your ass out of the seat once you initiate a transfer.

<{POST_SNAPBACK}>

Somewhat true. AutoIT has grown about 100KB since V2. At 1000 computers that's an extra 100MB extra going across my network every morning if I run 1 EXE file. Imagine having multiple scripts it starts to get ugly. I work in a school district and some of my sites still have hubs. Slows boot times and people complain. Just giving reasons why I wouldn't like it to get too much bigger for not enough used features.

Really that's why I would like to see the code split up and to be able to add the parts you need during compile. I think Jon turned down that idea when he thought he would keep it around 100KB, but now I think there is a valid reason to do this so we can keep it around 100KB. That said I'm not a programmer and I don't even know if it is possible to do it. So really it's up to you guys and him.

red

[Jon]

To whoever said that it would be a constant battle to shave features and weigh up filesize vs functionality - you are dead right. The other devs will be able to recount countless tales of code of theirs I've cut because it didn't feel right at the time - and sometimes after AutoIt has evolved a bit more the code sneaks back in.

Up to February I was very much involved on a daily basis but due to some problems and working away from home I've been hardly involved at all so well done to the devs for coming up with great stuff and supporting autoit

I'm still not sure about the "full on programming language thing" I'd still like the priority to be automation functions that aren't usually easy in things like VBscript. Meh.

A single file non-install exe has always been important. Unless I can copy AutoIt3.exe onto a memory fob and use it without installation and without hassle on any popular windows OS then something is wrong. Sure some functions might not work on 9x, nt4 but they are documented and fail silently where appopriate - I like that a lot.

Filesize is an odd one. As pointed out even a blank word document can be 150KB but I still worry about it. Red makes a decent point too about using autoit in corporates (actually my primary use for it - never used it much for home stuff). So I think striving for small exe even if we don't quite manage it is a worthwhile goal still. That means that ultra-niche functions won't make it in, even if they are just " a couple of KB". If i'd added all the niche stuff over the years that has been suggested the exe would already be 1MB of "just a few KB functions"

In a corp scripts are usually compiled because they don't want users looking at what the script is doing so you can end up with a number of compiled scripts - which is where the filesize can soon add up. Maybe I should use the existing compression and encryption engine to allow the _encoding_ of files. So instead of adding AutoItSc.bin onto every compiled file I just save the script/file portion in a way that the standard AutoIt3.exe can still work with. Actually I like this idea a lot....hmmm...cool. It would probably involve adding a couple of KB onto AutoIt3.exe but that's far outweighed by having small scripts. 10 compiled scripts at the moment is 1.5MB (excluding any fileinstalls) but with encoded stuff it would be one copy of AutoIt3.exe and 10 "archives" which would be tiny.

[BasicOs]

-I find tcp funcs vital-critical for autoit............

-If you are dropping them, I should propouse a speciall dll (working with it like an special fileinstall) where you can throw all fat niche functions like this not only tcp... I would call it something like asystem.dll and allowing to change the name.. something like that:

>fileinstalldll("") ,default asystem.dll .... ->into c:\windowsdir\systemdir\

>fileinstalldll("c:\whereever\anyname.dll")

this funcs could be noted in the help with some: nichefunc() ***

for all funcs into this dll

-ANOTHER question:

It looks super great this idea of saving space with many scripts........... but

will it not develop into an easyer cracking or decompiling of compiled scripts( with not allowing decompile option)?

Thanks for developing up it

To whoever said that it would be a constant battle to shave features and weigh up filesize vs functionality - you are dead right.  The other devs will be able to recount countless tales of code of theirs I've cut because it didn't feel right at the time - and sometimes after AutoIt has evolved a bit more the code sneaks back in. 

Up to February I was very much involved on a daily basis but due to some problems and working away from home I've been hardly involved at all so well done to the devs for coming up with great stuff and supporting autoit

I'm still not sure about the "full on programming language thing"  I'd still like the priority to be automation functions that aren't usually easy in things like VBscript.  Meh.

A single file non-install exe has always been important.  Unless I can copy AutoIt3.exe onto a memory fob and use it without installation and without hassle on any popular windows OS then something is wrong.  Sure some functions might not work on 9x, nt4 but they are documented and fail silently where appopriate - I like that a lot.

Filesize is an odd one.  As pointed out even a blank word document can be 150KB but I still worry about it.  Red makes a decent point too about using autoit in corporates (actually my primary use for it - never used it much for home stuff).  So I think striving for small exe even if we don't quite manage it is a worthwhile goal still.  That means that ultra-niche functions won't make it in, even if they are just " a couple of KB".  If i'd added all the niche stuff over the years that has been suggested the exe would already be 1MB of "just a few KB functions"

In a corp scripts are usually compiled because they don't want users looking at what the script is doing so you can end up with a number of compiled scripts - which is where the filesize can soon add up.  Maybe I should use the existing compression and encryption engine to allow the _encoding_ of files.  So instead of adding AutoItSc.bin onto every compiled file I just save the script/file portion in a way that the standard AutoIt3.exe can still work with.  Actually I like this idea a lot....hmmm...cool.  It would probably involve adding a couple of KB onto AutoIt3.exe but that's far outweighed by having small scripts.  10 compiled scripts at the moment is 1.5MB (excluding any fileinstalls) but with encoded stuff it would be one copy of AutoIt3.exe and 10 "archives" which would be tiny.

<{POST_SNAPBACK}>

Edited July 15, 2005 by BasicOs

[Jon]

It looks super great this idea of saving space with many scripts........... but

will it not develop into an easyer cracking or decompiling of compiled scripts( with not allowing decompile option)?

Thanks for developing up it

I've actually already got this working, so it will appear in a beta soon I imagine.

The encoded scripts are stored as .a3x files using similar code to that which encrypted the .exe. Although having a pure .a3x file to attack might seem more risky I don't think it is. It's just too complicated to reverse engineer. The script is compressed and then encrypted and all sorts of random sizing occurs too (compile the same script twice and check the size...different ). So to attack by decoding the .a3x/.exe file would require:

- Work out how to decrypt the stream

- Work out files are stored, table of contents, start/end position of files

Even then any information would be compressed using a proprietry compression routine so it's hard to know if you even have managed to decrypt successfully. Then you have to work out how to decompress the files.

That's too much hard work. Much simpler to just load up AutoIt3.exe/Exe2Aut with a dissassembler, add some breakpoints and take it from there. Even if I added some of the anti-dissassembler features available there are people out there who patch Adobe PhotoShop's activation code within 10 minutes of release....

Edit:

The additional cool thing is that you even save space over normal .au3 files. Scriptomatic.au3 was 21KB, Scriptomatic.a3x is 9KB

Edited July 15, 2005 by Jon

[HighGuy]

I've actually already got this working, so it will appear in a beta soon I imagine.

Fantastic Jon, I like your idea of encrypted scripts very much. As I'm distributing a lot of compiled AutoIt-scripts in one package this will make the size of my package a lot smaller. And if it seems to be more complicated to decrypt them, this will be my favorite methode of making my scripts "secure".

Thanks a lot. I'm looking forward to this new AutoIt feature!

[layer]

Great!

[redndahead]

I've actually already got this working, so it will appear in a beta soon I imagine.

The encoded scripts are stored as .a3x files using similar code to that which encrypted the .exe.  Although having a pure .a3x file to attack might seem more risky I don't think it is.  It's just too complicated to reverse engineer.  The script is compressed and then encrypted and all sorts of random sizing occurs too (compile the same script twice and check the size...different ).  So to attack by decoding the .a3x/.exe file would require:

- Work out how to decrypt the stream

- Work out files are stored, table of contents, start/end position of files

<{POST_SNAPBACK}>

How do you envision this working? Could I just run autoit3.exe file.a3x without the need of installing it on the computer? I'm thinking that if I just ran that in my logon scripts with command line options of the script that needs to be ran then that might be a nice way to distribute my scripts. Is this what your envisioning?

red

[Jon]

How do you envision this working?  Could I just run autoit3.exe file.a3x  without the need of installing it on the computer?  I'm thinking that if I just ran that in my logon scripts with command line options of the script that needs to be ran then that might be a nice way to distribute my scripts.  Is this what your envisioning?

red

Just like running a normal script:

AutoIt3.exe myscriptarchive.a3x

Except that just like a compiled exe the .a3x file can contain FileInstall stuff too.

[Jon]

As JP doesn't seem to be around to release a beta here are the files to have a sneak peek at the .a3x stuff.

[MSLx Fanboy]

Very nice...Much better than that crap VB encoding program Microsoft released (can't change user passwords when its encrypted )

I haven't tested it with COM or the beta stuff, but is the demo based off of 3.1.1 or a beta version?...nevermind... .59!

Edit: In regards to the encryption used...is it a standards-based encryption scheme or what? (Only because some of the encryption algorithms adhoc'd for use in AutoIt scripts aren't very secure)

Edited July 15, 2005 by MSLx Fanboy

[jpm]

As JP doesn't seem to be around to release a beta here are the files to have a sneak peek at the .a3x stuff.

<{POST_SNAPBACK}>

I am back from our national day

[Jon]

I am back from our national day

Have fun?

[jpm]

Have fun?

<{POST_SNAPBACK}>

yes with my little daugher

[layer]

That's good, you definatley deserve it

[redndahead]

Just like running a normal script:

AutoIt3.exe myscriptarchive.a3x

Except that just like a compiled exe the .a3x file can contain FileInstall stuff too.

<{POST_SNAPBACK}>

So would I be able to do autoIT3.exe myscript1.a3x myscript2.a3x myscript3.a3x

The reason I ask is because if I could put this into a logon script and only pull down autoIT3.exe once it might be nice. Do I need the bin at all other than to compile the script to the .a3x format?

red

[redndahead]

So would I be able to do autoIT3.exe myscript1.a3x myscript2.a3x myscript3.a3x

The reason I ask is because if I could put this into a logon script and only pull down autoIT3.exe once it might be nice.  Do I need the bin at all other than to compile the script to the .a3x format?

red

<{POST_SNAPBACK}>

Ok I know I don't need the bin now, but is there a way to run multiple scripts in a row so as soon as one stops the next one starts?

red

[quaizywabbit]

Ok I know I don't need the bin now, but is there a way to run multiple scripts in a row so as soon as one stops the next one starts?

red

<{POST_SNAPBACK}>

isn't that what #include is for?