Specific name for shell application not loadable through shell - any reason why this may be?
JackMacWindows <jackmacwindowslinux@...>
Hello,
I asked a question here a few months ago about a problem I was experiencing with an application I was working on. Basically, the program would work just fine under QEMU (and after later testing, the EmulatorPkg as well), but when trying to run it on a real machine, the application would fail to run with EFI_UNSUPPORTED. This failure would happen before the application even ran - adding a print statement at the beginning of the entry point would not show anything.
Recently, I decided to try to fix this issue. After a bunch of debugging, I ended up changing the dsc/inf files so that they were the exact same as another program that worked, except for the name. This still did not work. That led me to the conclusion that for some reason the name I decided to use for the app ("CraftOS") was causing it to fail, which was verified after I changed the name to something else ("CCEFI").
I’m glad to have been able to fix this issue, but I’m curious why the name would cause it to fail to load. I don’t understand how the name would cause some sort of failure only on real systems. Perhaps there is a bug in a reference UEFI that causes the failure, that the OVMF firmware doesn’t have. (Note: I tested the app on various UEFI versions from 2.3 to 2.8, and none of them worked.) Or maybe that name mirrors some pattern in the PE header that causes a failure when reading the image.
For reference, I mainly used the stable202002 release, but also tested on various versions going back to UDK2015. I built on both macOS using gcc-5, and Windows using VS 2019. The name that didn’t work was "CraftOS" and the name that did work is "CCEFI".
If anyone has any ideas as to why this happened, I’d love to hear them.
JackMacWindows
I asked a question here a few months ago about a problem I was experiencing with an application I was working on. Basically, the program would work just fine under QEMU (and after later testing, the EmulatorPkg as well), but when trying to run it on a real machine, the application would fail to run with EFI_UNSUPPORTED. This failure would happen before the application even ran - adding a print statement at the beginning of the entry point would not show anything.
Recently, I decided to try to fix this issue. After a bunch of debugging, I ended up changing the dsc/inf files so that they were the exact same as another program that worked, except for the name. This still did not work. That led me to the conclusion that for some reason the name I decided to use for the app ("CraftOS") was causing it to fail, which was verified after I changed the name to something else ("CCEFI").
I’m glad to have been able to fix this issue, but I’m curious why the name would cause it to fail to load. I don’t understand how the name would cause some sort of failure only on real systems. Perhaps there is a bug in a reference UEFI that causes the failure, that the OVMF firmware doesn’t have. (Note: I tested the app on various UEFI versions from 2.3 to 2.8, and none of them worked.) Or maybe that name mirrors some pattern in the PE header that causes a failure when reading the image.
For reference, I mainly used the stable202002 release, but also tested on various versions going back to UDK2015. I built on both macOS using gcc-5, and Windows using VS 2019. The name that didn’t work was "CraftOS" and the name that did work is "CCEFI".
If anyone has any ideas as to why this happened, I’d love to hear them.
JackMacWindows