Dennis Duda

We can probably be 100% sure now :) Found this by change while browsing reddit: http://bytepointer.com/articles/the_microsoft_rich_header.htm 

>So it's possible all the files were treated as C even with .CPP extensions. That was one of my very first assumptions about the project haha

> is that sometimes the decompilation is not accurate. It really depends on your definition of accurate. If Hex-Rays and the compiler used to recompile were assumed to be bug-free,...

> I am pretty sure some of these are a violation of the infamous "strict aliasing" rules and could cause optimized code to be incorrect Oh yeah, definitely. BTW: From...

> Thanks for pointing out a small '!' I missed. You're right, that code is weird. if(!pre) means prefix on value equals 0 but, if(post) means suffix non zero. Oh...

Quick ping over here - is there any chance to get #59 fixed?

Hmm, even without the deadlock and with the Windows fix, I think bug 2 in the issue is not addressed. `persist_window` does not seem to save the maximized state in...

This can definitely be fixed - the problem is that there is absolutely no output buffering in `OutputLog`, and `OutputMainChannel` generates the hex dump view mostly one char/byte at a...

Just did a quick test: Before: ``` StartTime: 2023-12-27T17:09:54+0100 EndTime: 2023-12-27T18:29:37+0100 ``` (3.2GB mainError.txt) Commented out the `OutputLog`s in `OutputMainChannel`: ``` StartTime: 2023-12-27T18:40:32+0100 (.scm capture from drive was done at...

> assuming the spread of missing platform support is sufficiently narrow As a data point: Getting this on the latest (both from AMD and through Windows Update) driver for my...