http://bugs.winehq.org/show_bug.cgi?id=2594
Summary: fixme:font:WineEngCreateFontInstance Untranslated
charset 255
Product: Wine
Version: 20041201
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-console
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mcolgin(a)gmail.com
Upon executing a Win32 Console mode program (no GUI, just good-ole text
characters, full 32-bit): wine reports the following error:
fixme:font:WineEngCreateFontInstance Untranslated charset 255
The program then continues to run without a problem, however the font used to
render the screen under X uses a small-ish font that I'm unable to determine
it's source. There doesn't appear to be any configuration file that I can find
that allows me to override this font. But given the "fixme" flag on this error,
I'm hoping that it's some kind error that maybe my fellow Win32-Console friends
haven't reported yet.
This test and error was reported using a publicly available shareware text
editor called Semware's TSE Pro, it's available at the below URL for duplication
of the error:
http://semware.com/html/tsepro42new.html
Please let me know if there's anything I can help with in indentifying the problem.
--
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=2593
Summary: Mouse wheel's WM_MOUSEWHEEL requires screen, not client,
coordinates
Product: Wine
Version: 20041201
Platform: HP
URL: http://www.ssontech.com
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-x11driver
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: matchmovie(a)yahoo.com
CC: matchmovie(a)yahoo.com
The WM_MOUSEWHEEL message is specified to have absolute screen coordinates,
unlike the WM_LBUTTONDOWN etc messages, which are client coordinate system.
x11drv/mouse.c and windows/input.c treat them all identically (client). So
WM_MOUSEWHEEL messages are delivered to the correct window (and appear to work),
but have the wrong coordinates, so programs that use the coordinates to
redistibute the MOUSEWHEEL message (ie to override the focus) wind up delivering
the MOUSEWHEEL messages to grossly incorrect windows, so much so that the mouse
scroll is unusable. The SynthEyes program at www.ssontech.com shows this
clearly, you can find multiple images of the overall screen-wide scroll wheel
mapping within each subwindow, because the MOUSEWHEEL coordinates are being sent
in client coordinates, not screen coordinates.
This problem should be fixable with a slight modification to mouse.c::get_coords
to allow the client rectangle mapping to be turned off for WM_MOUSEWHEEL. I'm
not entirely sure what the story is with the two mappings in the routine without
running a debugger on it, or I'd propose a patch. (Sorry, no experience to be
able to do this.)
For future note, I think the mapping to client coordinates for the LBUTTONDOWN
etc messages should actually be in windows\input.c::queue_mouse_event with no
mapping in get_coords. The hardware message between the two is intended to
always pass screen coordinates in screen-normalized coordinates, not to be
normalizing the client-coordinate values as is currently done.
But that's a fine point for now, the key point is to fix this bug so SynthEyes
can be run under Linux... tnx.
--
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=1409
puoti(a)inwind.it changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
------- Additional Comments From puoti(a)inwind.it 2004-03-12 15:48 -------
This bug is fixed by http://bugs.winehq.com/show_bug.cgi?id=991 (Untested, but
all M$ game installers suffered from the same bug so that patch should fix them all.
--
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=1434
Bug 1434 depends on bug 1409, which changed state.
Bug 1409 Summary: Starlancer trial installer doesn't work.
http://bugs.winehq.org/show_bug.cgi?id=1409
What |Old Value |New Value
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
--
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=1408
puoti(a)inwind.it changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From puoti(a)inwind.it 2004-03-12 15:48 -------
This bug is fixed by http://bugs.winehq.com/show_bug.cgi?id=991 (Untested, but
all M$ game installers suffered from the same bug so that patch should fix them all.
--
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=1434
Bug 1434 depends on bug 988, which changed state.
Bug 988 Summary: Age of empires conquerors expantion trial won't install.
http://bugs.winehq.org/show_bug.cgi?id=988
What |Old Value |New Value
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
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=2592
Summary: SetCompositionWindow Errors
Product: Wine
Version: 20041201
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-misc
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dougp25(a)hotmail.com
Trying to run something called nitto.
wine starts it, we get the splash screen, and a login (like we do under
windoze). We are able to see errors spooling past on the console. They
consist of quite a few of:
fixme:imm:ImmGetContext (0x10028): stub
fixme:imm:ImmSetCompositionWindow STUB
The program then ends, and the window it is running in closes, on this error:
err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to
dispatch exception.
I am not sure which error is the worse one, or if one is causing the other!
--
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=2591
btucker(a)mpc-data.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Wine FreeBSD |Wine FreeBSD Stuck in
| |ReadProcessMemory
------- Additional Comments From btucker(a)mpc-data.co.uk 2004-03-12 05:55 -------
Running Freebsd 4.10, Wine 20040505 or 20040408 both patched for FreeBSD and built fron the ports
collection. I find that console mode win32 exes run ok.
Any GUI executables such as notepad.exe (from a XP pro sp2 installation) get stuck in the win32 api call
'kernel32.ReadProcessMemory'. Interestingly, the windows GUI version of vim, called gvim.exe version
62 did not suffer the same problem.
Running XFree86 4.3.0.1.
I have attacked the wine trace and ktrace.
I am supprised that I have found no mention of this problem in the bug lists as it affects all windows
exes (gvim excluded) that I tried (word, excell etc) I am trying to run a propriety windows GUI scripting
system for X platform driver testing. It runs on Linux but FreeBSD has become an unexpected show
stopper.
Any help gratefully received.
Ben.
P.S. Running under linux, our test system loads dlls several times i.e. it does LoadLibrary on the same
dll more than one time. We have found that where the dll in question is a wine wrapper '.dll.so', the first
load library succeeds but subsiquent loads fail. Wine picks up the .dll.so from the linker paths the first
time but that records it's path incorrectly. This problem only ocures when a path the the win .dll is
included in the LoadLibrary call.
--
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.