http://bugs.winehq.org/show_bug.cgi?id=2197
tony_lambregts(a)telusplanet.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |NoAppDBEntry
------- Additional Comments From tony_lambregts(a)telusplanet.net 2004-06-05 10:50 -------
Would you please create an attachment containing the program?
--
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=1374
------- Additional Comments From david_costanzo(a)yahoo.com 2004-06-05 00:51 -------
Created an attachment (id=588)
--> (http://bugs.winehq.org/attachment.cgi?id=588&action=view)
Lionel's patch, updated for current state of CVS
I think I found the emails:
Description of the problem:
http://www.winehq.org/hypermail/wine-devel/2002/05/0494.html
Proposed (hacky) Solution:
http://www.winehq.org/hypermail/wine-devel/2002/08/0048.html
I have attached a patch that should be equivalent to Lionel's original patch,
but that can be applied to the current source.
The patch has no discernable effect in Hammer's default mode of operation,
which is to show maps in a window with a horizontal and a vertical splitter,
with each of the four views (top,front,side,camera) having its own quadrant.
However, this patch *does* fix the problem when Hammer's is run in its
alternate mode of operation, where each of the four views have their own window
(Tools->Options->General and check "use independent window configuration"). In
this mode, I find it convenient to simulate the splitter window by organizing
the four separate windows with Windows->Tile.
Lionel, in the mail that you sent to wine-dev, you wrote:
> Anyway, all this comes from the fact that the programmers were
> lazy and did not add the 'DCX_CLIPSIBLINGS' flag to their GetDCEx
> call (I know it's not needed because the clipping is done by OpenGL
> in the viewport call).
Are the "lazy programmers" the Hammer programmers? Would it be that simple to
fix Hammer, assuming we had the source code? If you're confident that this
would fix the problem, we can try to convince someone at Valve to set the flag.
They seem like a Linux-friendly company.
--
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=2205
tony_lambregts(a)telusplanet.net changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |http://appdb.winehq.org/appv
| |iew.php?appId=995
--
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=2194
tony_lambregts(a)telusplanet.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |NoAppDBEntry
--
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=717
------- Additional Comments From Speeddymon(a)yahoo.com 2004-05-05 20:51 -------
Well it may be a lil while before I can help with debugging the real problem,
because as I said before I still dont have a computer, just using a public
access one. But if you know a little bit about BASH scripting, I can help you
write up a workaround..
I think that all that needs to be done is have wineshelllink check to see if
the link target exists. If it does then create the link as before, but if not,
then create the link using the dummy icon (which would be installed to
C:\Windows\System (or C:\WinNT\System32) when wine is installed)
Of course some nice but not necessary additions to this would be to have an
initscript check (upon bootup) to see if the files needed to create a proper
link exist, and if so then call wineshelllink to do so. Another thing it could
do is to remove links when someone hasnt properly uninstalled a program and the
targets _no longer_ exist (but did before). And of course if the link is
already proper then do nothing... This is of course not necessary as I said
before but would be something nice..
If anyone has any other ideas post em here and as soon as I get a computer Ill
get to writing them up..
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
http://bugs.winehq.org/show_bug.cgi?id=717
pauling(a)starwolf.biz changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pauling(a)starwolf.biz
------- Additional Comments From pauling(a)starwolf.biz 2004-05-05 19:47 -------
See Comment 20;
I'm running wine 20040408, and this is still a problem, complete error message
reads:
Error: Unable to create a link to C:\Program Files\Starcraft\Readme.hl as
C:\WINDOWS\Start Menu\Programs\Starcraft\Starcraft Readme.lnk.
Installation Aborted
Error 0: Success
at: LinkUndo.cpp Line 165
I've tried touching the file that it's having trouble creating, to no effect,
and this has happened now reliably for 20 install cycles. Other .lnk files it
appears to be able to create without problems.
Any assistance in suggesting WINEDEBUG environment variables that might help
isolate this would be appreciated
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
http://bugs.winehq.org/show_bug.cgi?id=2209
Summary: Cannot print from Red Hat Enterprise Linux 3
Product: Wine
Version: CVS
Platform: PC
OS/Version: Linux
Status: NEW
Severity: critical
Priority: P2
Component: wine-misc
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: medbi01(a)accpac.com
When printing from ACCPAC Advantage Series for Linux (and I expect from a test
program too) I get the error:
lpr: unable to print file: server-error-service-unavailable
This occurs just after CloseJob16 closes its fd to the printing fork.
If I modify wine to print via a temp file I get the same error, even though I
can print the temp file manually from the command line.
--
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=2194
irshadkunda(a)yahoo.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P4 |P1
--
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.