So, what happens if I make a program that writes back to its original copy when it is run in the archive from DCS? Does Doors actually unarchive the program before it runs it, so that writing back is possible, or does it not and do I have to do that myself before writing back?

I think that DCS will give an archive error, but I could be wrong :/

I hope not... Anyway, Ill just try it out.


EDIT: It does not seem to give any problems. Yay!

Doors CS uses what I call Intelligent Writeback. When any program is run, it is copied (not moved) to RAM from archive, if it was archived. When the program terminates, Doors CS first compares the RAM and Archive copies. If they are identical, Doors CS deletes the RAM copy. If they are either of different sizes or different contents, Doors CS deletes the Archive copy and archives the RAM copy. Does that answer your question?

It thoroughly does, thanks I needed to know this because of the game saving I have been working on. I'll be uploading an update later today.

I'm a little unclear on what you're planning on doing, and slightly worried that it might potentially break things in the future. Might you detail what you are suggesting?

I am just bcalling to chkfindsym and using de + offset to copy data from the running to the original version of the program. I was only wondering about running archived programs in DCS since chkfindsym would return b = 0 or something if the program was archived, but it seems now that it never is.

The RAM copy of the program has a different name than the original Archive copy. If you were to modify the archived copy, Doors CS would just delete it anyway; there's no point to doing anything other than just modifying the RAM copy if you want writeback to occur. I strongly strongly do not recommend unarchiving, modifying, and rearchiving the original program. And if the program is in RAM, then it currently has a size of 2 bytes, so modifying it via ChkFindSym is a very bad idea.

Okay, what I do is, I only alter the data in the running version during the program. When quitting I copy all save and highscore data from the running to the original version. The funny thing is that the program has always been writing back in the random function, so I just assume no one has ever tried to run it from archive or was too shy/lazy to tell me about any errors that the writing back may have evoked.
Anyway, I need some way to know that the program is run from DCS so that I can skip the writing back and just let Doors do it. I know Doors will always write back if it has changed, but I want it to work without Doors as well so I need my own writing back routine.

Well, you could check if there is a DCS7 or DCS6 appvar on the calculator, and if so, assume you shouldn't do writeback. That's a good indicator of DCS being used in my opinion.

But what then if there is a DCS appvar, but the program is not actually run from Doors?

I think that would be highly unlikely, although I of course thought of that. There are more reliable ways to check if Doors CS is loaded, but they're much more complicated.

...and require a lot of code I presume?

I think I have it. Do other OSes allow running from archive? Because I could just use ChkFindSym to determine if the program is in the archive (unless of course somehow DoorsCS changes the entry in the VAT to flag the program as in RAM) and if it is, just don't write back. Only write back if it is in RAM.

Doors CS does not do anything to the original program's VAT entry that would prevent that from working.

That's cool. Should I do that then?

Yeah, that's a good way to do it; I think that's probably your most reliable method. If it's unarchived, write back starting at $9d95 (NOT to the program itself, though!). If it's archived, don't do anything.

Wait, that doesn't make sense. That's not going to quite work. You need to combine the two methods. If it's in RAM, _AND_ the DCS6 and DCS7 AppVars do not exist, then chkfindsym the program and write to it. Under any other circumstances, just do the edits near $9d95.

I don't see how my method won't work. I would never need to write back to the program at $9d95 because that's where I am copying from. The saves and high score lists are already updated in that version and I NEED to write them back to the original program at the very end before quitting, because the program might not be run by DCS.
Before I do the writeback I check whether the program is archived or not. If it is, I assume that it is run by Doors (do any other shells run archived programs?) and skip the write back.
The program uses a LOT of SMC, which changes all the time, so it's pretty safe to assume that Doors will ALWAYS do write back, especially if the save games or highscore lists in the running version are different from the ones in the original program.

Am I missing something here? I've actually implemented it like this and used all ways (Asm(NUMBERED), Doors archived and unarchived, home run etc.) to run the program and it did not fail yet.

EDIT: It actually did wipe my RAM once, but that is our friend which is manifesting itself again and it happened in the middle of a game I was playing.

You are indeed missing something. When the TI-OS runs a program from RAM, it copies it to $9D95, leaving a copy at where the VAT entry points. When Ion, Doors CS, and MirageOS run an ASM program, they move the contents to $9d95, leaving only a two-byte stub (the program's size word) where the VAT entry is pointing. Trying to modify the contents of the "program" where the VAT entry is pointing when there's only the two-byte stub there would be very, very bad.

But how can you do Intelligent Writeback then? You always have to move the running program back that way, right? I don't see how you can compare two versions of the program when the one in the VAT is gone. I mean, the original data is still there, right? Or do chells actually copy the program to $9d95 and then delete the original? What is the use of doing that?

By the way, I still have to see the very very bad effects of doing this, because the program as it is now, DOES write back to where the VAT entry is pointing. It just does not change the first two bytes there, so how could it be harmful?

Ugh, this is complicated...

1) When the program is archived, it copies a copy to RAM, which has a correct VAT entry (just not the same as the original RAM copy).
2) When the program is in RAM, it moves the contents to $9d95 from the VAT-pointed RAM variable. Intelligent Writeback is not an issue in this case; DCS (and the others) just move the contents of the program back to where they should be in RAM when the program completes.