http://bugs.winehq.org/show_bug.cgi?id=5294
------- Additional Comments From dmitry(a)codeweavers.com 2007-15-05 10:00 -------
> Due to the way wine implements the LOAD_LIBRARY_AS_DATAFILE flag, it fails.
> The dll is mapped as "data file" into memory (receives its own base address).
...
> To work around this problem, LOAD_LIBRARY_AS_DATAFILE shall not use
> load_library_as_datafile() (CreateFileMappingW/MapViewOfFile).
But Windows really just maps the file without performing any initialization
steps for LOAD_LIBRARY_AS_DATAFILE. There should be something else that causes
a problem. Is the dll already loaded at that point? Perhaps in that case
LoadLibrary(LOAD_LIBRARY_AS_DATAFILE) supposed to behave differently?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5006
------- Additional Comments From rikardo.tinauer(a)eba.si 2007-15-05 09:47 -------
I tried this with all subsequent wine releases and it did not work, I also tried
win98 configuration, it installed but did not work.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8392
------- Additional Comments From paolo_red(a)yahoo.com 2007-15-05 07:48 -------
Trial version installed, same problem.
Tried with and without overriding oleacc.dll . Same configuration as posted above.
Please note: for using the "console" feature in the administrative client you
need a domino server running to connect (and administrative privileges).
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5294
------- Additional Comments From focht(a)gmx.net 2007-15-05 07:46 -------
Hello,
another interesting pick (i downloaded 5.4.x) :-)
--- quote ---
Does that mean the application is copyprotected?
--- quote ---
Yes, a late ASProtect 2.x SKE version (http://www.aspack.com/asprotect.html).
The minor problem first: You have to use native msxml3 (winetricks), or it will
crash due to unsupported features.
The major problem is the exe protector itself.
It's a pain to debug this in wine due to the way the PEB->BeingDebugged flag is
managed in places critical to debuggers.
Although one of the simple ones (out of several anti debugging checks) it proves
to be annoying in wine environment.
If you simply reset the field (memory) to fool the protector the whole debugging
facility will break.
So patching some sources is the only way to get around (top level SEH and debug
events despite !BeingDebugged).
Ok i stop the little rant :-)
The application consists of two major components which are both protected by
AsProtect: morpheus.exe and M5Shell.dll
The dll proved to be problematic. An inproc ole server.
When i first rebuilt and run the main executable it crashed due to some class
interfaces not registered, probably belonging to M5Shell.dll.
Manually running "regsvr32 M5Shell.dll" failed (this self-register step failed
in setup too - silently)
When the dll is loaded and the initialization routines are run, the protector
decrypts several PE sections in memory.
One of them is the .rsrc section.
When the regsvr32 process calls DllRegisterServer, it tries to register its
interfaces by gathering data from .rsrc section (REGISTRY resource types).
This is done by explicit LoadLibraryEx with LOAD_LIBRARY_AS_DATAFILE flag set
and appropriate Find/LoadResource API.
Due to the way wine implements the LOAD_LIBRARY_AS_DATAFILE flag, it fails.
The dll is mapped as "data file" into memory (receives its own base address).
At that point all crucial PE sections are encrypted.
Remember: only when dll initializers are run, either by explicit entry or TLS
callbacks they get properly decrypted.
When Find/LoadResource is applied to the newly loaded dll it finds useless stuff
(of course the data is encrypted).
It dies then.
Offending code:
--- snip dlls/kernel32/module.c ---
static HMODULE load_library( const UNICODE_STRING *libname, DWORD flags )
{
NTSTATUS nts;
HMODULE hModule;
WCHAR *load_path;
if (flags & LOAD_LIBRARY_AS_DATAFILE)
{
/* The method in load_library_as_datafile allows searching for the
* 'native' libraries only
*/
if (load_library_as_datafile( libname->Buffer, &hModule )) return hModule;
flags |= DONT_RESOLVE_DLL_REFERENCES; /* Just in case */
/* Fallback to normal behaviour */
}
load_path = MODULE_get_dll_load_path( flags & LOAD_WITH_ALTERED_SEARCH_PATH
? libname->Buffer : NULL );
nts = LdrLoadDll( load_path, flags, libname, &hModule );
HeapFree( GetProcessHeap(), 0, load_path );
if (nts != STATUS_SUCCESS)
{
hModule = 0;
SetLastError( RtlNtStatusToDosError( nts ) );
}
return hModule;
}
--- snip dlls/kernel32/module.c ---
To work around this problem, LOAD_LIBRARY_AS_DATAFILE shall not use
load_library_as_datafile() (CreateFileMappingW/MapViewOfFile).
A quick fix is to comment out "if (load_library_as_datafile( libname->Buffer,
&hModule )) return hModule;" to fall back to standard loader mechanism (of
course imports are already resolved and init routines are run).
That way the application/protector can find its resources and succeed.
With that patch applied, morpheus starts up fine.
There are many applications in the wild which use ASPack/ASProtect and other
protectors which encrypt resource/data sections.
So this information probably applies to other bug reports too.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8401
vitaliy(a)kievinfo.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|wine-ole |wine-misc
------- Additional Comments From vitaliy(a)kievinfo.com 2007-15-05 07:40 -------
Upgrade to latest Wine - 0.9.37.
What version of Visio?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7980
------- Additional Comments From lambdae2(a)gmail.com 2007-15-05 06:28 -------
What video card are you using? I saw this bug on some winXP computers
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8400
------- Additional Comments From xerox_xerox2000(a)yahoo.co.uk 2007-15-05 05:41 -------
and please upgrade to wine-0.9.37 first.
this is a known regression in wine-0.9.36
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8401
Summary: Crash when press New button in MS Visio
Product: Wine
Version: 0.9.33.
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-ole
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ogldelphi(a)mail.ru
Crash when press New button in MS Visio Something wrong with OLE
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.