This is currently the home of my AutoIT code. If traffic demands aren't too high and so forth, hopefully it should keep well into the future. Navigation links to code should appear on the left. I'm providing most of it in-page for the time being. It may not be pretty but it should work! You'll also see the following license agreement alot (don't worry - it's not a huge deal!):
Note: Some code has been left on the AutoIt forums for now (generally smaller UDF's or examples). See my forum profile ('About me' tab) for links to the rest of the code. You'll find links for File(s) Drag & Drop, _FilePropertiesDialog, dotNETGetVersions, Drive(s) Power Status and whatever else I think might be useful.
*10/12/2012 - Performance Counters update (Microsoft PDH.DLL bugs, bug fixes, 64+Processor Support)
*10/7/2011 - _ShellExecuteWithReducedPrivileges added (my COM knowledge is growing..)
*6/8/2011 - Process, Thread, DLL UDF grew even bigger - ALL the good stuff is in there now. Plus, Driver info now too
*5/28/2011 - Performance Counters - more updates/fixes, cleaner Console output
*5/27/2011 - _DLLStructDisplay now works with new v184.108.40.206 alignment-directives, plus some other changes
*5/23/2011 _FileFindEx, formerly _WinAPI_FileFind, updated - speed increases, Reparse Point info
*9/3/2010: Process UDF grew 10,000% to be a Process,Thread & DLL Functions UDF!! And I actually have included 2 Binary Threads for 32 and 64-bit code (one even with a special Wow64 version) embedded =) *7/21/2010: File + Process Import/Export UDF updated. *7/2/2010: New Milestone for Performance Counters - ObjectBase Interface!!
MASSIVE Changes, Awesome New Interfaces, etc. Still x64 and Locale-neutral!
Ascend4nt's AutoIT Code License agreement:
While I provide this source code freely, if you do use the code in your projects, all I ask is that:
Notes regarding certain projects:
If you provide source, keep the header as I have put it, OR, if you
expand it, then at least acknowledge me as the original author, and any other authors I credit
If the program is released, acknowledge me in your credits (it
doesn't have to state which functions came from me, though again if
the source is provided - see #1)
- The source on it's own (as opposed to part of a project) can not be posted unless a link to the page(s) where the code were retrieved from is provided and a message stating that the latest updates will be available on the page(s) linked to.
- Pieces of the code can however be discussed on the threads where
Ascend4nt has posted the code without worrying about further linking.
- The PDH Performance Counters UDF is currently my 2nd most popular project, and has undergone changes that simplifies usage of counters *tremendously*. Just go and try monitoring CPU Usage and see how easy it is. I'll one day get around to finishing up the 'Task Manager' example (haha, I don't know - me and list changes don't get along). Also, this is a HUGE project that needs good documentation - I've never done a .CHM Help File, but I want to (when I'm not busy with other things). I assume that's another learning curve there.. but for the meantime, there's plenty of examples and the headers are full of info, plus i give some resources. People can always ask me questions on the forums.
- The RemoteCodeX/RemoteThreadX Buffer-Execution UDF's aren't posted because:
The Full-Screen Crash Recovery program I've actually considered releasing on a freeware site, but I went ahead and put it here for now. The source code I'm holding onto, because I've done alot of work and testing on this to get it 'just right' - plus I may add additional features in the future, especially if it's going to be released to the 'public' (gotta think about some type of interface, allowing reassignment of hotkeys [possibly], etc). Hmm.. I might rerelease the source code again.. I'm THAT nice..
- They require flat machine code. The code can not be executable programs (.EXE) or dynamic link libraries (.DLL), it must be plain no-header binary code (which can't be run on it's own). Very few people will know or understand how to do this.
- Threads are neat and all, but most people who want Threads for AutoIT want it for the script part of the code. This is another point of confusion - the Threads can not directly interact with the script. They can do so via DLLStructs (allocated memory) or through posting messages. But keep in mind - posted messages pause the script just like Adlib and regular callbacks. So, in essence only 1 AutoIT thread is running - the rest of the Threads I create are machine code threads.
- 'Remote Threads?!' I know - I chose the wrong name for the UDF. These do not create Threads in other processes. However - I am working on creating a UDF to do just that - but the potential for abuse is high, so I'm skeptical if I'll ever release that when I'm done with it.
- *** Special note: The Processes, Threads & DLL's UDF's have 3 examples of creating threads (1 local, 2 remote)
64-bit Binary/Hex conversion UDFs - well, there's enough people with their own versions of binary/hex conversions, though very few have tackled the 64-bit problem. trancexx has however created a quick and dirty Hex conversion using DLLStructs that you should check out. Binary (base 2) conversion is another story - but there's probably a few that have done it 64-bit. If there's a dire need I could dig up my old scripts though.
The other miscellaneous projects I posted never got any attention or use, so those I also won't post for now.
I'm just trying to post what there's a need for =)
Quick 'About me':
I come from DOS C++/Assembly language roots. When Windows came along, I mostly stuck with writing Console applications, but found it annoying, and had a desire to tap into the Windows GUI interface. That proved to be a right pain in the arse, which is why I avoided it for so long. However, when I discovered AutoIT, I found myself diving in full force to Windows GUI programming, and even created moderate to somewhat complex programs. However, I've about stretched the language to its limits and am more involved with C++ programming these days. I still dabble in AutoIt programming though, and will probably use it for basic tasks and for testing different concepts out. For anything speed-intensive or large though, C++ is where I'll be at.
I contribute to the AutoIT forums
pretty regulary, a place which has a *great* community (save for a few folks
), but I may lose access to it again one day (long story).. which is why everything I'd like to share is now here, where I can control/update it.