I remember encountering a problem a long time ago, but this is before my Axe and assembly skills were too adept and I figured I was just doing something wrong. However, just a few moments ago, SirCmpwn was having trouble getting the size of archived programs, so I looked into it to help out. In the process of testing the reading of archived programs with a randomly chosen program target (which happened to be a protected assembly program) and looking at Commands.inc, I realized that p_GetArc doesn't check for protected programs!

The two bytes that specify the size of the variable should be the 2 bytes immediately preceding the pointer returned from GetCalc(), whether using the normal or archive method. This is easy for variables in RAM, because the variable's data starts with two bytes for its size, and the VAT pointer for the variable always points right to it. However, when variables with variable names (programs, lists, appvars, and groups) are archived, the variable's name (and possibly other data, I'm not sure) is appended to the file in front of the two bytes indicating size. To correct this, Quigibo's archive variable locating routine determines the length of the variable's name from the VAT and adds that to the pointer to skip this unwanted data and to be consistent with unarchived variables. However, he forgot to check if the variable's type is a protected program, so it thinks that any protected program doesn't have this and doesn't correct for the name length.

Ok, I've fixed all the problems mentioned so far.

Yeah, i've been trying to figure out what was happening, but crazy things were occuring in my program combiner, which was making it impossible for me to continue development on PortalX until the issue is fixed unfortunately, as I can no longer generate the executable.

Nice, I look forward to it!

Cool to hear the bugs were fixed

^

Also, this is fairly random and unreproducible, but sometimes I will run into random BAD SYMBOL errors while compiling (usually an archived program). Sometimes when I unarchive it the compile goes smoothly and error free. More rarely, it will throw another BAD SYMBOL, and upon pressing prgm to goto, the entire program after a certain point seems to be corrupted (lots of random tokens, etc.) I remember that the goto-prgm thing used to be unstable with large programs. What constitutes a large program: one with lots of library files whose compiled code comes out to 16kb count? (The main program is 5 kb and the largest library is 3kb...and the corruption will usually happen to any of them, not just the main program)

The app length bug was fixed in 0.4.8

Also, this is fairly random and unreproducible, but sometimes I will run into random BAD SYMBOL errors while compiling (usually an archived program).

That bug was supposed to be fixed in 0.4.7  Have you had that problem in the later versions?

Sometimes when I unarchive it the compile goes smoothly and error free. More rarely, it will throw another BAD SYMBOL, and upon pressing prgm to goto, the entire program after a certain point seems to be corrupted (lots of random tokens, etc.) I remember that the goto-prgm thing used to be unstable with large programs. What constitutes a large program: one with lots of library files whose compiled code comes out to 16kb count? (The main program is 5 kb and the largest library is 3kb...and the corruption will usually happen to any of them, not just the main program)

This is a problem I still can't figure out.  The OS must be handling large files differently than small ones for some reason because I pass control to the OS before the actual scroll.  If anyone knows more information about the BASIC editor context variables, I could definitely use your help!