mactype
mactype copied to clipboard
snowie2000
新版本2023.823要出了吗？
目前还在再次熟悉detours的阶段，目前是可以稳定运行的情况。
尝试了detours自带的注入dll的功能，会导致explorer出错
这个比EasyHook有什么好处吗？detours记得十几年前一开始就是用它的
切换到 Detours 之后，是不是就能支持 ARM 版的 Windows 了呢？一直期待着 Apple 芯片上运行的 Windows 也能使用MacType……
切换到 Detours 之后，是不是就能支持 ARM 版的 Windows 了呢？一直期待着 Apple 芯片上运行的 Windows 也能使用MacType……
很遗憾的是，目前的结论是不行。 虽然detours确实支持arm，但是经过测试，detours的createwith方法并不能用于mactype，这和createwith的工作原理有关。 简单来说： mactype希望处于“能加载最好，如果加载不了也不影响应用正常使用”的状态，所以一直都是使用自己编写的汇编引导代码来实现这个效果的，但是好像就是因为这个代码有些问题导致目前出现的部分dll错误等等。
createwith的实现方法就另辟蹊径，直接将mactype.dll作为应用的必须dll，让Windows帮忙加载。优点就是如果能加载，就非常稳定，免去了汇编可能存在的稳定性问题，缺点就是如果对方应用禁止第三方dll（如游戏等），则应用会直接拒绝启动。目前测试已知大量Windows store app无法启动，Windows store本身也无法启动……
切换到 Detours 之后，是不是就能支持 ARM 版的 Windows 了呢？一直期待着 Apple 芯片上运行的 Windows 也能使用MacType……
很遗憾的是，目前的结论是不行。 虽然detours确实支持arm，但是经过测试，detours的createwith方法并不能用于mactype，这和createwith的工作原理有关。 简单来说： mactype希望处于“能加载最好，如果加载不了也不影响应用正常使用”的状态，所以一直都是使用自己编写的汇编引导代码来实现这个效果的，但是好像就是因为这个代码有些问题导致目前出现的部分dll错误等等。
createwith的实现方法就另辟蹊径，直接将mactype.dll作为应用的必须dll，让Windows帮忙加载。优点就是如果能加载，就非常稳定，免去了汇编可能存在的稳定性问题，缺点就是如果对方应用禁止第三方dll（如游戏等），则应用会直接拒绝启动。目前测试已知大量Windows store app无法启动，Windows store本身也无法启动……
切换到 Detours 之后，是不是就能支持 ARM 版的 Windows 了呢？一直期待着 Apple 芯片上运行的 Windows 也能使用MacType……
很遗憾的是，目前的结论是不行。 虽然detours确实支持arm，但是经过测试，detours的createwith方法并不能用于mactype，这和createwith的工作原理有关。 简单来说： mactype希望处于“能加载最好，如果加载不了也不影响应用正常使用”的状态，所以一直都是使用自己编写的汇编引导代码来实现这个效果的，但是好像就是因为这个代码有些问题导致目前出现的部分dll错误等等。
createwith的实现方法就另辟蹊径，直接将mactype.dll作为应用的必须dll，让Windows帮忙加载。优点就是如果能加载，就非常稳定，免去了汇编可能存在的稳定性问题，缺点就是如果对方应用禁止第三方dll（如游戏等），则应用会直接拒绝启动。目前测试已知大量Windows store app无法启动，Windows store本身也无法启动……
换个注入方式， 挂个image/Process NotifyRoutine回调 起一个进程插一个，很完美，进程起来第一时间就注入进去hook了 store这种 无法启动时权限问题，要换注入方式,
