non-deterministic enumeration of imported libraries

[mewmew]

Upon two consecutive executions of binee (with added debug statements for SearchFile, the following debug output was obtained. Notice that rpcrt4.dll follows shell32.dll in the output of the first execution, while msvcrt.dll follows shell32.dll in the outut of the second execution; thus indicating non-deterministic results.

emu.SearchPath
SearchFile("apisetschema.dll")
SearchFile("ntdll.dll")
SearchFile("kernel32.dll")
SearchFile("shell32.dll")
SearchFile("rpcrt4.dll")
SearchFile("advapi32.dll")
SearchFile("secur32.dll")
SearchFile("shlwapi.dll")
SearchFile("gdi32.dll")
SearchFile("user32.dll")
SearchFile("msvcrt.dll")
SearchFile("version.dll")

emu.SearchPath
SearchFile("apisetschema.dll")
SearchFile("ntdll.dll")
SearchFile("kernel32.dll")
SearchFile("shell32.dll")
SearchFile("msvcrt.dll")
SearchFile("rpcrt4.dll")
SearchFile("secur32.dll")
SearchFile("advapi32.dll")
SearchFile("shlwapi.dll")
SearchFile("gdi32.dll")
SearchFile("user32.dll")
SearchFile("version.dll")

[mewmew]

I think this was the only source of non-determinism was in ImportedDlls, and as such, this issue should be fixed by #42. Given the nature of non-deterministic bugs, this cannot be guaranteed.

As such, it would be good to add a test case that has a few additional imports (except kernel32.dll and ntdll.dll which are always at fixed locations in the list of imported libraries). Any CI test case failures would then let us know if this issue was also caused by other non-deterministic computations.