https://bugs.winehq.org/show_bug.cgi?id=49052
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #4 from Anastasius Focht focht@gmx.net --- Hello folks,
from your comments it pretty much looks like standard application virtualization/sandboxing using native API hooking.
Paul already mentioned bug 33236, there are others as well. It could be a combination of multiple issues. Some of these sandboxing schemes rely on the native API call sequence(s) matching Windows loader.
* bug 33236 ("Multiple application virtualization schemes rely on LdrLoadDll to behave like native Windows loader (NtOpenFile, NtXXXSection) (VMWare ThinApp 4.x, BoxedApp)")
* bug 38950 ("Creo Elements/Direct Modeling Express 6.0 .NET based licensing tool crashes on startup (Xenocode VM, 'load_native_dll' must also allow imports resolving for 'EXECUTABLE_IMAGE')")
* bug 23451 ("VMWare Thinapps (packaged with version >4.5) and XenoCode wrapped apps fail to run (differences in process creation sequence at native API level)")
If registry virtualization is involved:
* bug 38956 ("Multiple applications wrapped with Xenocode fail with .NET Framework error (Creo Elements, Neuro-Programmer v2.5)(registry virtualization fails to intercept Wine's root key handles)")
Regards