[Bug 13915] Oblivon Script Extender (OBSE) fails to start ("privileged instruction")

wine-bugs at winehq.org wine-bugs at winehq.org
Tue Aug 24 06:17:18 CDT 2010


http://bugs.winehq.org/show_bug.cgi?id=13915





--- Comment #55 from Anastasius Focht <focht at gmx.net>  2010-08-24 06:17:12 ---
Hello,

--- quote ---
Actually the offset from the base address may not be the same in the other
process, because the PE header needs to be aligned to a 64k boundary. You'd
have to look up the RVA in the remote PE header manually.
--- quote ---

Sure, populating remote process PE headers would be completely safe ...
Your scenario is more a corner case that applies to executables that are
specially crafted by people that make an art of "optimizing" everything in
headers (e.g. unusual load bases, section alignments) - unlikely to happen for
Wine core libraries (unless someone messed with the build system, explicitly
specifying preferred load bases). 

I wanted to give him a "quick" solution without going through the hassle of
parsing PE headers and section tables.

Anyway, do you agree this bug is a WONTFIX?
Wine can't guarantee that core dlls (ntdll, kernel32, user32) will always get
the same load base in all address spaces (with ASLR switched off).

Though I wonder if certain Windows core dlls still have an "immutable" load
address (=preferred base).
It was a requirement in various Windows versions to support all these brain
damaged software that made certain assumptions about system dlls.
If some executable's preferred image base overlaps with core dlls, the infamous
"illegal system dll relocation" would appear and the OS loader refused to
process further.

Regards

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list