 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
Lexikos
Joined: 17 Oct 2006
Posts: 2739
Location: Australia, Qld
|
 Posted: Tue Nov 27, 2007 9:32 am Post subject: |
 |
|
Thanks for pointing that out. Most decent editors support UTF-8/upper-ASCII, but I've updated my post anyway, for Notepad compatibility.  |
|
| Back to top |
|
 |
Laszlo
Joined: 14 Feb 2005
Posts: 4078
Location: Pittsburgh
|
| Posted: Tue Nov 27, 2007 5:10 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
freakkk
Joined: 29 Jul 2005
Posts: 169
|
| Posted: Wed Nov 28, 2007 7:42 pm Post subject: |
|
|
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!
_________________
.o0[ corey ]0o. |
|
| Back to top |
|
|
AHKnow
Joined: 03 Jul 2004
Posts: 118
|
| Posted: Fri Nov 30, 2007 4:25 am Post subject: |
|
|
| 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)
} |
|
|
| Back to top |
|
|
none
Guest
|
| Posted: Fri Nov 30, 2007 10:49 pm Post subject: |
|
|
| lexikos, why do you post this every day? |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 2739
Location: Australia, Qld
|
| Posted: Sat Dec 01, 2007 12:48 am Post subject: |
|
|
Come again?  |
|
| Back to top |
|
|
Joy2DWorld
Joined: 04 Dec 2006
Posts: 425
Location: Galil, Israel
|
| Posted: Sat Dec 01, 2007 6:45 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 2739
Location: Australia, Qld
|
| Posted: Wed Dec 19, 2007 12:37 pm Post subject: |
|
|
I found another AutoHotkey-related use for named pipes: listing library includes. 
| 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. 
Of course, the script above on its own should show a blank MsgBox, since there aren't any calls to library functions. |
|
| Back to top |
|
|
tinku99
Joined: 03 Aug 2007
Posts: 35
|
| Posted: Sat Feb 09, 2008 5:06 am Post subject: question |
|
|
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. |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 2739
Location: Australia, Qld
|
| Posted: Sat Feb 09, 2008 7:07 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4078
Location: Pittsburgh
|
| Posted: Sat Feb 09, 2008 3:20 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
paulwarr
Joined: 21 Sep 2006
Posts: 30
|
| Posted: Tue Feb 26, 2008 10:42 pm Post subject: |
|
|
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....
|
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 2739
Location: Australia, Qld
|
| Posted: Wed Feb 27, 2008 1:00 am Post subject: |
|
|
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.) |
|
| Back to top |
|
|
paulwarr
Joined: 21 Sep 2006
Posts: 30
|
| Posted: Wed Feb 27, 2008 1:29 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 3652
Location: Belgrade
|
| Posted: Tue Mar 25, 2008 2:55 pm Post subject: |
|
|
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 ?
_________________
 |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
