https://bugs.winehq.org/show_bug.cgi?id=37503
Bug ID: 37503
Summary: Bad reflow in joystick control panel
Product: Wine
Version: 1.7.30
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: programs
Assignee: wine-bugs(a)winehq.org
Reporter: adys.wh(a)gmail.com
Distribution: ---
Created attachment 49892
--> https://bugs.winehq.org/attachment.cgi?id=49892
Screenshot
See attachment. The word "applet" is cut. If I change tab and go back, the word
applet is on a newline as it should be.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26160
Summary: Broken control path in mcicda
Product: Wine
Version: 1.3.13
Platform: x86
OS/Version: Mac OS X 10.5
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winmm&mci
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: hoehle(a)users.sourceforge.net
I'm thankful to C. Robinson for making mcicda work on my Linux machines since
wine-1.1.5. Since then the code supports 2 modes of operation, either via
- IOCTL_CDROM_*_AUDIO (PLAY/STOP/PAUSE/RESUME/SEEK)
- or via a separate thread using DirectSound with
IOCTL_CDROM_RAW_READ. READ_TOC is needed in both modes.
However,
commit 8afa626faa3c5aa2d32d17dca77edaf9efb3a5da
uses as selector
if (wmcda->hThread != 0) {
which causes inconsistent results as the thread may be long dead. I believe
that is not the correct way to select whether to invoke either
thread/DS+RAW_READ commands or IOCTL_CDROM_*_AUDIO ones.
Consider this sequence of MCI commands:
cmd hThread comment
play -- start hThread
stop # !0 => SetEvent stopEvent, hThread becomes 0
stop # =0 => DeviceIoControl
resume # =0 => DeviceioControl
play
resume # !0 => DSB+Play, unlike previously
status mode !0 GetStatus yields PLAY, later STOP
it will never detect that a disk was long ejected!
stop
status mode =0 GetStatus performs IoControl instead
and hence reports current and correct state.
It's fine that the code supports 2 modes of operation, the bug is that the
current code confuses itself as to which branch should be taken and produces
results depending on the history of commands rather than the current state (and
HW capabilities), wrongly mixing both code paths, leading to incorrect results.
IMHO a binary decision via hThread is wrong, there are more states to consider:
- DSB + RAW_READ is useable / being used;
- IOCTL_CDROM_PLAY_AUDIO is useable / being used
- don't know yet.
This issue becomes more important now as MacOS support is getting close (see
bug #20323). This issue becomes more important now as MacOS support is getting
close (see bug #20323). It does not implement the IOCTL_CDROM_*_AUDIO and
spits out unneeded err: and fixme: to the console. I mentioned that I'd about
this issue in bug #20323 comment #4 last year.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20323
Summary: MacOS mcicda does not play audio CD
Product: Wine
Version: 1.1.30
Platform: PC
OS/Version: Mac OS X 10.5
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: kernel32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: hoehle(a)users.sourceforge.net
mcicda invokes GetDriveTypeW which returns 3, the same as for C: and other HD
drives. It expects DRIVE_CDROM(5).
E: is not recognized as CD-ROM by Wine, although it is created by the mountmgr.
It points to /Volumes/Audio-CD. Indeed /Volumes/Audio-CD/ is a directory full
of files named "N Titel NN.aiff", e.g. "2 Titel 02.aiff". e:: points to
/dev/rdisk2
GetDriveTypeW in turn calls:
trace:file:CreateFileW returning 0x68
trace:vxd:DeviceIoControl (0x68,6d4084,0x32f2ac,16,0x32f2ac,16,0x0,0x0)
trace:ntdll:NtDeviceIoControlFile (0x68,0x0,0x0,0x0,0x32f018,0x006d4084,0x3
2f2ac,0x00000010,0x32f2ac,0x00000010)
code=006d4084 (device=6d) is weird, as winioctl.h only lists FILE_DEVICE_* 01
.. 39
I have not looked further into the origin of this code.
Bypassing this test allows mcicda to open cdaudio.
mciSendString: open e: type cdaudio alias y
+ status cdaudio length
+ status cdaudio length 2
+ status cdaudio number of tracks work -- so there's hope -- whereas
- status cdaudio position
- status cdaudio current track
- status cdaudio media present
- seek and
- play fail.
fixme:ntdll:server_ioctl_file Unsupported ioctl 2402c (device=2 access=1 func=b
method=0)
fixme:mcicda:MCICDA_GetError Unknown mode 50
status length etc. show that
DeviceIoControl(wmcda->handle, IOCTL_CDROM_READ_TOC
works.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=35165
Bug ID: 35165
Summary: Quake Live standalone login window shows difficult to
read text in the username field
Product: Wine
Version: 1.7.8
Hardware: x86-64
URL: http://quakelive.com
OS: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: alexandru.balut(a)gmail.com
Classification: Unclassified
Created attachment 46910
--> http://bugs.winehq.org/attachment.cgi?id=46910
Entered "mmmmmmmm" in the two fields
Install the app (installer might crash, but ignore that), start it, notice the
text entered in the username/password fields appears in a weird way.
When pressing backspace to delete the last character, the text suddenly seems
to appear fine but there is an unexpected margin between the right-side of the
text and the cursor. Then if more letters are entered they continue to be
displayed broken.
Does not happen with digits for some reason.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40816
Bug ID: 40816
Summary: Webrotate (FREE) application hangs during installation
Product: Wine
Version: 1.9.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: bob.mt.wya(a)gmail.com
Distribution: ---
Created attachment 54761
--> https://bugs.winehq.org/attachment.cgi?id=54761
WINEDEBUG=+relay,+seh,+tid console output (truncated)
Installation of this application hangs after pressing the INSTALL button. I've
not dug through the trace to see what's going wrong - but it's not immediately
obvious what (Wine) component is at fault.
The last few lines of the console trace repeat ad infinitum (so I've truncated
the attached version):
000d:Call ntdll.RtlAllocateHeap(00110000,00000000,00000014) ret=7efeb721
000d:Ret ntdll.RtlAllocateHeap() retval=00179098 ret=7efeb721
000d:Call ntdll.RtlAllocateHeap(00110000,00000000,00000016) ret=7efeb44b
000d:Ret ntdll.RtlAllocateHeap() retval=001790b8 ret=7efeb44b
000d:Call ntdll.RtlAllocateHeap(00110000,00000000,00000006) ret=7efeb44b
000d:Ret ntdll.RtlAllocateHeap() retval=001790d8 ret=7efeb44b
000d:Call ntdll.RtlAllocateHeap(00110000,00000000,00000006) ret=7efeb44b
000d:Ret ntdll.RtlAllocateHeap() retval=001790f0 ret=7efeb44b
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40787
Bug ID: 40787
Summary: POILoader quits right after start
Product: Wine
Version: 1.9.12
Hardware: x86
URL: http://www.garmin.com/us/maps/poiloader
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ladislav.laska(a)gmail.com
Distribution: ArchLinux
The Garmin POI Loader quits after start, without an error message. This might
be related to bug #22544, but it's an old bug, and I'm not really sure if it's
regression. I've tried testing this with the 1.7.11 as suggested, but the
result is the same.
Installer works (and required mono). Whenever I start the application, I get a
few messages on terminal, the POI Loader initial screen shows up for a few
seconds, but is non-responsive, and crashes promptly, without further error:
krakonos@wallaby ~/[...]/POI Loader $ wine POILoader
fixme:dbghelp:elf_search_auxv can't find symbol in module
fixme:dbghelp:elf_search_auxv can't find symbol in module
fixme:dbghelp:elf_search_auxv can't find symbol in module
krakonos@wallaby ~/[...]/POI Loader $ wine --version
wine-1.9.12
The wine I'm using is a version from Arch repository.
I'd be glad to provide more information, but I have no idea where to look for
problems.
Download is available here: http://www.garmin.com/us/maps/poiloader
Tested with POI Loader 2.7.3 (the latest available)
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=34928
Bug #: 34928
Summary: X Rebirth only (re)draws HUD Elements
Product: Wine
Version: 1.7.6
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: skython(a)web.de
Classification: Unclassified
Created attachment 46545
--> http://bugs.winehq.org/attachment.cgi?id=46545
Screenshot 1: Rendering bugs after starting a new free game.
The game doesn't renders everything except the HUD. When you start a new free
game the screen becomes black and only the HUD elements are visible.
If any of the HUD elements is moving, you see them being 'copied' over the
black background. The attached screenshots are showing this behaviour.
If you alter some graphics settings (for example antialiasing) while ingame,
you can see the game rendering everything just fine for a single frame. But
then again the rendered scene doesn't redraw and HUD is being copied again. You
can see this behaviour on the second screenshot.
The terminal repeatedly says:
err:d3d:wined3d_debug_callback 0x193ef0: "GL_INVALID_OPERATION error generated.
Buffer is mapped.".
err:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502)
from glDrawElementsBaseVertex @ ../../../wine/dlls/wined3d/drawprim.c / 64
I'm using Archlinux and the current Wine version 1.7.6
I already tried altering several rendering settings using winetricks. No luck
so far. Any help is appreciated
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=40725
Bug ID: 40725
Summary: 8-bit Armies crashes on start (32-bit prefix, Windows
7 mode)
Product: Wine
Version: 1.9.11
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fjfrackiewicz(a)gmail.com
Distribution: ---
Created attachment 54631
--> https://bugs.winehq.org/attachment.cgi?id=54631
Terminal output for Wine 1.9.11 Staging no CSMT
I am attempting to run this game in a clean 32-bit prefix and it crashes while
loading.
Running the command "wine ClientG.exe" gets me a splash screen and opens up a
very tiny square which I assume is the game's window. After a few seconds the
game then crashes.
I have checked that ClientG.exe, the game's executable, is in fact a 32-bit
file:
file ClientG.exe
ClientG.exe: PE32 executable (GUI) Intel 80386, for MS Windows
I am attempting to run the game in Windows 7 mode as it does not support
Windows XP.
I have attached the terminal output as the game loads then crashes. I am using
Wine 1.9.11 Staging.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32495
Bug #: 32495
Summary: Incorrect behavior in ScriptGetLogicalWidths() /
ScriptApplyLogicalWidth() (buffer overrun)
Product: Wine
Version: 1.5.19
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: usp10
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: disposable593-wine(a)yahoo.com
Classification: Unclassified
Currently, ScriptGetLogicalWidths() and ScriptApplyLogicalWidth() are
incorrectly implemented, leading to wrong glyph positioning in one of my
applications.
**ScriptGetLogicalWidths(): The current implementation simply copies the input
to the output array, incorrectly assuming nbchar==nbglyphs. If there are fewer
glyphs than characters, this causes a buffer overrun, potentially leading to
application crashes. (The problem does and will become more prevalent as the
implementation of shaping is improved over time.)
**ScriptApplyLogicalWidths(): The functions fails to apply justification and
simply returns the unjustified widths.
Below I include what I believe are correct implementations. I have taken care
that the results agree with those returned by the Microsoft implementations. (I
have never seen or been in contact with the original Microsoft code, though, so
the following code is "clean" and may be used for any purpose.)
HRESULT WINAPI ScriptGetLogicalWidths(const SCRIPT_ANALYSIS *sa, int nbchars,
int nbglyphs,
const int *glyph_width, const WORD
*log_clust,
const SCRIPT_VISATTR *sva, int *widths)
{
int rtl, i;
// TRACE("(%p, %d, %d, %p, %p, %p, %p)\n",
// sa, nbchars, nbglyphs, glyph_width, log_clust, sva, widths);
rtl = sa->fRTL && !sa->fLogicalOrder;
for (i = 0; i < nbchars; )
{
int w = 0, i2, j, j2;
j = log_clust[i];
i2 = i;
do i2++; while (i2 < nbchars && log_clust[i2] == j);
j2 = i2 < nbchars ? log_clust[i2] : rtl? -1 : nbglyphs;
for ( ; j != j2; rtl? j--:j++)
w += glyph_width[j];
for ( ; i < i2; i++)
w -= widths[i] = w / (i2-i);
}
return S_OK;
}
HRESULT WINAPI ScriptApplyLogicalWidth(const int *dx, int num_chars, int
num_glyphs,
const WORD *log_clust, const
SCRIPT_VISATTR *sva,
const int *advance, const
SCRIPT_ANALYSIS *sa,
ABC *abc, int *justify)
{
int rtl, i;
// FIXME("(%p, %d, %d, %p, %p, %p, %p, %p, %p)\n",
// dx, num_chars, num_glyphs, log_clust, sva, advance, sa, abc,
justify);
rtl = sa->fRTL && !sa->fLogicalOrder;
if (abc) abc->abcB = - abc->abcA - abc->abcC;
for (i = 0; i < num_chars; )
{
int w = 0, j, j1, j2;
j1 = log_clust[i];
do w += dx[i++]; while (i < num_chars && log_clust[i] == j1);
j2 = i < num_chars ? log_clust[i] : rtl? -1 : num_glyphs;
for (j = j1; j != j2; rtl? j--:j++)
w -= advance[j];
for (j = j1; j != j2; rtl? j--:j++)
{
w -= justify[j] = w / (rtl? j-j2:j2-j);
justify[j] += advance[j];
if (abc) abc->abcB += justify[j];
}
}
return S_OK;
}
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19452
Summary: QuickVerse 2009 crashes when attempting to open a book
Product: Wine
Version: 1.1.26
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: firesword14(a)yahoo.com
Created an attachment (id=22597)
--> (http://bugs.winehq.org/attachment.cgi?id=22597)
Log of what happened, then dump
Wine crashes when I double click on a bible or book to open.
This is my first bug report, if need more information, please ask.
First issue in log: shdocvw:PersistStreamInit_InitNew
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.