Create new mailing list wine-isv?

Peter Beutner p.beutner at gmx.net
Fri Dec 16 08:41:01 CST 2005


Michael Jung schrieb:
> On Friday 16 December 2005 12:54, Peter Beutner wrote:
> 
>>Let's just look at the problem with the memory layout. Wine relies on the
>>possibility to load certain codes at fixed addresses as this is how it
>>works under windows. Linux choose exact the opposite direction, i.e. try to
>>ensure that libraries are loaded at random places in the memory. This is
>>not a missing feature it is a complete different design decision. And I
>>seriously doubt that the kernel/or glibc guys will import the security flaw
>>from windows to always load code at fixed positions. So wine will have to
>>live forever with it's custom preloader hack to emulate the windows process
>>environment.
> 
> 
> Well, wine is loading code at fixed positions. So we are bypassing this 
> security mechanism, right? If I understand correctly, if the kernel/glibc 
> guys will "fix" this, Wine will have major problems. 
> 
> This means there are many people (all wine users) dependend on being able to 
> load stuff at fixed positions. Since we are doing it anyway, and if the PE 
> loader would be integrated with the standard ELF loader, the kernel could 
> make an exception for PE executables. That's what I mean about the 
> environment adapting to given usage scenarios like wine. If this is too much 
> of a security problem for a given system, one would'nt install wine anyway. 

The point is that it won't be integrated in neither kernel or glibc. At least I can't 
imagine that this will happen. Why should anybody integrate another binary loader/memory 
layout into the kernel/libc where there is already a fully working one?
Just because some people don't want to spend time/money to port their code to linux?
I don't think with an argument like that you get this stuff included somewhere :/
(not even mentioning the flaws in the "windows mechanism").

So no, I don't believe that the environment(e.g. kernel/libc) will be adapting to wine in 
this aspect.

Don't get me wrong I still think it is perfectly valid that wine is doing that sort of 
hack to get existing windows applications working but you really shouldn't advertise it as 
a solution to platform independence and encourage developers to go this way.




More information about the wine-devel mailing list