ABC freezes the machine if END is bogus

Reported here, as ABC is part of the DDE which is ROOL… ;-)

Using {NEWHEAP} (I don’t bother with the old way, it’s just painful and quirky), I made a “too-early-not-enough-tea” booboo:

END = (4096 * 1024) : REM Give ourselves 4 megabytes

Upon running this, ABC promptly hung in a non-recoverable way. Alt-Esc popped up the usual stop task dialogue, but the task was too far gone to relinquish control (crash in the module?).

It’s worth noting that BASIC coped perfectly fine, most likely by completely ignoring the request as “stupid”.

Therefore:

• ABC shouldn’t be allowing memory allocations to be set less than that which is necessary for the program itself and whatever memory the runtime requires. Possibly the simplest method (Steve can correct me if I’m wrong here) is to simply ignore the request if the user is trying to set END to less than LOMEM. – it’s not less, it’s correctly more

• Tidy up the exception handling a little. A failure in a BASIC-like environment really oughtn’t require the reset button being fondled…

Hmm, turns out that my original calculation is correct. 4096 * 1024 is indeed 4MB. It’s not 4*, it’s 4096*!

Which, as the first instruction in a program, causes ABC to effectively hang the machine.

Is it not setting WimpSlot accordingly?

Interestingly it works if I leave out the END assignment. The environment looks like it expands the slot as necessary – with the Next slot set to 64K, it’s more than happy to start up and load in ~2.5MB of data.

Conditional compilation ( {NOCOMPILE} ) ‘fixes’ this, but END= is still broken…