Shaggi

As jumping/calling is always using relative offsets in x86 assembly, you would need to either calculate the correct jump offset (ie. base of your allocated code + offset of current instruction + instruction and operand size - the absolute address) or the simpler way: move the absolute address into a register and call / jump to that register. Second way may be more or less problematic as I'm assuming you're creating some kind of patch, where registers are either used or not saved yet. In this case, first method is usually the only way.

Sorry i haven't been around. Either use system("cls") or write a wrapper around FillConsoleOutputCharacterW, as brewman said.

#include <array.au3> global $folders[41][2] global $oS = objcreate("Shell.Application") for $i = 0 to ubound($folders) - 1 local $sfolder = $oS.namespace($i + 1) if not isobj($sfolder) then continueloop $folders[$i][0] = $sfolder.title() $folders[$i][1] = $sfolder.self.path next _arraydisplay($folders) outputs folders in installed language as well

This looks like the language i always wanted. Amazing job, will look at it later

?

I'll second this. Consistency is always the best, else reading/working on an existing codebase is arguably enough reason to suicide.

Sorry, but that list is useless. Also, this: And what is the point of this?

To get the relative jumps & calls resolved, you can just load the code into an debugger and copy paste.

Are you sure you want to do this? Using a DLL is the preferred way to do this (that's why they were invented). If you want to resolve your crashes, attach a debugger to your process and call DebugBreak() before entering your assembly, and step through it. The mistakes should be obvious. e: ollydbg even shows the current line of code while stepping through (if object files are available). Also, who allocates your memorymodule (and the nested pointers inside)?

This really. I actually used it in many projects, but the complications and non-certainty of it ever being finished or possibly be removed (which it has now), combined with the lack of support made me drop it. But i think it was far superior to making your own dlls, and use them through dllcall.

If you're looking to reduce polling amount, have a look at windows hooks (however they need to be executable extremely fast, and any hangs in the code might hang the system). If not, no, not really.

That is seriously cool. I really love the nostalgic feel of it, very good job.

Run("wmplayer.exe 'I:\Treasures\Treasures Listening Library\Supplemental Readers\Grade 1.m3u'") I don't think Windows recognizes ' as an alias to " the same way as autoit does it. Do like this: Run('wmplayer.exe "I:\Treasures\Treasures Listening Library\Supplemental Readers\Grade 1.m3u"')

Are we talking about running two seperate processes or one process parsing an autoit-alike script? There are differences. If the former, no to your answer, autoit runtime, once run, will not modify/reflect on it's source, thus you cannot add anything like functions (native), only variables.

You would have to make some inter process communication api, through which you can request commands and get results, either through cmdlines, standard streams, weird memory writing/scanning, or through wm_copydata messages etc. In short, you cannot do it directly.