Oh. I get it now.

03EF404501C9

03 tells it to take the next three bytes as a search string. That brings us to 01, which tells it to take the next one byte.

Is that right?

Now you've got it! The only weakness to this type of system is that it's much harder to iterate backwards, but I don't see how that's significant to us.

True. Now, is 03 a one or two byte number?

And for my own segment, is there a way, in asm to return a list of all program vars on the calc?

03 is a one-byte number, EF4045 is a three-byte string, and 03EF404501C9 is a six-byte string. And yes, there are easy ways to iterate through the list of program variables on the calculator in ASM.

Can you possibly explain to me how so I can attempt it with axe, or supply hex for it to be written inline? Or both? And can it be stored so that I can access it in Axe, if its done in asm?

To be honest, I'm not that sure about the last point. I can show you the skeleton code for iterating through the VAT, but how to present it to you depends on what you're doing to do with it. Do you want to look at the name? The contents? Something else? Each of those has its own set of caveats to go along with it.

Just names. All I need is a list of the names of all programs on the calc returned into an appvar, which can be called BTemp. And I would need them to be either delimited by commas or in the format you plan on using for the search string.

I need to run to the office, so I'm not going to post the code for this immediately, but I'll start you on the way. Basically, you'll need to do two passes through the VAT: first one will find the total number of name bytes plus one extra byte per name for the name length. Then you create the appvar with that size, then on the second pass through the VAT you populate the appvar.

I would not know how to do that in Axe. I'll work on what I can in the meantime, though.

Also, when you're done compiling the list of specific mal-tokens that should be scanned for, if you can send the list to me for inclusion in the installer, that would be great. The reason being (tell me if you agree or not) that it makes the program more stable(?-is that the word im looking for) to have the installer itself CREATE the appvar than to require the user to send 2 or more files to their calc.

Yeah, I agree, the fewer programs that better. I'm still slightly unclear why the appvar of program names is necessary; I believe I may have lost track of something somewhere. It seems to me that the appvar should be kept up-to-date with the current programs on the calculator at any rate, no?

No. I just need a temporary variable to hold the names of the programs while scanning. It will only be created with an up to date list when a scan is conducted and destroyed when finished. and the appvar because the appvars are really the only external variables im comfortable handling with Axe.

Ah, that makes sense then. This'll be relatively easy code to write then.

Edit: Would you prefer comma-delimited names, length-prepended names, or fixed-length names padded with spaces?

Also, Kerm, for the segment of code that installs the RunProg Hook, does it take extra coding to make it "chainable"? Can you make it specifically compatible with DCS's RunProg Hook?

Yes, absolutely. Do you need me to write the chain part?

Yes, if you wouldn't mind. I know no assembly, remember. lol.

I think this will work, although I haven't gotten a chance to test it yet. This is of course the code to populate the appvar:


Code:

Nice. Can you just change the name of the target appvar to "BTemp", if it isn't to much trouble. And can u either post the hex please, or post here the link to the Hex Editor you once mentioned to me. Thank you very much.

The hex editor is XVI32, but that wouldn't help you unless you compiled the program first. Here's XVI32:

http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm

To compile, you could use the DCS SDK:

http://www.ticalc.org/archives/files/fileinfo/341/34192.html

For the sake of simplicity, keep bumping this, and I'll remember to compile and test the code, then dump the hex here.

ok. thanks.

Also, Kerm. In the length-prepended system for the hook, you said that two hex chars equals one byte. How will it be for the appvar routine? Would the appvar look like this for the program AAA?

03AAA

no, it would looke like 03414141. 03 is one byte, and 41 is the one-byte representation for 'A'. Again, this is the byte [41], then the byte [41] etc, NOT '4''1', '4''1'!