OK, at great risk of over simplifying, this is an attempt to describe how eccoext works... (Dave's note on how hard this is...)
Please please please, add to and clarify this!

Below is Dave's very lucid insight and explanation, to which I add:

1) Some of the incredible fixes are plain, old-fashioned, one byte changes to the ecco code, allowing flexible multi-folder pulldowns, proper OLE object copying, numbering past 999, etc. On one hand it's something so tiny, that produces huge results. On the other hand note it is pure Slang genius behind the code breakdown/analysis and discovery of 99.9% of these key fixes. Simply astounding to me personally how clearly and deeply Slang has been able to decypher the code and pinpoint the ultimate and key 'fix' points.

2) Some of the incredible power is just plain old great concept + brilliant design + solid coding!! The structure of key folder assign tool is the same add-on tools have always been, using Ecco's built in DDE interface to manipulate in a programmed way the underlying data. True, that we can directly call the internal DDE routines without needing the DDE messaging, bypassing the middle-man so to speak, but that is a recent Slang breakthru bonus... the tools worked really great even before...

3) One key is the 'sandwich' approach. Using monitoring of the 'front end' (user input/actions), with 'back end' DDE based data manipulations. With this, amazing innovation has been possible. Add to this Slang's brilliant eye for detecting and uncovering the structures and routines hidden in the Ecco assembly code, and neat, otherwise impossible tricks become possible-- locking folders, item focus, etc.. and there in a nutshell, you have it!




Note that this is my current understanding and I certainly hope that my knowledge will evolve over time. My view will expand by having others revise and expand this page with corrections and additional insights. I certainly hope that it can ultimately give some insight into eccoext that will enable non-technical users to appreciate the possibilities that are opened by eccoext.//

For the most part computers just do one thing at a time, tediously executing instructions in the order that a programmer provided them.
Computers are VERY predictable, and unless there is a hardware failure do things the same way every time. (Ecco has not changed in over a decade, so it is VERY predictable)

In the "good old days" computer programs were "patched" by choosing a place in a program where you wanted to have something behave differently, and inserting a different instruction. Typically if the program looked like this:

000022 Do thing A
000023 Do thing B
000024 Do thing C
000025 Do thing D

you could replace instruction #000023 with something different, something like Goto 000087
(one of the first instructions that computers understood is to go to a different place for then next instruction, rather than to the next sequential instruction, sort of like a treasure hunt...)

so now our "program is something like:

000022 Do thing A
000023 Goto 000087
000024 Do thing C
000025 Do thing D
...
000087 Do thing B
000088 Do thing X
000089 Do thing Y
000090 Goto 000024

The computer certainly doesn't know what's going on, it just goes where it is told to go, and does what it is told to do... [Note that "Do thing B" still is executed, just that the instruction to do it was moved to make room for the "goto" instruction...]

In a more modern and complex world, it is possible for one program to run or "load" another program. If done correctly, the "loader" has complete control of the program that is loaded. So, one program can load another, and once the loaded program is under the loader's control, the loader can "inject" new instructions into the program similar to the "patches" from the old days...

By carefully monitoring how a program runs, it is possible for a talented programmer to figure out precisely what instruction is called every time a program such as Ecco does a particular thing, for example, when an item is changed or added.

If a "loader" program that "wraps" Ecco first: starts Ecco, then inserts a "patch" in the right place, it is possible to have new added code executed.

Ecco provided an "application programming interface" or API so that external programs could interact with Ecco and Ecco's data. This interface used a mechanism called DDE to pass messages back and forth between an external program and Ecco. Though very useful, many of the API features seemed to be provided for synchronization programs. The ability to interact with Ecco's auto-assign rules, presentation (like colors), and notepad filters were not in the API. The API also did not allow real-time interaction where an external program would be notified if something changed in ecco. The external programs needed to periodically check for changes and performance wasn't very good.

eccoext appears to work by implementing a "wrapper" that "loads" Ecco, and then "injects" patches or "hooks" that allow the loader to take control whenever the auto-assign code would normally be executed. Then eccoext appears to use other "hooks" to call the same code that would be used by the API to manipulate the data such as folder assignments, etc. Because eccoext appears to use the same code that was used by the API for manipulating the Ecco data, it can be assumed that it is quite reliable.

One of the more advanced features of eccoext is the ability to execute embedded code or "macros" when an auto-assign rule would normally be applied. The macros use a language called "Lua" which is heavily used in the computer game industry. Lua is a "high level" "dynamically typed" language that is similar in many ways to Python and Ruby. It turns out that Lua is a fairly obvious fit (once we've been shown the proof) for creating an embedded macro language for Ecco. Lua is also targeted at embedded applications such as inclusion in handheld devices and cell phones. It is my understanding that the Lua libraries provide most of the regular expression handling that is exposed by eccoext. (actually, if not mistaken, that is the perl REGEX engine doing that magic). Again, we can feel assured that the artful matchup of Ecco and Lua relies on lots of code that has already seen many years of refinement.

One thing that many of you might be thinking about these techniques is: "isn't that the way malware and viruses are created?", and you are quite correct in making that connection. But these "black hat" techniques are also used extensively in advanced development tools that are created for debugging and profiling programs during development. Their application to Ecco gives an incredible "new life" to this code that has not changed in a decade...

Enough for tonight...

DaveG