Jump to content

New SciTE4AutoIt3 available with SciTE v1.77


Jos
 Share

Recommended Posts

  • Developers

Ok, that works ideally now.

Callback functions are stripped. I's not related to that script directly, it's the same for any script with callback function - e.g. help file example.

Callback UDF work as long as the specified UDF name is the string is equal to the actual UDF name which is the case in your script.

Local $h_CB = DllCallbackRegister("_CallbackEnumResTypeProc", "int", "hwnd;ptr;int")
;
Func _CallbackEnumResTypeProc($hWnd, $iMsg, $wParam, $lParam)
;
EndFunc ;==>_AdjustMediaViewPos

There was another issue in Obfuscator causing the error which should be fixed now.

Also found a Obfuscation error in your script when you use something like: Local $iNewYPos2 = (.8) It wouldn't include the DOT as part of the number.

That is fixed now too.

Try the current Beta version to see if it works for you.

Jos

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Link to comment
Share on other sites

  • Replies 155
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Callback UDF work as long as the specified UDF name is the string is equal to the actual UDF name which is the case in your script.

Local $h_CB = DllCallbackRegister("_CallbackEnumResTypeProc", "int", "hwnd;ptr;int")
;
Func _CallbackEnumResTypeProc($hWnd, $iMsg, $wParam, $lParam)
;
EndFunc;==>_AdjustMediaViewPos

There was another issue in Obfuscator causing the error which should be fixed now.

Also found a Obfuscation error in your script when you use something like: Local $iNewYPos2 = (.8) It wouldn't include the DOT as part of the number.

That is fixed now too.

Try the current Beta version to see if it works for you.

Jos

Yes, all works well. All I can say is thanks... again.

Just one thing more :D

If I manually do this replacements on obfuscated script, it shrinks additionally for 10 kB:

", " --> "," (not when ", _")
" =" --> "="
"= " --> "="
" &" --> "&"
"& " --> "&"
" <" --> "<"
"< " --> "<"
" >" --> ">" 
"> " --> ">"
"- " --> "-"
" -" --> "-"  (not after keyword e.g. Case -3)
" +" --> "+"
"+ " --> "+"

♡♡♡

.

eMyvnE

Link to comment
Share on other sites

  • Developers

Yes, all works well. All I can say is thanks... again.

Just one thing more :D

If I manually do this replacements on obfuscated script, it shrinks additionally for 10 kB:

", " --> "," (not when ", _")
" =" --> "="
"= " --> "="
" &" --> "&"
"& " --> "&"
" <" --> "<"
"< " --> "<"
" >" --> ">" 
"> " --> ">"
"- " --> "-"
" -" --> "-"  (not after keyword e.g. Case -3)
" +" --> "+"
"+ " --> "+"
mmm... a tidy stripper for Obfuscator... :o

Don't want to think about it at this moment because there are many things that could break and I have stripped most of that lexing logic used by Tidy from the Obfuscator source as that was never the intend for it. Actually also the Func and Var stripping options was never really intended as they don't have any relation with Obfuscator, but it was the easiest program to implement it. It was just one of those fun challenges to take on to see if it was doable.

I never expected to use it as much as I do today running it on most of my scripts with option /SO.

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Link to comment
Share on other sites

  • 1 month later...

I have still problems with latest beta of obfuscator /striponly and #include <SQLite.dll.au3>

Inside #include <SQLite.dll.au3> there are 3 (Inline) functions which are called from #include <SQLite.au3> by Call().

Because of that these functions are stripped which is OK. But I want to tell obfuscator to skip stripping of these functions

but I can't solve it by any way.

Here are my attempts:

1)

#AutoIt3Wrapper_Run_Obfuscator=y
#obfuscator_parameters=/striponly
#Obfuscator_Ignore_Funcs=__SQLite_Inline_Modified,__SQLite_Inline_Version,__SQLite_Inline_SQLite3Dll



#include <SQLite.au3>
#include <SQLite.dll.au3>

2)

#AutoIt3Wrapper_Run_Obfuscator=y
#obfuscator_parameters=/striponly

#include <SQLite.au3>
#Obfuscator_Off
#include <SQLite.dll.au3>
#Obfuscator_On

Ad 2) In obfuscated AU3 is this

#Obfuscator_Off
;Inline SQLite3.dll, Creation Time: 2007/06/24 22:26:55
#Obfuscator_On

so #include file SQLite.dll.au3 was stripped

The best way would be new Obfuscator option:

#Obfuscator_Ignore_Includes=SQLite.dll.au3

EDIT: I think #Obfuscator_Ignore_Funcs and #Obfuscator_Off are ignored/badly interpreted when using /striponly

Edited by Zedna
Link to comment
Share on other sites

  • Developers

The #Obfuscator_Ignore_Funcs= is only for the Obfuscation process, not for the stripping process.

If you want UDFs not stripped from a included file you could just add some unreachable code like:

If 0=1 Then
   __SQLite_Inline_Modified()
   __SQLite_Inline_Version()
   __SQLite_Inline_SQLite3Dll()
Endif

Does that work for you?

Jos :)

Edited by Jos

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Link to comment
Share on other sites

The #Obfuscator_Ignore_Funcs= is only for the Obfuscation process, not for the stripping process.

If you want UDFs not stripped from a included file you could just add some unreachable code like:

If 0=1 Then
   __SQLite_Inline_Modified()
   __SQLite_Inline_Version()
   __SQLite_Inline_SQLite3Dll()
Endif

Does that work for you?

Jos :)

Yes. This works fine. Thanks.

