RulerOf

Hello Folks, This took me long enough to do that I thought I'd share with the world. I needed a MAC address from AutoIt code by parsing the output from "ipconfig /all" stdout stream. It'll return the first MAC address it finds, and contains no error handling. Quick and dirty. #include <constants.au3> $ipconfig = Run(@ComSpec & " /c " & 'ipconfig /all', "", @SW_HIDE, $STDOUT_CHILD) Local $line = "" While 1 $line &= StdoutRead($ipconfig) If @error Then ExitLoop WEnd $macraw = StringRegExp($line, "\s*Physical\sAddress[\s\.]*\:\s*((?:(\d{1,2}|[a-fA-F]{1,2}){2})(?::|-*)){6}", 2) $mac = StringRegExpReplace($macraw[0], "\s*Physical\sAddress[\s\.]*\:\s*", "") Cheers, RulerOf P.S.: I hate regular expressions.

Oh hot damn that is one sexy script! Won't work here cause our users aren't admins... then again my biggest problem there is that SYSTEM doesn't have the symlink creation privilege, so it likely wouldn't work anyway. If you want to test for yourself, try calling mklink from a SYSTEM cmd prompt. It's kinda stupid.

Clever idea, and while I could do that, the local administrator accounts are disabled. As an aside though, I'm not a fan of embedding passwords I appreciate the thought though!

No, Group Policy startup scripts. Startup scripts run in the SYSTEM context and are transparent (and oh so easy to implement ), and usually give me a secure method for running administrative tasks that are local to a given machine. I wrapped the AutoIt3 executable and includes into an MSI with WIX such that admins and SYSTEM are allowed to run scripts and deployed that through group policy. That way I can stuff an .au3 file into the policies I'm using to get work done rather than using compiled scripts or resorting to javascript/vbs/whatever inferior language

Wow. It gets even more obnoxious than I thought. There's a policy setting in Windows to allow the creation of Symlinks by non-admin users, specifically the "SeCreateSymbolicLinkPrivilege" privilege. Every single attempt I've made to modify the privilege both through local/group policy, and using the security.au3 UDF, turns back successful but it doesn't f***ing do anything! Turns out that this is an issue with Windows that's apparently never been fixed, but I don't know how deep this bug goes. I'm whipping out some C++ today (groan) to see if I can dig at this privilege and get the damn thing working.... I just find it extremely stupid that I can't create symlinks programmatically with the SYSTEM account. FWIW, I'm digging into this (and I've wasted DAYS of work on this, thanks Microsoft!) because Symlinking is the only method I've been able to come up with (and if I had known about this, I would have tried anything else) to address a compatibility issue with a line of business app (hell, for my company it is the line of business app). If I'm successful, I'll post any methods/code/whatever that I come up with here, as well as other places. We'll see where this goes I suppose.

Yessir. Symlinks are only supported on NT6+ You could junction or hard link them, but I wasn't interested in those because I need to symlink a network folder

Oh good lord this is obnoxious... NT AUTHORITY\SYSTEM doesn't have the privilege to create Symlinks. I wanna shoot myself right now At least the code works

Hello Folks, Posting just to share I was wracking my brain yesterday trying to figure out why my script to generate a Symlink wouldn't work, and among other things, invoking @Comspec wasn't helping things any! A little googling and I stumbled across the method to create them programatically using the Windows API, which works pretty well. Here's the function if anyone would like to use it! ;======================================================================================= ; Function Name: _SymLink ; Description: Creates an NTFS Symbolic Link at the specified location ; to another specified location. ; ; Parameter(s): $qLink = The file or directory you want to create. ; $qTarget = The location $qLink should link to. ; $qIsDirectoryLink = 0 for a FILE symlink (default). ; 1 for a DIRECTORY symlink. ; ; Syntax: _SymLink( $qLink, $qTarget, [$qIsDirectoryLink = 0] ) ; ; Return Value(s): On Success: Returns the path to the created SymLink. ; ; On Failure: 0 and set @Error: ; ; 1 = DLLCall failed, @extended for more info ; 2 = $qLink already exists! ; ; Notes: To remove a Symbolic link, just delete it as you would any ; file or directory. ; ; Author(s): Andrew Bobulsky (RulerOf@{Google's-infamous-mail-service}.com) ; ; Other info: http://www.informit.com/guides/content.aspx?g=dotnet&seqNum=762 ; MSDN: http://msdn.microsoft.com/en-us/library/aa363866(VS.85).aspx ;======================================================================================= Func _SymLink( $qLink, $qTarget, $qIsDirectoryLink = 0 ) If FileExists($qLink) Then SetError(2) Return 0 EndIf DllCall("kernel32.dll", "BOOLEAN", "CreateSymbolicLink", "str", $qLink, "str", $qTarget, "DWORD", Hex($qIsDirectoryLink)) If @error Then SetError(1, @extended, 0) Return EndIf Return $qLink EndFunc Enjoy! =) -RulerOf

