Alexandre Julliard wrote:
As far as I've observed (I've got Win2000 available), most Windows DLL's have 512-byte (sector) alignment internally, _not_ 4096-byte (page) alignment for the sections. This means that the separate sections can't be mmap'd (or else they'd lose their required relative relationships):
Actually the file alignment doesn't need to be 4096, it needs to match the filesystem block size. On a FAT filesystem the block size is 512 so Linux will happily mmap every section. On a 1k-block ext2 fs it will be able to mmap about 50% of them.
Looking at the kernel sources, it appears to be page-alignment, not filesystem block size that mmap needs to match. Rereading old wine-devel archives, it appears that the notion that the filesystem block size is involved is either from a very old kernel, or a misreading of some kernel comments. From linux/mm/mmap.c:
unsigned long do_mmap(struct file * file, unsigned long addr, unsigned long len, unsigned long prot, unsigned long flags, unsigned long off) . . . /* Obtain the address to map to. we verify (or select) it and ensure * that it represents a valid section of the address space. */ if (flags & MAP_FIXED) { if (addr & ~PAGE_MASK) return -EINVAL; } else {
Also, since DLLs and EXEs are not compiled as PIC (the MSDEV compiler not having such an option as far as I can recall), the fixup tables usually seem to apply to just about every page in the code section.
Only if the dll cannot be loaded at the preferred address, which shouldn't happen too often. I'm not saying your patch is useless, but I doubt the gain is as large as you seem to think.
It's worthwhile to point out that while many Win2K system DLLs may be 512-byte aligned, almost any app written in the past several years is probably using 4k alignment, since that was made the default with MSVC 5.0. It makes one wonders why MS would be using old compilers for the OS...
-Gav