On Wed, Jun 14, 2017 at 10:53 AM, Alan Cox <alan@llwyncelyn.cymru> wrote: > Mostly the latter. If you want the full glorious horror story take a look > at how windows16 does call stack frame fixup for 16bit apps. > > (Short version - each stack frame pushes bp. Windows 16 inc's bp before > pushing and decs after if the function is far, thus allowing the windows > OS code to walk the stack frames and modify each far return according to > what is and isn't in memory and where it moved) Oh, nice, sort of! I found https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=11203 which explains it in more words, but I probably would have understood your explanation if I had thought about it some more :) > We could modify the compiler to do that, but it's up there with coding > while drunk on 'good idea' rating. Yeah, it was pointed out in the comments on the above article that if you corrupt your stack you're going to make the kernel corrupt some other memory. I presume that modifying far pointers to code within the code (rather than within the stack as is covered above) on Win16 relies on having a relocation table, and ELKS binaries don't have relocation tables since they're small model, correct? > That was more because a DOS program owns all of memory so you don't know > how much to give it. Oh yeah, of course, thanks! >> And regardless of moving away from tiny model, I gather that moving to >> OpenWatcom just for the optimisations and ANSI C would potentially be >> worthwhile? > > 16bit gcc is probably better. I was thinking that at least OpenWatcom is maintained, but I didn't think to check if anyone had resurrected 16-bit GCC in the last 3 months :) Thanks! David -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
