http://bugs.winehq.org/show_bug.cgi?id=2961
marcus(a)jet.franken.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
------- Additional Comments From marcus(a)jet.franken.de 2005-14-05 06:20 -------
did you run "make distclean" before "cvs up" ?
probably not.
to fix this onetime problem (due to changed import handling) do:
cd dlls
rm *.def
cd ..
make
--
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=2961
Summary: Compile failure: dlls/dinput/tests/Makefile missing an
object
Product: Wine
Version: CVS
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: test
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: inverseparadox(a)comcast.net
(I hope I'm interpreting the component classifications correctly...)
As of a couple of days ago, in an up-to-date CVS tree, if I run
make distclean; ./configure; make depend; make
the build will fail in dlls/dinput/tests/ trying to create dinput_test.exe.so.
The error is that joystick.o contains undefined references to c_dfDIJoystick,
which is defined (only) in dlls/dinput/data_formats.c. The problem is that the
build line in the Makefile does not reference the needed object; adding
../data_formats.o
to the winebuild command line fixes the problem.
I'm not entirely sure how this has gone unnoticed so far, since the problem
sometimes also occurs when compiling after a simple cvs update without first
running make distclean; it's possible that the failure is something wrong with
my system, but if so I'd certainly like to know what.
--
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=11
felix.nawothnig(a)t-online.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #877 is|0 |1
obsolete| |
------- Additional Comments From felix.nawothnig(a)t-online.de 2005-14-05 05:32 -------
Created an attachment (id=878)
--> (http://bugs.winehq.org/attachment.cgi?id=878&action=view)
screenshot of unmodified endjoin.exe
(eh, did I write "native screenshot" before? I should get some sleep. It was a
wine screenshot ofcourse)
Some testing revealed that Windows does indeed convert the coordinates to DP on
LineTo() etc. so we have to do the conversion in StrokePath() - I submitted a
patch which adjusts the pen width (rather than doing a DP->LP->DP conversion on
the points) @ http://www.winehq.org/hypermail/wine-patches/2005/05/0279.html
With those 2 patches applied endjoin.exe looks quite like native now.
(screenshot attached & old one obsoleted)
--
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=11
------- Additional Comments From felix.nawothnig(a)t-online.de 2005-14-05 03:55 -------
Investigated it a bit:
When StrokePath() is called MWT_IDENTITY is set since the coordinates passed to
PolyLine() in StrokePath() (or LineTo(), etc. before - it was already broken
before my patch) are already device coordinates, converted by PATH_LineTo(),
PATH_MoveTo(), etc. since they all call LPtoDP(), but the pen width isn't ofcourse.
A quick fix is to remove all the mapping mode changes in PATH_StrokePath() and add
DPtoLP(dc->hSelf, pPath->pPoints, pPath->numEntriesUsed);
before the loop - I think that's rather hackish since I wonder if the
coordinates in pPath->pPoints should be DP anyway...
--
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=11
------- Additional Comments From felix.nawothnig(a)t-online.de 2005-14-05 03:28 -------
And since removing the (Begin|End|Stroke)Path fixes the pen width my speculation
could be very right. ;)
--
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=11
------- Additional Comments From felix.nawothnig(a)t-online.de 2005-14-05 03:21 -------
Created an attachment (id=877)
--> (http://bugs.winehq.org/attachment.cgi?id=877&action=view)
native screenshot
> * the lines are pretty thin yet they are supposed to be pretty thick
> * it looks like there is a mixup between PS_JOIN_BEVEL (the middle one) and
> PS_JOIN_MITER (the rightmost one). But it's tricky to say because the lines
> are so thin.
Nope, they are just fine. I attached a native screenshot with increased
pensize.
> (speculation: the SetWindowExtEx() was not taken into account for
> the pen thickness)
Another speculation: The mapping mode changes in PATH_StrokePath() might be the
cause...
--
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=11
------- Additional Comments From fgouget(a)codeweavers.com 2005-14-05 02:48 -------
> The URL is no longer valid (404)
That's because I converted the screenshot to a PNG 3 years ago:
> ------- Additional Comment #5 From François Gouget 2002-03-28 20:40 -------
> Here are the correct links:
> * http://fgouget.free.fr/wine/PrgWin95/Chap4.shtml#endjoin
> * http://fgouget.free.fr/wine/PrgWin95/endjoin-win95.png
But the links to Microsoft's page are pretty cool.
The results do seem much more correct. I didn't get time to investigate but
there are two things bothering me:
* the lines are pretty thin yet they are supposed to be pretty thick
* it looks like there is a mixup between PS_JOIN_BEVEL (the middle one) and
PS_JOIN_MITER (the rightmost one). But it's tricky to say because the lines are
so thin. (speculation: the SetWindowExtEx() was not taken into account for the
pen thickness)
--
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=2960
Summary: Bug in int 21, function 3f (read) causing WATCOM Win386
Read error
Product: Wine
Version: unspecified
Platform: All
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-dos
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: lupien(a)physique.usherbrooke.ca
An old windows 3.1 program (compiled with a watcom compiler) was failing with
the message Read Error in a window called WATCOM Win386. I found the problem was
due to count being set to 0 in int21, function 3f. In my case the
GetSelectorLimit16 was set at 0xffff (DX was set 0) and would make maxcount 0.
Below is a simple fix (making maxcount a double).
in dlls/winedos
--- int21.c.orig 2005-05-13 21:21:32.000000000 -0400
+++ int21.c 2005-05-13 21:24:36.000000000 -0400
@@ -4744,7 +4744,7 @@
/* Some programs pass a count larger than the allocated buffer */
if (DOSVM_IsWin16())
{
- WORD maxcount = GetSelectorLimit16( context->SegDs )
+ DWORD maxcount = GetSelectorLimit16( context->SegDs )
- DX_reg(context) + 1;
if (count > maxcount)
count = maxcount;
--
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.