Note

[zaval]

I wanted to check if my provider's IP is still blacklisted by some service this forum makes use of and decided to tell about a quirk I recently stumbled upon when testing my loader on real x64 hardware. So you can take a note about it or even check if this applies to your machines. The laptop in question is Dell Latitude E6420. Its EFI_FILE_PROTOCOL.Read() function returns error EFI_VOLUME_CORRUPTED on requests to read 0 bytes from a valid file. Such a request should return EFI_SUCCESS, what other real hardware firmwares and OVMF on emulators do. But this one returns error, so, if for some reason, you can have such a request in your loader, be warned. Why you can have it, another question. For example on a section, containing only unitialized data, so it has no file data. instead of checking everytime if a section has file size not zero, as an optimization, you could skip the check in your section loading loop. The Latitude fw doesn't want you did so. Also, if anyone tests on other Latitude laptops, maybe you would be interested to know if this oddity is present. especially interesting are new models. Is it still there, E6420 is from 2011.

[nullplan]

OK, but if I have to decide between a conditional jump and a file system call, I'm going to assume the latter is the more costly of the two. Saving the conditional jump in favor of an unneeded file system call seems like a bad idea.

[zaval]

I won't argue, I went with exactly conditional jump (PE specifics requires that anyway, for the logical purity so to say), but still, it's a bug to return "volume corrupted" on such a call. Finally, who knows what else surprises it's holding in its sleeve. real hardware has proven yet once, its programming is a real PITA, going beyond just following manuals.