4 ms·
ARM support for Windows seems like it would predate this emulation effort by quite a while, but I'm not sure. Historically system DLLs on windows aren't vulner
by kevingadd 5y ago
ARM support for Windows seems like it would predate this emulation effort by quite a while, but I'm not sure.
Historically system DLLs on windows aren't vulnerable to this kind of API skew because there's a special ABI specifically for windows APIs referred to as "stdcall", everything exported from user32.dll etc is exposed via that ABI. I would expect the same to be true here. Note also that historically there aren't separate copies of all the system DLLs on windows for 32 and 64 bit, most of the 32 bit DLLs are full of thunks that jump to the 64-bit ones if you're running on a 64-bit Windows. So that approach would also be possible here.
- lukeh 5y agoAre you sure? https://docs.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details https://docs.microsoft.com/en-us/windows/win32/winprog64/wow... suggests otherwise.
- kevingadd 5y agoI'm not sure what you mean, it says right there in the article that the 32->64 stuff is done in user mode and that there are thunks in the 32-bit binaries.
- hrydgard 5y agoNot the case. Actual thunking is only done when calling into the kernel, you can't load a 32-bit DLL into a 64-bit process or vice versa.
- fredoralive 5y agoI think GP is thinking more of how Windows 9x did 16 and 32 bit, which was full of funky thunking and only really had one set of libraries AFAIK (awaiting inevitable correction).