Directly mapped from the disk? A whole filed can't be mapped from the disk imho... if I take a look into the PE header of a CE executable created with FPC, the physical address of sections differs from the virtual address. So they're clearly intended to not be mapped from the disk (wouldn't work
). Could be that it /would/ be possible, in this case the compiler/linker/etc. probably would need to create a PE file that supports this (identical physical/virtual addresses, and imho there's another header field that would need to be adjusted, which just won't come into my mind currently).
So even if applications would be stored in RAM (I've read something about old PocketPC phones loosing applications when battery is empty due to that?), they would need to get more memory where they could be stored correctly mapped when running.
Another reason why I think that they are not directly mapped: SHCloseApps, which goes and frees RAM by sending WM_CLOSE to other applications. If they were mapped on disk, this would be useless, as it wouldn't free any memory
Without UPX, some fixed sections would probably even be loaded only once even if multiple instances are running. With UPX, the PE loader can't determine which sections would support that, so all sections would be loaded for each instance, thus creating another memory overload in addition to compressed+expanded usage (just my few cents of thinking, I'm writing this where I've escaped too from the heat, and where I don't have my PE cookbook at hand
).
But imho: it makes sense to allow WinCE applications to run in only one instance anyway, since especially on smartphone devices without the touchscreen, killing tasks or even switching to already running tasks is a real pain. So it would only be the decompressor code (I hope it wouldn't load the compressed image into memory, imho the decompression could work fine with the disk as source
) that'll mean additional memory usage then.