"Felix Nawothnig" felix.nawothnig@t-online.de wrote:
For PE files there is a hack in kernel/except.c which does COW for resource data - but winelib apps crash when they try to write to it. (If this is a design-decision please tell me)
As it's clearly indicated in the error message in kernel/except.c only broken apps try to write to the resources. What your application is trying to do?
Dmitry Timoshkov wrote:
For PE files there is a hack in kernel/except.c which does COW for resource data - but winelib apps crash when they try to write to it. (If this is a design-decision please tell me)
As it's clearly indicated in the error message in kernel/except.c only broken apps try to write to the resources. What your application is trying to do?
It tries to write to a resource, which seems to work under Windows even if .rsrc is marked as readonly. The pointer returned by LockResource is not const so I'm not sure if those apps qualify as "broken" anyway - they are just exploiting undocumented (?) behaviour.
By the way, anyone knows if writing to a (readonly) resource throws an exception on windows (which is handled & ignored by kernel32.dll) one can catch or does the PE loader maybe ignore the RO flag for .rsrc? (can't test this since mingw seems to mark .rsrc as RW...)
-flx
Felix Nawothnig felix.nawothnig@t-online.de writes:
By the way, anyone knows if writing to a (readonly) resource throws an exception on windows (which is handled & ignored by kernel32.dll) one can catch or does the PE loader maybe ignore the RO flag for .rsrc?
Yes, Windows has an exception handler too. And actually I would expect our handler to work on builtins too, so probably the first thing to do is to figure out why this isn't the case.