Ahem: <3 You. I come into work today only to find you've made my job sooooo much more concise. I owe ya! =) Thanks so much, RulerOf

This was driving me nuts for hours, trying to think of a good way to do this, and then I stumbled upon the LogonUser function in advapi32.dll. This code seems to work for me against the accounts I tried. Not sure what permissions are necessary for the autoit code to validate against the AD you're targetting though Also, use an NT-style domain (like "domain" instead of "domain.com") as I'm not sure if the FQDN will work. Hope you like it ;Returns 1 for valid credentials, 0 for invalid credentials and sets @error Func _ValidateUserCreds($d_Account, $d_Password, $d_Domain = @ComputerName) const $LOGON32_LOGON_INTERACTIVE = 2; const $LOGON32_LOGON_NETWORK = 3; const $LOGON32_PROVIDER_DEFAULT = 0; const $LOGON32_PROVIDER_WINNT50 = 3; const $LOGON32_PROVIDER_WINNT40 = 2; const $LOGON32_PROVIDER_WINNT35 = 1; $d_LogonUser = DllStructCreate("HANDLE") DllCall("advapi32.dll","BOOLEAN","LogonUser", "str", $d_Account, "str", $d_Domain, "str", $d_Password, "dword", $LOGON32_LOGON_NETWORK, "dword", 0, "ptr", DllStructGetPtr($d_LogonUser)) $d_Success = DllStructGetData($d_LogonUser, 1) If $d_Success Then Return 1 Else SetError(1) Return 0 EndIf EndFunc

Aye aye, I kinda fell off the wagon on this project when other things came up and never revisited it However, at the moment I find myself sorely in need of AutoIt on IIS right now (Because to hell with PHP! ) for a Win7 deployment I'm doing, so I'm going to be setting this up again and I'll give you my notes =) Apologies, but also many thanks!

