http://bugs.winehq.org/show_bug.cgi?id=7979
------- Additional Comments From nikolay(a)vladimiroff.com 2007-01-05 03:44 -------
Are you sure you're still using static lighting when you enable fbo? Because
it's the dynamic lighting that's causing the massive slowdown for me. Fbo and
static work fine(i get the same fps with pbuffer).
--
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=8244
Summary: indigo.exe - page fault on write access in 32-bit mode
Product: Wine
Version: 0.9.36.
Platform: PC-x86-64
URL: http://www.indigorenderer.com/
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-msvcrt
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: goawaypleaseus(a)yahoo.com
Hello. I don't know how to do this, cut me some slack if I don't provide the
right stuff or miscategorize.
Indigo is a Windows raytracer, built around Metropolis Light Transport and
bidirectional path tracing. It produces gorgeous output, or that is, it used to.
The developer switched to wxWidgets for the GUI and changed his dev environment,
now apparently dynamically linked to VC71 runtime dlls.
I was running 9.35, figured it might be wine, compiled 9.36, same same.
Stack dump attached.
-BP
--
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=8243
Summary: Feature: Add MsiBreak to aid debugging custom actions
Product: Wine
Version: 0.9.35.
Platform: All
OS/Version: All
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: wine-msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
it seems debugging brain damaged msi installers (hello adobe) became some sort
of daily work :)
There is one incredibly useful "developer" feature missing from wine msi:
"MsiBreak".
Windows msi has this (rather undocumented) feature for some time now to aid
developers to debug custom action dlls/function calls.
Without that you would have to attach to right msi service process (usually the
wrong one), break on "module load" events, set breakpoint on custom action
exports and the like.
Due to constant custom action dll loading/unloading this is a very nasty setup.
That's why the "MsiBreak" feature exists.
Basically it's an environment variable called "MsiBreak" which holds the name of
custom action as value.
If defined and matching the current custom action to be called, msi would ask
the developer to take action.
The developer can attach a debugger to appropriate pid (as displayed in dialog)
and then press "OK".
Msi DebugBreaks() then, allowing the developer to step into custom action code.
If not wanted, one can press "Cancel" ("Cancel" is not in windows version, i
added it as comfort).
The environment variable is read at run time.
Undefining or redefining the current custom action while running the installer
works of course.
I wrote a patch to include this feature to custom msi.
I rarely use winedbg but a custom windows usermode debugger which needs windows
process ids for attach, thats why both process ids are displayed (upid=unix,
wpid=wine/windows).
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=8235
------- Additional Comments From karl(a)qdh.org.uk 2007-01-05 02:47 -------
> What is not happening is users start programs from WM's file browser and guess
> what $PWD is in that case?
Please don't assume I've made a newbe error like this!
I ran the installer as follows;
cd /home/karl
wine D:\\Setup.exe
This failed on the second disc, then I tried
wine /media/cdrom0
Which also failed on the second disc, in both instances my pwd was /home/karl
which is mapped to my h:\ drive in wine.
It seems now I can't even test it however, as somehow a new problem has crept up
on my ubuntu machine where I can't write to the temp folder from the CoD
installer. I've tried;
rm -rf ~/.wine;wineprefixcreate;winecfg -D
Then re-installing, I'm getting a few spurious errors about Nt security contexts
but this must somehow be a problem at my end.
I will re-test this with fedora I think that will be the best way forward, then
I can file a bug with ubuntu for it. Maybe the ubuntu packages weren't built
with hal?
--
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=8219
------- Additional Comments From dank(a)kegel.com 2007-30-04 23:54 -------
Indeed. the problem with disks 2 and 3 has nothing
to do with Wine. You can't even read them from
Linux because the Rock Ridge extensions metadata on the disk
is borked, and sets the permissions so only the mythical
user 400 can read the disk. (At least on my system.)
Using the norock option when mounting the discs works around
this. Sadly, this isn't easy for the average user.
--
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=1074
tony.lambregts(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
------- Additional Comments From tony.lambregts(a)gmail.com 2007-30-04 23:07 -------
Closing
--
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.