AutoHotkey Community

It is currently May 25th, 2012, 10:07 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 49 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject:
PostPosted: November 27th, 2007, 10:32 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7501
Location: Australia
Thanks for pointing that out. Most decent editors support UTF-8/upper-ASCII, but I've updated my post anyway, for Notepad compatibility. :P


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: November 27th, 2007, 6:10 pm 
Offline

Joined: February 14th, 2005, 4:05 pm
Posts: 4710
Location: Boulder, CO
khan wrote:
I can't run a posted script because script have unicode characters.
Those are extended ANSI chars, not Unicode. However, they might be different in your input locale, so the chr() version is really safer.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: November 28th, 2007, 8:42 pm 
Offline

Joined: July 29th, 2005, 5:32 pm
Posts: 179
This is very useful! I find it quite amazing how simple this turns out to be!!

lexikos wrote:
One of the ideas I had: a custom build of AutoHotkeySC (for compiled scripts) that accepts script content directly via a pipe. This way compiled scripts would be able to:
  • Execute "dynamic" script.
  • Run embedded child scripts. For instance, to simulate multi-threading for specific tasks without loading any unnecessary code into the child script.
(All without packaging AutoHotkey.exe with the script.)
Although I would find that phenomenally useful.. I can understand why that may not be a common request for a majority of users. It would no doubt open some new doors though..

Thanks again for demonstrating this; many experiments come to mind w/ using pipes now that I understand them! :P

_________________
.o0[ corey ]0o.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: November 30th, 2007, 5:25 am 
Offline

Joined: July 3rd, 2004, 1:03 pm
Posts: 121
khan wrote:
I can't run a posted script because script have unicode characters.
so, I changed a little.
Code:
Script = %Script%

to
Code:
Script:=chr(0xef) . chr(0xbb) . chr(0xbf) . Script

Anyway, Thanks for sharing it. :)


Very interesting script. Lazlo's and Khan's slight mod version works too.


