New SciTE4AutoIt3 available with SciTE v1.79

[Jos]

Those will be fixed in the next version.. thanks

[Mat]

Hey Jos, I have a quick question about the "#AutoIt3Wrapper_Res_SaveSource" directive. I am using it at the moment in order to keep a copy of the script source with the executable, but I also use obfuscater (to remove unused funcs etc. And also rename vars and funcs) and it is copying the obfuscated code to rc_data. Is there a particular reason for this because I think the logical way to do it is give the code as the author wrote it (readable). If there is a reason for this then I am fine to open ResHacker every version and do it myself.

Mat

[Melba23]

Mat,

Use the /SOI parameter for Obfuscator - it leaves your source code as you wrote it. This post is when Jos introduced it - the whole thread explains how it came about.

M23

[Mat]

Thanks melba, but its still not ideal, I am now doing this instead:

#AutoIt3Wrapper_Run_After=ResHacker.exe -add %out%, %out%, %scriptfile%.au3, RCDATA, SOURCE, 0

/soi is good, very close, but it copies all the include data, which is not what I want. Anyone interested in the source will be an autoit user, and it'll be a lot more meaningful to see #Include<Constants.au3> rather than Global Const .... etc.

Mat

[Jos]

The #AutoIt3Wrapper_Res_SaveSource was introduced at the time the decompile option was removed and as such simply saves the source included in the EXE.

I have no issue looking at alternative options for this directive as it should be simple to make changes for this particular requirement and can see the usefulness.

What about we do it this way:

#AutoIt3Wrapper_Res_SaveSource=y  ; save the source as included in the EXE
#AutoIt3Wrapper_Res_SaveSource=O  ; save the original source in the EXE

This change is trivial and honestly it will take more time to document it than implementing it.

Jos

[Valik]

My only comment I'll make on the "save source" thing is this: Remember that not every script is stand-alone in the sense that it only relies on the standard UDFs. Jos, how would you package /trunk/_build/B_02_build_autoit.au3, for example. It relies on an additional non-standard library contained in a sub-directory which in turn relies on yet more libraries. I'm not sure how you would go about handling that situation since it can get pretty complex pretty fast.

[Mat]

My only comment I'll make on the "save source" thing is this: Remember that not every script is stand-alone in the sense that it only relies on the standard UDFs. Jos, how would you package /trunk/_build/B_02_build_autoit.au3, for example. It relies on an additional non-standard library contained in a sub-directory which in turn relies on yet more libraries. I'm not sure how you would go about handling that situation since it can get pretty complex pretty fast.

Very true, and I hadn't considered it. I suppose an option like Jos said would be better then. Since I have the reshacker line working fine now, I am fine to stick with that, but I was confused that it was saving the obfuscated source which is of little use to anybody (without using /soi). If there is no logical way to implement it then don't bother.

[Jos]

My only comment I'll make on the "save source" thing is this: Remember that not every script is stand-alone in the sense that it only relies on the standard UDFs. Jos, how would you package /trunk/_build/B_02_build_autoit.au3, for example. It relies on an additional non-standard library contained in a sub-directory which in turn relies on yet more libraries. I'm not sure how you would go about handling that situation since it can get pretty complex pretty fast.

I know the "shortcomings" of this option since day one and honestly never ever use it because I always use a proper versioning system for all my sources.

The options really are to:

1. include the source script without includes: current option when Obfuscator isn't run.

2. included stripped total code: current option when Obfuscator is ran with /SO parameter.

3. included obfuscated code: current option when Obfuscator is ran without parameters.

4. included all source code: not implemented at this moment but doable.

I know I am going to deeply regret this but let me ask this forum:

What options should really be supported for this option?

Do we really want this option supported et all?

Jos

Edited January 18, 2010 by Jos

[Melba23]

Jos,

As one of the original instigators of the /SOI option here is my tuppenny-worth (no 2 cents here yet! ) on your suggestions:

1. include the source script without includes: current option when Obfuscator isn't run.

Should be retained as it keeps the code "as written".

2. included stripped total code: current option when Obfuscator is ran with /SO parameter.

Should be retained to keep the includes as they were at that time so that if an include is changed any difference can be seen (and any problems hopefully remedied quickly). Personally I prefer the /SOI option, for the reasons I stated before - the main code is readable and I do not believe that most coders would be able to read a stripped script after even a short period.

3. included obfuscated code: current option when Obfuscator is ran without parameters.

Cannot see the need - if the code is obfusctated it is virtually unreadable, even by the author!

4. included all source code: not implemented at this moment but doable.

Makes for a VERY BIG exe - these were my figures from the /SOI thread:

Basic source        FullSource      New Obfuscated /SOI

.au3    88,373              2,069,072       186,536

.exe    351,877             743,558         372,333
(with upx)