But it looks little ugly :-(

Edited by Zedna
Link to comment
Share on other sites

  • Developers

Yes. This works fine. Thanks.

But it looks little ugly :-(

Put a nice ribbon around it to make it look pretty ?

Seriously, I am not sure why you needed this, because if a UDF is used that Call()s any of these Funcs it isn't stripped... right?

Edited by Jos

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Link to comment
Share on other sites

Seriously, I am not sure why you needed this, because if a UDF is used that Call()s any of these it shouldn't be stripped... right?

I think you are wrong.

These Call()s are invoked only at specific conditions.

And functions inside Call() are always considered to be stripped.

But I need SQLite DLL file to be included for cases when it's not installed on target machine.

Today I have used SQLite for the first time in one of my script so I found out this issue.

Edited by Zedna
Link to comment
Share on other sites

  • Developers

Don't agree that Funcs inside call statements are stripped unless they are not translatable.

Try this example and see that the called func remains in the output file:

#AutoIt3Wrapper_Run_Obfuscator=y
#obfuscator_parameters=/striponly
#include <SQLite.au3>
#include <SQLite.dll.au3>
If 0=1 Then
   call("__SQLite_Inline_Modified")
Endif

EDIT:

In this example the first Func will remain but obviously the second won't because Obfuscator doesn't know the result of the string concatenation:

#AutoIt3Wrapper_Run_Obfuscator=y
#obfuscator_parameters=/striponly
#include <SQLite.au3>
#include <SQLite.dll.au3>
If 0=1 Then
   call("__SQLite_Inline_Modified")
   call("__SQLite_Inline_" & "Version")
Endif
Edited by Jos

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Link to comment
Share on other sites

Don't agree that Funcs inside call statements are stripped unless they are not translatable.

Try this example and see that the called func remains in the output file:

#AutoIt3Wrapper_Run_Obfuscator=y
#obfuscator_parameters=/striponly
#include <SQLite.au3>
#include <SQLite.dll.au3>
If 0=1 Then
   call("__SQLite_Inline_Modified")
Endif

EDIT:

In this example the first Func will remain but obviously the second won't because Obfuscator doesn't know the result of the string concatenation:

#AutoIt3Wrapper_Run_Obfuscator=y
#obfuscator_parameters=/striponly
#include <SQLite.au3>
#include <SQLite.dll.au3>
If 0=1 Then
   call("__SQLite_Inline_Modified")
   call("__SQLite_Inline_" & "Version")
Endif
I didn't know that.

Unfortunatelly from SQLite.au3 UDF it's called this way:

Call('__' & 'SQLite_Inline_Version')
Call('__' & 'SQLite_Inline_SQLite3Dll')
Call('__' & 'SQLite_Inline_Modified')

So this is main reason of my problems!!

I think it should be fixed if it's not intentional.

Edited by Zedna
Link to comment
Share on other sites

  • Developers

I didn't know that.

Unfortunatelly from SQLite.au3 UDF it's called this way:

Call('__' & 'SQLite_Inline_Version')
Call('__' & 'SQLite_Inline_SQLite3Dll')
Call('__' & 'SQLite_Inline_Modified')

So this is main reason of my problems!!

I think it should be fixed if it's not intentional.

No idea why it is done this way, but that indeed would cause these Funcs to be strippen in stead of being marked as Used by Obfuscator.

Maybe piccaso can shed some light on this?

Jos

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Link to comment
Share on other sites

Um, WTF:

Func _SQLite_Startup($sDll_Filename = "")
    Local $fUseInline = True
    If @error Then $fUseInline = False

That test is never going to be true...

Anyway, I can see no reason to concatenate the names. It looks like Call() is being used because SQLite.dll.au3 may or may not be included in the script. It seems to me that the full names should be used in Call() so that the functions don't get stripped. If a user does want the functions stripped then they should just stop including SQLite.dll.au3 because that eventuality is coded for and gracefully handled.

In short, I see no reason not to fix this.

Link to comment
Share on other sites

Um, WTF:

Func _SQLite_Startup($sDll_Filename = "")
    Local $fUseInline = True
    If @error Then $fUseInline = False

That test is never going to be true...

Anyway, I can see no reason to concatenate the names. It looks like Call() is being used because SQLite.dll.au3 may or may not be included in the script. It seems to me that the full names should be used in Call() so that the functions don't get stripped. If a user does want the functions stripped then they should just stop including SQLite.dll.au3 because that eventuality is coded for and gracefully handled.

In short, I see no reason not to fix this.

I fully agree with Valik

Just mentioned code snippet from my 3.2.12.1 is this:

Func _SQLite_Startup($sDll_Filename = ""); Loads SQLite Dll
 Local $hDll, $hFileDllOut = -1
  Local $fUseInline = True
 Local $vInlineVersion = Call('__' & 'SQLite_Inline_Version')
 If @error Then $fUseInline = False
 ...
Edited by Zedna
Link to comment
Share on other sites

I fully agree with Valik

Just mentioned code snippet from my 3.2.12.1 is this:

Func _SQLite_Startup($sDll_Filename = ""); Loads SQLite Dll
  Local $hDll, $hFileDllOut = -1
   Local $fUseInline = True
  Local $vInlineVersion = Call('__' & 'SQLite_Inline_Version')
  If @error Then $fUseInline = False
  ...
That makes more sense but is certainly not what the current code in my working copy shows.
Link to comment
Share on other sites

I didn't know that.

Unfortunatelly from SQLite.au3 UDF it's called this way:

Call('__' & 'SQLite_Inline_Version')
     Call('__' & 'SQLite_Inline_SQLite3Dll')
     Call('__' & 'SQLite_Inline_Modified')

So this is main reason of my problems!!

I think it should be fixed if it's not intentional.

This is fixed in the next beta.

Um, WTF:

Func _SQLite_Startup($sDll_Filename = "")
    Local $fUseInline = True
    If @error Then $fUseInline = False

That test is never going to be true...

As is this.
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...