awsdert

Didn't think about limiting alloca's ability to allocate from the stack. Using something I found [here](https://stackoverflow.com/questions/21754928/how-to-get-stack-size-and-stack-limit-of-any-thread-using-win32-api) to fix that in my latest commit

despite the failure runs the checks are still taking quite a long time to catch up with my latest commit so I'll check back tomorrow morning instead

uh, why is the bot builder not registering the next commit to try building?

also is there a way to configure the bot from my fork to stop trying the commit after the 1st failure? Don't really want to bother with subsequent trials if...

> > also is there a way to configure the bot from my fork to stop trying the commit after the 1st failure? Don't really want to bother with subsequent...

I was slow to notice the "No such interface supported" message was being tiggered. Since I don't check the output of `MyGetProcessId()` I can assume that somehow reaching the `Th32EnumProcessModules()`...

Well now I know why the heap stuff was failing for so long. Forgot to change which variable was checked at heap creation, only compiled at all because I forgot...

If all's good with the next round of tests then I'll start merging in those change pali made to commit next which should mark the final commit before the pull...

Quick check b4 I start merging pali's changes into my fork, is there anything with my current fork you want me to look at before hand? If I don't see...

Right, this PR should be ready to merge unless someone sees an issue I haven't noticed