RamonUnch

It seems indeed that is is impossible but if some indirect access to a close-by variable was badly performed it can change the value. for example: ```c #include int main(void)...

So I think I found the bug: ```c G[ (p[0]-0x28)%4 ] = ASCII; // 1B [28-2B] 4A ``` is not valid because even if p[0] is unsigned 0x28 is not,...

> thats out-of-bound access, valid access range of int y[4] is y[0] to y[3]. I wonder if compiler will spit warning message or not. In a simple case like this...

https://github.com/RamonUnch/GreenPad/pull/91 Also a cool side-effect is better performances and smaller exe (in my case).

I fixed the crash in `rUtfOFSS` reader by implementing Eof() with a greater or equal rather than an equal. I applied the modification to al readers because it should not...

Potential out of bound acess in rightOf(): https://github.com/RamonUnch/GreenPad/commit/f55656731ce35a8da3eb4d659ab5b3ccd6e0b417 I think it never caused problems but better be safe and a boundary check should always come before de-referencing.

Good idea I will give this a try.

Very Nice. Good idea to get rid of thunking all-together, this saves a 4KB VirtualAlloc for each window. Which SDK version are you using? When I installed VC++4.0 I do...

Very nice indeed! Does it have a repo with official release? so I can link it in the readme? I tried to cross compile using OpenWatcom but it seems Alpha...

Nice to see that, so the circle is almost complete in term of CPU architectures. > (P.S.: and LOBYTE(app().getOSVer()) goes strange on ARM64, shown in screenshot) Maybe we should create...