Code:
Gui Add, Edit, r5 w160 vScript, MsgBox `% %A_Space%
Gui Add, Button, w70, &Run
Gui Add, Button, w70 x+20 yp, &Cancel

#!z::Gui Show

ButtonRun:
   Gui Submit

   Script:=chr(0xef) . chr(0xbb) . chr(0xbf) . Script ; AHK needs leading UTF-8 BOM ""

   pipe_name := A_Now   ; unique to prevent collision
   pip2 := CreateNamedPipe(pipe_name, 2) ; AHK calls GetFileAttributes() = close pipe. Create 2nd pipe
   pipe := CreateNamedPipe(pipe_name, 2) ; 1st instance seems to reliably be "opened" first
   if (pipe=-1 or pip2=-1) {
       MsgBox CreateNamedPipe failed.
       ExitApp
   }

   Run %A_AhkPath% "\\.\pipe\%pipe_name%"

   DllCall("ConnectNamedPipe","uint",pip2,"uint",0) ; Wait for AHK to connect via GetFileAttributes()
   DllCall("CloseHandle","uint",pip2)               ; Not needed any more
   DllCall("ConnectNamedPipe","uint",pipe,"uint",0) ; Wait for AHK to connect to open the "file"

   If !DllCall("WriteFile","uint",pipe,"str",Script,"uint",StrLen(Script)+1,"uint*",0,"uint",0)
       MsgBox WriteFile failed: %ErrorLevel%/%A_LastError%

   DllCall("CloseHandle","uint",pipe)
Return

ButtonCancel:
   Gui Destroy
Return

CreateNamedPipe(Name, OpenMode=3, PipeMode=0, MaxInstances=255) {
    Return DllCall("CreateNamedPipe","str","\\.\pipe" Name,"uint",OpenMode
        ,"uint",PipeMode,"uint",MaxInstances,"uint",0,"uint",0,"uint",0,"uint",0)
}


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: November 30th, 2007, 11:49 pm 
lexikos, why do you post this every day?


Report this post
Top
  
Reply with quote  
 Post subject:
PostPosted: December 1st, 2007, 1:48 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7501
Location: Australia
Come again? :shock:


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 1st, 2007, 7:45 pm 
Offline

Joined: December 4th, 2006, 10:35 am
Posts: 561
Location: Galil, Israel
maybe?? none/guest hasn't realized yet that each reply 'bumps' your post to the top,

and they were thinking you were reposting same thread every day.

_________________
Joyce Jamce


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 19th, 2007, 1:37 pm 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7501
Location: Australia
I found another AutoHotkey-related use for named pipes: listing library includes. :D
Code:
pipe := DllCall("CreateNamedPipe","str","\\.\pipe\ahkilibpipe","uint",3
        ,"uint",0,"uint",255,"uint",0,"uint",0,"uint",0,"uint",0)

Run, "%A_AhkPath%" /iLib \\.\pipe\ahkilibpipe "%A_ScriptFullPath%"

DllCall("ConnectNamedPipe", "uint", pipe, "uint", 0)
Loop {
    VarSetCapacity(buf, 4095)
    DllCall("ReadFile","uint",pipe,"str",buf,"uint",4095,"uint*",bytesRead:=0,"uint",0)
    NumPut(0, buf, bytesRead, "char") ; terminate the string
    VarSetCapacity(buf, -1)
    text .= buf
    if bytesRead < 4095
        break
}
MsgBox %text%

I believe the /iLib feature is used by Ahk2Exe. It generates a list of #includes for library functions (which otherwise wouldn't have explicit includes.) Piping avoids the need for a temporary file. 8)

Of course, the script above on its own should show a blank MsgBox, since there aren't any calls to library functions.


Report this post
Top
 Profile  
Reply with quote  
 Post subject: question
PostPosted: February 9th, 2008, 6:06 am 
Offline

Joined: August 3rd, 2007, 8:01 am
Posts: 555
Location: Houston, TX
1. lexiKos, which ram disk do you use?

2. i want to use named pipes to communicated between java and tesseract to speed up an ocr script i wrote...

i want to use java.awt.robot to capture an image, write it to a pipe, then have tesseract read from that pipe to extract text...
is this possible? Sorry if I am off topic from autohotkey...

would ramdisk be faster?

right now i just runwait, until the files are written to start the next process... which i suspect is slowing things down.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 9th, 2008, 8:07 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7501
Location: Australia
I use AR Soft's RAM Disk.

There probably won't be much difference in performance between pipes and ramdisk. I would go with pipes, if possible, since:
  • they don't require installing software, and
  • they can be simultaneously read and written.
There are other solutions, like TCP/IP, but since named pipes are basically treated as files, they seem simpler.
Quote:
right now i just runwait, until the files are written to start the next process... which i suspect is slowing things down.
Using a ramdisk probably wouldn't solve that issue, though reading/writing might be faster.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 9th, 2008, 4:20 pm 
Offline

Joined: February 14th, 2005, 4:05 pm
Posts: 4710
Location: Boulder, CO
A couple of years ago we did some benchmarking of the speed of inter-process communication. Pipes were not included, but RAM disks proved to be slower than real disk I/O, because small files written, read and immediately deleted remain in the Windows buffer, never actually written to the disk. Reading and writing the memory of the other process is faster, but if you don’t do it in a loop, you will never see a difference. The problem with the disk I/O is you have to avoid file name conflicts, worry about disk quotas (in multi user environments, USB disks), read only problems when booted from a CD, etc., but these don’t affect the majority of users.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 26th, 2008, 11:42 pm 
Offline

Joined: September 21st, 2006, 10:04 pm
Posts: 32
lexiKos wrote:
Quote:
One of the ideas I had: a custom build of AutoHotkeySC (for compiled scripts) that accepts script content directly via a pipe. This way compiled scripts would be able to:

Execute "dynamic" script.

Run embedded child scripts. For instance, to simulate multi-threading for specific tasks without loading any unnecessary code into the child script.
(All without packaging AutoHotkey.exe with the script.)

I have no immediate use for it, so probably won't be the one to work on it.

Compiled AutoHotkey scripts that are "open" (having the ability to accept and run uncompiled scripts from without the executable) have enormous potential - whether using pipes or temporary files. One hypothetical example:
    Client computer has an "updater" compiled script - just a stub, really, that launches an embedded webbrowser in a gui, forces the user to authenticate to the server, then downloads, decrypts and executes a customized and up-to-date "patch" (registry revisions, whatever) that's built on-the-fly and encrypted on the server, customized for that particular user/workstation configuration. This would be very useful for windows admins who have to maintain machines that aren't connected to a Windows Active Directory.... :D


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 27th, 2008, 2:00 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7501
Location: Australia
Thanks for the interesting example.

I think a more expansive idea would be to introduce another form of #include that is not replaced by ahk2exe. Compiled scripts would then be extensible, without exposing the script of the core application. (Edit: Unfortunately, an included script could potentially reconstruct the source code of the core application by examining in-memory code structures.) Content could be loaded from a script file and/or accepted (exclusively) via a pipe:
Code:
#include *i \\.\pipe\pipename
*i allows the script to load if the pipe doesn't exist.

This also gives the script a meaningful script path, for built-in variables (such as A_ScriptDir and A_ScriptFullPath) and utilities that enumerate running scripts (such as AHKControl.)


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 27th, 2008, 2:29 pm 
Offline

Joined: September 21st, 2006, 10:04 pm
Posts: 32
Quote:
(Edit: Unfortunately, an included script could potentially reconstruct the source code of the core application by examining in-memory code structures.)

Yes, I see the risk. And, of course, once the "reconstruct this" code's in the pipe, there's little that can be done to prevent what you suggest from taking place. So care would have to be taken by the developer (in my example, perhaps by use of some encryption/checksum exchange involving a private key) to assure that only "validated" uncompiled scripts are allowed to run in the pipe.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 25th, 2008, 3:55 pm 
Offline

Joined: May 24th, 2006, 2:49 pm
Posts: 4511
Location: Belgrade
2 lexikos
Hello m8.

Can you tell me is it possible to recreate some simple file system this way. For instance, lets say I have 1 MHT file and several files in it (images, wavs, js's, etc..). Can I use this MHT directly without unpacking it to the HD, by creating pipe for each file and feeding this path were regular path in arbitrary API call would be.

So, idea would be to instead writing to HD, I write to pipe (thus recreating files in memory, but still being able to use them by path)

thx

Quote:
Yes, I see the risk. And, of course, once the "reconstruct this" code's in the pipe, there's little that can be done to prevent what you suggest from taking place. So care would have to be taken by the developer (in my example, perhaps by use of some encryption/checksum exchange involving a private key) to assure that only "validated" uncompiled scripts are allowed to run in the pipe.

How that differs from normal cracking ?

_________________
Image


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 49 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC [ DST ]


Who is online

Users browsing this forum: IsNull, Uberi and 12 guests


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group