[Linker flags for Borland and Intel omitted.]
I'm not even sure if this is the right fix: should we really be passing such large arrays around on the stack in the first place?
Frankly, I'm completely puzzled that apparently relatively modern Windows versions can't handle medium-sized (5 KB) stack allocations. After all, the wonders of modern MMUs enable operating systems to handle similar tasks such as demand-paging just fine. And Unix-style operating systems do handle arbitrary stack growth just fine.
I'm going by memory here, because I couldn't find the relevent MSDN pages on a quick search, but I believe what happens is this: There is only one guard page, and it's 4K in size, so a 5K object that starts in valid memory can still "straddle" the entire guard page. Since the stack winds downward, attempting to access the start of the object will actually access the part that's just "dropped off" the bottom of the guard page, and bang goes your application.
Looks like the only option is to allocate the data area on the heap. Which increases the overhead for creating and destroying a mersenne_twister quite a lot.
Feels like it should be a PIMPL to me, but that's only personal preference. Even though it will slow your construction, a copy-on-write design should give you much faster copy-assign-swap etc. My gut feeling is that kind of change should wait till after 1.33 though - we're only a few days from release after all! HTH, John.