Replies: 1 comment 1 reply
-
I think there's a misunderstanding here, and looking back it probably wasn't clear in the video. I didn't patch out an SSE2 instruction, I patched an erroneous check .NET's JIT compiler did that was causing it to emit SSE2 code on a platform that didn't support it. I don't suspect SSE2 will be an issue for .NET (at least 2.0-3.5) moving forward. That being said, your idea could be interesting if this gets spun off into a more general kernel extender for apps outside of .NET, and would be worth looking into at that point. |
Beta Was this translation helpful? Give feedback.
-
Problem:
While the rogue SSE2 instruction may have been a one-off in the installer, you are going to run into a LOT of instructions that aren't implemented when running .Net 2.0 applications and especially later versions. This means the current method of patching executables is unsustainable and will be increasingly hacky when there are integrity checks for the binary.
Solution:
Instead of getting rid of unknown instructions, you should polyfill them. This is possible because on Windows 95 executing an illegal operation causes an Invalid Opcode Exception which is handle as such: IDT -> VMM -> VPICD (Virtual Programmable Interrupt Controller Device). Windows 95's VPICD service allows you to install an interrupt specific handler using the
VPICD_Virtualize_IRQ
function.To make a polyfilling VxD then someone would need the Windows 95 DDK and a PDF with info like Writing Windows VxDs and Device Drivers (1996) (click "GET").
Beta Was this translation helpful? Give feedback.
All reactions