Hello Folks, A little bit of Googlin' and a couple of Forum searches seems to indicate that, for some reason, this function isn't really prevalent, so I wanted to post the code I wrote here. Anyone care to pick it apart for me? I write AutoIt code in my spare time, so I may have missed a few gotchas that my limited (but successful!) testing couldn't reveal. _ProcessGetWindow() is designed to be the counterpart of WinGetProcess(), returning HWND's from an input process ID. It can also be told to provide a single, best guess result in the event you don't want to try parsing multiple windows from the output. In the event that this is a highly redundant post, I apologize, but I did do some searching in advance, and all I came up with was instructions to do just this Edit: Ha-ha, found a bug when I went to use it. As originally written, it wouldn't return HWND's for processes owning less than two windows Code updated. #include-once #include <array.au3> ; #FUNCTION# ============================================================================================================================ ; Name...........: _ProcessGetWindow ; ; Description ...: Returns an array of HWNDs containing all windows owned by the process $p_PID, or optionally a single "best guess." ; ; Syntax.........: _ProcessGetWindow( $p_PID [, $p_ReturnBestGuess = False ]) ; ; Parameters ....: $p_PID - The PID of the process you want the Window for. ; $p_ReturnBestGuess - If True, function will return only 1 reult on a best-guess basis. ; The "Best Guess" is the VISIBLE window owned by $p_PID with the longest title. ; ; Return values .: Success - Return $_array containing HWND info. ; $_array[0] = Number of results ; $_array[n] = HWND of Window n ; ; Failure - Returns 0 ; ; Error - Returns -1 and sets @error ; 1 - Requires a non-zero number. ; 2 - Process does not exist ; 3 - WinList() Error ; ; Author ........: Andrew Bobulsky, contact: RulerOf <at that public email service provided by Google>. ; Remarks .......: The reverse of WinGetProcess() ; ======================================================================================================================================= Func _ProcessGetWindow( $p_PID, $p_ReturnBestGuess = False ) Local $p_ReturnVal[1] = [0] Local $p_WinList = WinList() If @error Then ;Some Error handling SetError(3) Return -1 EndIf If $p_PID = 0 Then ;Some Error handling SetError(1) Return -1 EndIf If ProcessExists($p_PID) = 0 Then ;Some Error handling ConsoleWrite("_ProcessGetWindow: Process " & $p_PID & " doesn't exist!" & @CRLF) SetError(2) Return -1 EndIf For $i = 1 To $p_WinList[0][0] Step 1 Local $w_PID = WinGetProcess($p_WinList[$i][1]) ; ConsoleWrite("Processing Window: " & Chr(34) & $p_WinList[$i][0] & Chr(34) & @CRLF & " with HWND: " & $p_WinList[$i][1] & @CRLF & " and PID: " & $w_PID & @CRLF) If $w_PID = $p_PID Then ;ConsoleWrite("Match: HWND " & $p_WinList[$i][1] & @CRLF) $p_ReturnVal[0] += 1 _ArrayAdd($p_ReturnVal, $p_WinList[$i][1]) EndIf Next If $p_ReturnVal[0] > 1 Then If $p_ReturnBestGuess Then Do Local $i_State = WinGetState($p_ReturnVal[2]) Local $i_StateLongest = WinGetState($p_ReturnVal[1]) Select Case BitAND($i_State, 2) And BitAND($i_StateLongest, 2) ;If they're both visible If StringLen(WinGetTitle($p_ReturnVal[2])) > StringLen(WinGetTitle($p_ReturnVal[1])) Then ;And the new one has a longer title _ArrayDelete($p_ReturnVal, 1) ;Delete the "loser" $p_ReturnVal[0] -= 1 ;Decrement counter Else _ArrayDelete($p_ReturnVal, 2) ;Delete the failed challenger $p_ReturnVal[0] -= 1 EndIf Case BitAND($i_State, 2) And Not BitAND($i_StateLongest, 2) ;If the new one's visible and the old one isn't _ArrayDelete($p_ReturnVal, 1) ;Delete the old one $p_ReturnVal[0] -= 1 ;Decrement counter Case Else ;Neither window is visible, let's just keep the first one. _ArrayDelete($p_ReturnVal, 2) $p_ReturnVal[0] -= 1 EndSelect Until $p_ReturnVal[0] = 1 EndIf Return $p_ReturnVal ElseIf $p_ReturnVal[0] = 1 Then Return $p_ReturnVal ;Only 1 window. Else Return 0 ;Window not found. EndIf EndFunc

Regarding your post here: There may very well be a method for determining what server is calling AuCGI. You seem quite interested in being able to run this on IIS (as I am, too!) so I'll grab the latest AuCGI and web.au3 code and roll up some changes or patches if you like. In the meantime, I'll investigate the options. I'll post back either in a couple hours or by Monday and let ya know! In the meantime if I get a chance, I'll keep this thread subscribed if you've got anything to add Oh one more thing: It seems that passing serverside info to a CGI application is supposed to be done through environment variables, so it's likely that adding support for IIS/Apache/Tomcat/whatever will all be extensions of the same code base, FWIW. Thanks again guys __________ Update: Here's a snippet of what IIS is passing to the CGI module: SERVER_SOFTWARE: Microsoft-IIS/7.0 SERVER_NAME: drew-dc.drew.local GATEWAY_INTERFACE: CGI/1.1 SERVER_PROTOCOL: HTTP/1.1 SERVER_PORT: 80 REQUEST_METHOD: GET PATH_INFO: /AutoIt/test.auw PATH_TRANSLATED: C:\inetpub\wwwroot\AutoIt\test.auw SCRIPT_NAME: /AutoIt/test.auw REMOTE_HOST: 192.168.1.61 REMOTE_ADDR: 192.168.1.61 Ironically, all of these variables seem to be declared in web.au3, so I'm going to have to read them an additional time in AuCGI if it detects IIS. If anyone has another suggestion though, I'd be welcome to it Should have a code snippet ready soon.

