http://bugs.winehq.org/show_bug.cgi?id=7698
------- Additional Comments From stfan4cjk(a)gmail.com 2007-26-04 22:48 -------
Where is this? dlls/gdi32/freetype.c
--
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.
You are on the CC list for the bug, or are watching someone who is.
http://bugs.winehq.org/show_bug.cgi?id=8033
------- Additional Comments From goodfella005(a)gmail.com 2007-26-04 22:36 -------
Adding the two lines of code you suggested fixed the problem thanks.
--
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=6297
------- Additional Comments From jordanstudios2934(a)gmail.com 2007-26-04 21:30 -------
I've had this bug happen to me in wine 9.35. wineboot didin't fix it for me.
Deleting the ClientRegistry.blob file fixed the problem, but required
re-typing in my password to log in.
The problem is also always fixed if I reboot my computer.
--
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=8187
------- Additional Comments From focht(a)gmx.net 2007-26-04 21:24 -------
Hello,
if you install vc2005 runtime, make sure the CRT library NEVER gets loaded from
System32 directory.
It will check for this and terminate if so (the messagebox you see).
All other directories which are seen by loader are permitted (usually app
directory or winsxs).
Place the new CRT libraries along with manifest files there (as by download link
in bug 7409).
In this case msvcr80.dll and Microsoft.VC80.CRT.manifest are required.
Make sure the manifest (Microsoft.VC80.CRT.manifest) is either in directory
where the CRT dll resides or in c:\windows\winsxs.
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=7644
jordanstudios2934(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #5959 is|0 |1
obsolete| |
------- Additional Comments From jordanstudios2934(a)gmail.com 2007-26-04 21:02 -------
(From update of attachment 5959)
opps, uploaded the wrong image from my desktop.
--
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=7644
------- Additional Comments From jordanstudios2934(a)gmail.com 2007-26-04 21:01 -------
Created an attachment (id=5959)
--> (http://bugs.winehq.org/attachment.cgi?id=5959&action=view)
Another image of the bug
I've tried HL2 under wine 9.35 The bug is still persisting for me.
Symptoms under wine 9.35:
* Objects are unusually bright unless they are being acted upon or the user is
shinning their flashlight at it.
* For some reason, the flashlight doesn't work on the floors and walls.
* A few objects do appear correctly, and the flashlight will act correctly on
them too.
--
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=8187
dank(a)kegel.com changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |http://quicken.intuit.com/fr
| |ee-trial-download.jhtml
Keywords| |download
------- Additional Comments From dank(a)kegel.com 2007-26-04 19:44 -------
Vitaliy, if you want to close the bug because it has a log pasted
in it, please give the user clear, polite directions.
But the right way to deal with this is probably to modify
bugzilla to automatically reject such submissions.
Maybe you should file a bug for that?
Ron, can you reproduce your bug with the downloadable trial version at
http://quicken.intuit.com/free-trial-download.jhtml ? That would really
help.
It's possible the DLLs you downloaded gave Wine indigestion.
When I tried this with the downloadable demo, I installed the
missing DLLs like this:
wget http://kegel.com/wine/winetricks
sh winetricks gdiplus vcrun2005
This downloads known good copies from Microsoft.com.
But the result I got was quite different: the app terminated
with a dialog box
"Runtime Error!
Program: C:\Program Files\Quicken\qw.exe
R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information."
This is not unexpected. Wine doesn't quite support applications
built with msvc2005 yet. I think what I saw is another example
of bug 7409.
Could you try again after renaming your .wine directory and
using winetricks as described above instead of downloading
the DLLs from wherever you got them? If you still have a problem
that's different that what I described above, file a new bug
(and this time attach the log, don't paste it inline).
--
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=7679
------- Additional Comments From focht(a)gmx.net 2007-26-04 19:16 -------
Hello,
i read some discussion on developer list regarding this one ... so it catched my
interest :)
Fired up my debugger and let go (+few cups of coffee).
In short: it's an interesting (subtile) bug in wine trigged by unusual PE
section protection flags :)
First, the root cause is a c++ exception generated by precompiled boost::python
module which should not hurt at all.
When being passed to upper exception handler chains it finally arrives at a
point where the application tries to make sense of it.
That task is accomplished by a hooking library which exports several APIs to
gather process/module information, hook either by patching the import address
tables of all modules (1st level hooker) and/or to patch entrypoints of system
functions itself (2nd level hooker, trampolines).
The hooker enumerates all modules and their import tables.
It modifies the page protection attributes to get write access to the IAT of
each module.
This is done by a series of VirtualQuery/VirtualProtect.
To answer the question "lots of access violations being seen in debugger":
completely harmless and expected.
The code checks if page write access has already been enabled to system
functions code area by using IsBadWritePtr (2nd level hooking/trampoline).
Checks for trampolines code (e.g. insertion of jmp/call opcodes on entry) are
made too.
Well, back to topic.
One module "Blowfish.pyd" has a rather unusal protection attributes combination
to its .idata (imports) section: C0000040 -> readable | writable | initialized data.
Usually it should be: readable | initialized data .. i'm pretty sure it was on
accident by developers.
This triggers the interesting wine bug.
With the module being mapped by wine loader, the page gets PAGE_WRITECOPY attribute.
At one place, the hooker basically does following:
if( VirtualQuery( IAT_addr_of_module, &info, sizeof(info)) == sizeof(info))
{
DWORD prot = info.AllocationProtect & (PAGE_NOACCESS | PAGE_READWRITE |
PAGE_WRITECOPY | PAGE_EXECUTE | PAGE_EXECUTE_READWRITE | PAGE_EXECUTE_WRITECOPY);
prot |= PAGE_READWRITE;
if( VirtualProtect( IAT_addr_of_module, ... , prot, &oldProtect))
{
// access the IAT
}
}
Now the problem: VirtualQuery() -> info.AllocationProtect -> returns 0x8 =
PAGE_WRITECOPY for this specific module.
That gets masked and or'd PAGE_READWRITE: 0xC -> PAGE_WRITECOPY | PAGE_READWRITE
and the passed to VirtualProtect().
Guess. VirtualProtect() returns TRUE and the hooker tries to access IAT area.
*boom*
Now you have literally a "double fault" - the module which should gather
exception information produced exception by itself :)
You may ask where is the wine bug?
Well, wine should never have returned TRUE on VirtualProtect with PAGE_READWRITE
and PAGE_WRITECOPY flags both set.
This is a very little known (undocumented) limitation starting with Windows 2000
and higher.
I had this issue some years ago - that's why I remembered this one.
The mode attribues PAGE_READWRITE and PAGE_WRITECOPY are mutually exclusive.
You can test it by yourself on windows systems (Win2k, WinXp), VirtualProtect
will fail if both set.
For verification that my findings are correct you have to options:
- change the section protection of "Blowfish.pyd" .idata section to 0x40000040
(read | initialized data).
VirtualProtect will succeed and the app finally starts up with login screen.
- fix wine itself: VirtualProtect( PAGE_READWRITE | PAGE_WRITECOPY) on Win2K+
must return FALSE. PAGE_WRITECOPY is not supported by Win9X. Though I couldnt
verify NT4. I'd say: prohibit this combination at all.
Actually these are the bugs i like (along with stack smashers). I had some fun :)
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.