The root of the bug is that, if FMSLogo has an unhanded "stop" error, the routine which implements BITMAPTURTLE would do nothing. In most cases, this is what we want, but in this case, the routine was called from the WM_PAINT message handler, not the Logo evaluator, so it would cause this bitmapped-turtle drawing part of WM_PAINT to do nothing. Every time a new instruction was run in the commander, it would save the current state of the "stopping_flag", run the command, then restore "stopping_flag". Then WM_PAINT would fire and this routine would see that FMSLogo was still in a stopping state and again, it would nothing. Once the stopping_flag was set, there was no way to unset it.
Depending on how you look at it, this could be considered a regression from MSWLogo. I had earlier fixed a bug where this condition would cause FMSLogo to have an unprocessed "halt" error, which caused the next command to always throw a stopping error. The fix was to backup and restore the state of stopping_flag while running any instruction from the commander. But because the stopping_flag is now always restored after it is run, the WM_PAINT message has no way of clearing it.
The fix for this bug is to ignore the state of stopping_flag from the context of WM_PAINT. The only time that this flag should be honored is if we're in the evaluator, in which case, it's used to ignore further Logo instructions.
