https://bugs.winehq.org/show_bug.cgi?id=51539
--- Comment #4 from Martin Storsjö martin@martin.st --- (In reply to Alexandre Julliard from comment #3)
I'm not sure how you are reproducing this since we should refuse to map executables to a different address
Oh, I see - I missed that this was an intended side effect of 28fe84da45bea7de56539b50eac8ebcec54342de (ntdll: Load the main image from the Unix side.) - previously this was implicitly allowed via the "if (status == STATUS_IMAGE_NOT_AT_BASE) status = STATUS_SUCCESS;" line, but now it errors out indeed.
I did most of my testing around these two commits, and you're right that I can't even get that far on any newer version, if unable to map the executable in the right spot.
So before a3c92a02cc7014cfdb1f90f1d070037868067097 (server: Get the process entry point from the exe image info.), mapping the executable at any address worked just fine, and after 28fe84da45bea7de56539b50eac8ebcec54342de it's explicitly disallowed.
but in any case b08b4b8213949ecfc8eb449b5676552669ec3211 will hopefully help.
Thanks - although as mapping the executable at a different address isn't allowed any longer I guess this doesn't really change anything...
I guess I should just try to implement the preloader for arm instead, to put it on par with the other architectures, which hopefully would let it map things at the desired addresses?