https://bugs.winehq.org/show_bug.cgi?id=7585
--- Comment #69 from joaopa <jeremielapuree(a)yahoo.fr> ---
For me the bug still occurs with wine-4.20 (intel integrated graphic card)
--
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=48017
Bug ID: 48017
Summary: winlink express:Call to unimplemented function
httpapi.dll.HttpReceiveRequestEntityBody, aborting
Product: Wine
Version: 4.18
Hardware: x86
URL: https://downloads.winlink.org/User%20Programs/Winlink_
Express_install_1-5-25-0.zip
OS: Linux
Status: UNCONFIRMED
Keywords: download
Severity: normal
Priority: P2
Component: httpapi
Assignee: wine-bugs(a)winehq.org
Reporter: xerox.xerox2000x(a)gmail.com
Distribution: ---
This was reported by user on forum,
I`m waiting for exact instructions how to reproduce this; for now i open
bugreport to point him to
https://downloads.winlink.org/User%20Programs/Winlink_Express_install_1-5-2…
--
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=47954
Bug ID: 47954
Summary: Bug in unicode path handling
Product: Wine
Version: 4.17
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: kernelbase
Assignee: wine-bugs(a)winehq.org
Reporter: rpisl(a)seznam.cz
Distribution: ---
Created attachment 65459
--> https://bugs.winehq.org/attachment.cgi?id=65459
Installer log
After working around bug https://bugs.winehq.org/show_bug.cgi?id=47626 the
installer fails while installing VisualStudio.TextMateGrammars due to a bug in
unicode file name handling.
The file is "File(Glob …).tmSnippet"
I can create the file manually or even from Far running in wine. But the
installer fails.
Tested on wine-staging 4.17-git
--
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=34723
Bug #: 34723
Summary: Resident Evil 3: changing settings during the game
results in a crash
Product: Wine
Version: 1.7.4
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: winebugs140(a)gmail.com
Classification: Unclassified
Created attachment 46297
--> http://bugs.winehq.org/attachment.cgi?id=46297
RE3 log+error
If you press F5 during the game to change some settings and then you confirm or
cancel your choice, the program crashes.
The problem can be reproduced in the demo (check out the link).
Tested with:
Windows Vista (without Wine), GeForce 9600M GS--the program works fine here
Ubuntu 13.04, GeForce 9600M GS (NVIDIA driver 313)
Mac OS X 10.7.5, ATI HD 2600 Pro, Mac Driver/X11
--
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=35925
Bug ID: 35925
Summary: fbo bailing out on context_set_gl_context
Product: Wine
Version: 1.7.1
Hardware: x86-64
URL: http://appdb.winehq.org/objectManager.php?sClass=versi
on&iId=30117
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: royceremer(a)gmail.com
This has the exact same symptom as bugid#24067, which uses the same engine, but
I do not believe this is a regression. I believe bugid#26802 may be a
duplicate, although it's triggered by a different engine, and there isn't
enough detail in that bug for me to be certain.
Using orm=fbo, all model textures are invisible in Age of Wonders 3. Objects in
the screenshots attached are only visible due to ambient occlusion and
reflective effects on the surfaces.
Using orm=backbuffer makes models appear solid, but loses many effects and is
slow. (picture attached)
Basically, no matter what winetricks or wine version I use, this engine will
bail out here:
https://github.com/mirrors/wine/blob/master/dlls/wined3d/context.c#L769
... for completeness, I have duplicated the bug under the following additional
conditions with a fresh wine prefix for each trial:
---wine1.7.1---
- d3dx9_43, d3dcompiler_43
- d3dx9_43, d3dcompiler_43, WINEARCH=win32
- d3dx9_43, d3dcompiler_43, WINEARCH=win32, force_s3tc_enable=true
- d3dx9_43, d3dcompiler_43, WINEARCH=win32, force_s3tc_enable=true,
glsl=disabled
- d3dx11_43, d3dcompiler_43
- d3dx11_43, d3dcompiler_43, glsl=disabled
- d3dx11_43, d3dcompiler_43, force_s3tc_enable=true
- d3dx11_43, d3dcompiler_43, gdiplus, ddr=gdi
- d3dx11_43, d3dcompiler_43, multisampling=disabled
- d3dx11_43, d3dcompiler_43, multisampling=enabled
- d3dx11_43, d3dcompiler_43, psm=disabled
- d3dx11_43, d3dcompiler_43, psm=enabled
- d3dx11_43, d3dcompiler_43, rtlm=disabled
- d3dx11_43, d3dcompiler_43, rtlm=readdraw
- d3dx11_43, d3dcompiler_43, strictdrawordering=enabled
- d3dx11_43, d3dcompiler_43, videomemorysize=2048, vsm=hardware
- d3dx11_43, d3dcompiler_43, vsm=hardware, psm=enabled
- d3dx11_43, d3dcompiler_43, vsm=hardware
- d3dx11_43, d3dcompiler_43, ao=enabled
---wine1.6.1---
- d3dx11_43, d3dcompiler_43
- d3dx9_43, d3dcompiler_43
- d3dx9_43, d3dcompiler_43, WINEARCH=win32
- d3dx9_43, d3dcompiler_43, WINEARCH=win32, glsl=disabled
- d3dx9_43, d3dcompiler_43, glsl=disabled
- d3dx9_43, d3dcompiler_43, force_s3tc_enable=true
- d3dx9_43, d3dcompiler_43, gdiplus, ddr=gdi
---wine1.4.1---
- d3dx9_43, d3dcompiler_43 <--- this configuration didn't launch at all for
different reasons
Setting `MESA_DEBUG=1 force_s3tc_enable=true` did not log any additional
messages, even after upgrading to
libtxc-dxtn-dev_1.0.1-0.3ubuntu0sarvatt+quantal from ppa:xorg-edgers... so
maybe that does what I think it does?
Logs will be attached in gzip format since they have
`WINEDEBUG=warn+all,trace+d3d,relay+d3d` and are over a gig (<100MB under gzip
-9 though).
Additional info about my system:
- libtxc-dxtn-s2tc0_0~git20110809-3
- xserver-xorg_1:7.7+1ubuntu4
- attached glxinfo for my Nvidia 550 TI (vbios 70.26.3a.00.52)
- ubuntu 12.10 quantal, x86_64
--
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=19667
Summary: Demo for Total Annihilation: mouse scrolling of screen
unworkable.
Product: Wine
Version: 1.1.27
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: hughperkins(a)gmail.com
Demo for Total Annihilation: mouse scrolling of screen unworkable.
On screens that cannot run at 640x480 resolution, the demo of Total
Annihilation has to run in a virtual desktop in order to run at all, otherwise
it crashes. This is not I feel the bug.
The issue targeted by this bug report is that it is unworkably hard to scroll
around the game world by moving the mouse pointer to the edges of the window,
since the mouse pointer has to be positioned *exactly* on the edge of the
window, which is possible, but detracts from the gameplay experience to the
point as to be unplayable.
A possible solution to this issue (which is not really a bug, so much as a lack
of a feature I feel), could be to make it possible to enforce in wincfg that
the mouse is locked to a particular region of the window or screen, by default
to the window itself.
wincfg could provide the possibility to specify a keyboard shortcut to unlock
the mouse when necessary, or simply, by alt-tabbing out of the window, the
mouse could be unlocked.
For an example of another environment that implements this, you could look for
example at dosbox. If you run for example populous in dosbox in a window, it
works perfectly I feel, by locking the mouse pointer to the window, and one can
use ctrl-f10 to free it, which I feel is totally unintuitive, but I feel works
fine.
--
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=48076
Bug ID: 48076
Summary: compile error: ucrtbase: ‘for’ loop initial
declarations are only allowed in C99 mode
Product: Wine
Version: 4.19
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ucrtbase
Assignee: wine-bugs(a)winehq.org
Reporter: version2013(a)protonmail.com
Distribution: ---
Compiling wine-4.19 failed.
distro:
# uname --kernel-release
3.14.56
# gcc --version
4.8.4
# ldd --version
glibc 2.19
my config line:
configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-x
--libdir=/usr/lib32 CFLAGS="-O2 -march=i486 -mtune=i686"
--
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=47807
Bug ID: 47807
Summary: Wine Mono fails to install fakedlls
Product: Wine
Version: 4.16
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: msi
Assignee: wine-bugs(a)winehq.org
Reporter: madewokherd(a)gmail.com
Distribution: ---
When creating a new prefix and installing Wine Mono by downloading the msi,
fakedlls are not installed in c:\windows\Microsoft.NET. For example, fusion.dll
is missing.
I do not believe this was caused by a change in Wine Mono.
This may be relevant:
001c:err:msi:execute_command unable to execute command 2
001c:err:msi:execute_command unable to execute command 2
--
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=48019
Bug ID: 48019
Summary: SSE register MXCSR is wrong for new threads
Product: Wine
Version: 4.15
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: mterrisse(a)free.fr
Distribution: ---
Created attachment 65554
--> https://bugs.winehq.org/attachment.cgi?id=65554
Command line executable with source code to get MXCSR in a new created thread
Hello,
I am running Wine 4.15 64 bits (PlayOnLinux) on Ubuntu 19.10 (More recent
versions of Wine are not available yet).
On Windows when a new thread is created (CreateThread), the value of the SSE
register MXCSR is initialized to 0x1f80.
But for Wine 4.15 on Ubuntu, it is initialized to 0x1920.
This is fatal for our programs that use libcef.dll (Chromium Embedded
Framework), this library creates new renderer threads, doesn't set the MXCSR
register (so exceptions due to denormalization of floats are not masked), then
there is an unhandled exception and the whole program crashes.
I tested with Wine 4.18 on macOS 10.15.1 Catalina, I get the correct value
0x1f80, and indeed there is no crash on macOS.
So this is specific to Wine on Linux (except is something has changed between
Wine 4.15 and Wine 4.18).
Here attach you can find a command line executable with source code (Delphi)
that displays the value of MXCSR for a new thread.
Thank you for your help.
Regards,
Michel Terrisse
--
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.