Not sure if anyone cares, but I got this working on IIS 7 under Win2008. Screenshot: If you want to do this, it requires a modified AuCGI.au3. IIS passes the calling script over the the handler via environment variables. Change this: If $CmdLine[0] < 1 Then error("what are you trying to do???") Global $sourcescript = $CmdLine[1] To this: If StringRight(EnvGet("PATH_TRANSLATED"), 3) <> "au3" And StringRight(EnvGet("PATH_TRANSLATED"), 3) <> "auw" Then error(EnvGet("PATH_TRANSLATED") & ": Not a .au3 or .auw script file!") Global $sourcescript = EnvGet("PATH_TRANSLATED") Create a web application and add the AuCGI handler mapping to your web application under the IIS Manager to handle *.auw and/or *.au3 files. Seems to work pretty well! I've been dying to use AutoIt to handle HTTP boot scripts for gPXE, and /this/ is just what I've been looking for =) Thanks for the great work! ___ Also, I was thinking it would probably be prudent to pass the other environment variables down to the actual Au3 code, but I'm not sure. I'm not really a web programmer Wikipedia has the full list here.

Heh, i'd link to it but i have no idea where it is Search function to the rescue, sir! I need to go find some documentation on the XML wrapper i just found :-X

When creating a messaging app like both of us are, it's more than ideal to utilize the least amound of disk reading/writing as possible. Unfortunately, I simply can't comprehend how the TCP/IP autoit libraries work, so I'm utilizing a file method. At any rate, you're going to probably have the highest amount of disk writes with constantly creating/deleting files. Creating and deleting files involves writing/deleting header data, which could (or would) be larger than the file itself. It really depends on the permanance of your solution. The simple file write/reads are excellent for getting started, but due to the disk I/O which is truthfully unnecessary, it's not the best solution. I do say though, that you/we have the right idea

Not sure on how to delete the line, sorry. To avoid your issue with simultaneous file read/writes, you could, for example, create a "locking marker" of sorts, either in the same file or in a different one. Imagine, if you will, that during your write operation to "MessageFile.txt," you have a flag set in "FileLock.ini" that says "MessageLock.txt is currently in use," every time your scripts read or write the file. That way, if one script is doing a read, it sets the locking flag. Your other script would go to write to that file, but when it attempts the write, it'll see that the locking flag is currently set, so it waits a random amount of time (i.e. 100ms) and checks the flag again. Once it sees the flag has been cleared, it sets the flag itself, and then performs its operation. Of course, you could run into problems if both scripts attempt to either set or clear the flag at the same time, but that can be taken care of with either multiple flags or ini files... look into how CRC's or some other type of error checking algorithms to get an idea as to how this stuff works. [ramble] Hell, you could even make a file with an MD5 hash of the message and then have your receiving script verify the MD5 of the message before it attempts to parse it as actual data... that might work even better [/ramble] I'm not an expert.

IniWrite() will actually create the .ini file if it doesn't already exist. My script actually deletes the ini file if it exists already, and then adds lines to it. Also, Flyingboz, thanks for the info. I'll see if that works out properly... I'm actually working on trying to encode several types of information into a text file. I don't think that a standard ini file is appropriate, and an epiphany told me that some type of XML format would be perfect... now the question is how easy will parsing XML in autoit be

While I can't provide you with example code because the script I'm working on isn't finished yet, one very simple way to communicate with a script on another computer is simply writing to a file with one script and then reading the file with another. Simple FileWriteLine() to \\<computer>\<share>\<file>.txt could work well. One question I actually have, as I am implementing this myself, is, does anyone know if you run into sharing or access violations if one script has the file open while others try to access or overwrite it?