:bm1::bm2::bm3::bm4::bm5::bm6::bm7::bm8::bm9::bm0:

@bonkmaykr@canithesis.org

21 Male, Missouri, United States
Running Canithesis Interactive & Worlio LLC
Software engineer, newly an Amiga + Saturn nut

Currently working on a shmup game called "Time Falcon", my own game engine for it, and some other stuff. My posts can range anywhere from deep nerd thoughts to brainless shitposting.

Expert at run-on sentences

Give me liberty or give me death
XMPP/Jabberbonkmaykr@canithesis.org

59 following, 45 followers

1 ★ 1 ↺
xianc78 boosted

[?]:bm1::bm2::bm3::bm4::bm5::bm6::bm7::bm8::bm9::bm0: » 🌐
@bonkmaykr@canithesis.org

@bonkmaykr@canithesis.org pointless complexity aside, the real problems are that this only works with debugging binaries and only if their symbols are in Visual Studio format, and Windows doesn't even remember where the loaded DLLs are from. allegedly. MSDN didn't exactly give me a single concise page or two explaining this. anyway, it can't print nameless addresses like glibc.

the entire point of getting a backtrace at runtime and not from your debugger directly, is to get information about a crash in a customer's stripped binary. this code is entirely useless for that purpose. i am sure there is another way to use CaptureStackBacktrace to get output similar to GNU's backtrace_symbols but it isn't documented anywhere I could find.

    History