So my vote would go for using the main Obfuscator parameters as the key to the included code:

#AutoIt3Wrapper_Res_SaveSource=n - nothing saved

#AutoIt3Wrapper_Res_SaveSource=y - depends on main Obfuscator parameters

=== Anything other than /SO or /SOI - unstripped script with no includes

=== /SO - stripped script and stripped includes

=== /SOI - unstripped script and stripped includes as at present

You did ask!!!!

M23

[Jos]

You did ask!!!!

I Know......

While you are on a roll let me ask you this: Who is going to document this in layman's terms that even I would understand it?

Seriously: It was all intended to be sweet and simple but I am worried that nobody will understand it any more.

As to the Obfuscator parameters checking (option 3) when somebody runs Obfuscator to truly Obfuscate the source you would THINK they would not opt for including the source in the Resources ....right?

..Or maybe option 0: stop support and tell people to use proper versioning?

Jos

[Melba23]

Jos,

I would be happy to try and put it into understandable English.

As to the Obfuscator parameters checking (option 3) when somebody runs Obfuscator to truly Obfuscate the source you would THINK they would not opt for including the source in the Resources ....right?

You are correct - please ignore that suggestion. It came out of the bottle of Cotes Du Rhone we had with dinner! Just look for the /SO and /SOI options then - makes the whole thing easier, no?

As to dropping the option entirely..... I use versioning as you obviously do, but there are now at least 2 threads where experienced users have asked if saving the source internally could be supported. You are a victim of your own success!

M23

[Mat]

An option for SaveSource=o would be a better idea than checking what obfuscater params have been run(my opinion). Or just add a not saying that if they want to add source as written then they can use #AutoIt3Wrapper_Res_File_Add or reshacker as I now am, that way they have the option to do it without messing up whats already there.

Edit: I do use versioning, but the idea I had was a way for the user to extract the source from the exe. simple huh?

Edited January 18, 2010 by Mat

[Jos]

An option for SaveSource=o would be a better idea than checking what obfuscater params have been run(my opinion). Or just add a not saying that if they want to add source as written then they can use #AutoIt3Wrapper_Res_File_Add or reshacker as I now am, that way they have the option to do it without messing up whats already there.

Having had my glass of Wine myself and a little more thinking about it I think it should work the following way when #AutoIt3Wrapper_Res_SaveSource=y is specified:

Include the source output from Obfuscator when /SO and /SOI is specified, else include the original source.

You are a victim of your own success!

What can I say?

[Mat]

Include the source output from Obfuscator when /SO and /SOI is specified, else include the original source.

Right. That sounds simple and easy! As long as easy enough to implement, I think that would be a good idea.

Thanks Jos (and Melba )

[Bowmore]

Include the source output from Obfuscator when /SO and /SOI is specified, else include the original source.

If any other options than /SO and /SOI have been specified is the any point in including the source?

If the original source is included then the obsfucation is rendered pointless and if source output from Obfuscator is included it will be, as others have said, virtually impossible for the author to understand. Personally I think that the option to include the source as a resource is a bad idea in that lets people get into a bad habit of not making sure they have several secure copies of their source code.    

[PsaltyDS]

SciTE has it's own beta directory. You're looking in the AutoIt beta directory.

Doh!

I looked for SciTE under beta, but not beta under SciTE.

[Melba23]

Jos,

As you appear to be in a mood to answer/change things about SciTE....

Is there any way to change the annoying (to me at least) behaviour of SciTE when you use "Replace". It leaves you at the location of the last replacement - can it be set to go back to the original position?

I have tried to code a LUA function after studying the existing "Jump to Function/Jump Back" function (promise not to laugh! ):

function AutoItReplace:JumpBack()

    props['SciteLastJumpFromPos'] = editor.CurrentPos .. "|"

    scite.MenuCommand(IDM_REPLACE)

    self.filepos = string.gsub(props['SciteLastJumpFromPos'],"(.-)|(.*)","%1")
    editor:GotoPos(self.filepos)

end

I saved the new .lua file, amended SciTEStartup.lua and actually got the function to work from within the Tools menu. However, it does not jump back once the "Replace" dialog is closed.

What am I doing wrong? Or, perhaps more pertinently, am I doing anything right? And if I do get it to work, how can I get it to run in place of the standard SciTE "Replace" function in the menu and toolbar?

M23

[Valik]

Attempting to do what you want would be considerably difficult. I can't think of a complete implementation off the top of my head. It's not exactly trivial. I think it's probably far more effort that it's worth.

[Melba23]

Valik,

Thanks for that - it is what I feared from the beginning. But it was fun trying and it is too wet for golf!

M23

[Jos]

Not much time at the moment but am pretty sure that LUA fires the Replace window and then doesn't wait for it to be closed.

mmn.. see Valik also answered....

Edited January 19, 2010 by Jos