I had to make two modifications to Milton's code before it ran properly on my machine.
1)
Trying to allocate big_chunk_of_memory at address 1<<18 failed with error code 0x1E7 (ERROR_INVALID_ADDRESS).
My workaround: #define HEAP_BEGIN_ADDRESS ((LPVOID)(1ull<<34))
On my machine most memory below 0x7FFF0000 is already occupied right after starting the application. Things like user32.dll and kernel32.dll live there. The Milton.exe module lives somewhere around address 0x13XXXXXXX. After that I have a gap of about 8 GB free addresses followed by various DLLs (e.g. opengl32.dll) all the way up to 0x7FFFFFFE0000. It might be wiser to make HEAP_BEGIN_ADDRESS be a very high address like 1<<63. If I remember correctly, that's what Casey did in HMH. I don't know whether Windows actually guarantees any address ranges to be free.
2)
Vertex shader failed to compile with the following errors:
ERROR: error(#271) Explicit version number 120 not supported by GL3 forward compatible context
ERROR: error(#273) 1 compilation errors. No code generated
My workaround: Change #version 120 to #version 130 in imgui_impl_sdl_gl3.cpp and milton .cc
It seems like this wouldn't have been a problem in release mode, since Milton only uses a core profile context, #if MILTON_DEBUG.
It's interesting to see how subtle differences in memory layout and graphics driver can break a program. Once the program runs, it runs reasonably well. The amount of processing power used by Milton depends heavily on the speed of the stroke. I'm not an artist myself, but I am looking forward to have a closer look at Milton's code.