https://bugs.winehq.org/show_bug.cgi?id=42764
Bug ID: 42764
Summary: Proteus direct 3D render problem
Product: Wine
Version: 2.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: hildogjr(a)gmail.com
Distribution: ---
I now that OpenGL sill not supported by Wine, so I use
https://appdb.winehq.org/objectManager.php?sClass=version&iId=27887
to use the Proteus 8 (ARES / ISIS) with Direct3D.
But (main) in the "3D Visualizer" function, the software running in Wine spend
a long time to render the objects and sometimes miss something (details or
objects).
--
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=48136
Bug ID: 48136
Summary: Wine can't be started, log notice: wineboot failed to
start wineboot c00000e5
Product: Wine
Version: 4.20
Hardware: x86
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: avenjames(a)live.com
Created attachment 65735
--> https://bugs.winehq.org/attachment.cgi?id=65735
Problem.
After updating from 4.19 Staging to 4.20 Staging in Mac OSX 10.13.6,
I was making the first starting refresh work as I usually do,
but after typing "winecfg" it show nothing but the Term show it was going back
to waiting input state,
but when I try "CMD" to start the commander line and run the "winecfg"
the CMD was working but after running the "winecfg" I notice that the term said
nodrv createwindow, failed to start again.
attached the rest of the logs.
--
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=47992
Bug ID: 47992
Summary: msi:action tests fail when running them twice
Product: Wine
Version: 4.17
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msi
Assignee: wine-bugs(a)winehq.org
Reporter: sven.wine(a)gmail.com
Distribution: ---
See the test results on the cw-*-64 machines, which are being run after the 32
bit tests:
https://test.winehq.org/data/tests/msi:action.html
This is due to the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\$USER\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\Features
key still being left after the tests. I'm not sure how to properly remove it.
Most machines are being reverted for every test run, so there it is not
visible.
--
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=47029
Bug ID: 47029
Summary: A.R.E.S. Extinction Agenda 1.x (.NET 2.0, XNA 3.1
game) crashes during intro (needs IWMPMedia::put_name
implementation)
Product: Wine
Version: 4.6
Hardware: x86-64
URL: https://www.fileplanet.com/archive/p-40578/A-R-E-S-Ext
inction-Agenda-Demo
OS: Mac OS X
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: wmp&wmvcore
Assignee: wine-bugs(a)winehq.org
Reporter: gijsvrm(a)gmail.com
Created attachment 64197
--> https://bugs.winehq.org/attachment.cgi?id=64197
+wmp log
Follow up of bug 45365.
winetricks -q qasf needed to work around bug 34622.
winetricks -q wmp9 works around this bug.
Attached is a +wmp log.
Tested Wine 4.6 in a 32bit prefix.
--
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=46916
Bug ID: 46916
Summary: Can't restore focus to certain minimized fullscreen
applications
Product: Wine
Version: 4.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: chrylis(a)gmail.com
Distribution: ---
Created attachment 64004
--> https://bugs.winehq.org/attachment.cgi?id=64004
stderr logs
This is a counterpart to the many (mostly resolved?) bugs regarding switching
*out* of fullscreen applications. On some applications, I can switch out of the
window without any problem. If the application has changed the desktop
resolution, it is restored to the previous setting (e.g.,
1920x1080->3840x2160).
However, I cannot restore focus to the application once it loses focus. The
application will unminimize (from the taskbar or the window switcher), and the
mouse cursor changes to the appropriate graphics, but the application seems
never to be unblurred; it's not redrawn (I believe this is its own choice when
it thinks it doesn't have focus), and the "bookmarked" resolution isn't
applied. The application does not respond to input, and I have to kill Wine
from the CLI.
The applications I have available where I'm able to reproduce the behavior are
based on the Civ4 engine (Civ4 itself, Railroads!). The behavior is identical
regardless of whether the application changes the screen resolution (if it
hasn't, then it'll switch back to full screen and show the last render but is
still frozen). Fallout 2, with or without Restoration, does *not* reproduce the
behavior. It may be linked to D3D.
I'm running KWin 5.14.5 on Intel graphics.
--
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=40187
Bug ID: 40187
Summary: Dream Acquarium can't run
Product: Wine
Version: 1.8
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: sdunnagan(a)yahoo.com
Distribution: ---
Something changed in the Dream Acquarium application, and now it doesn't
run after it automatically installs updates.
--
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=45216
Bug ID: 45216
Summary: Alien: Isolation crashes on startup
Product: Wine
Version: 3.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: moihack.inside(a)gmail.com
Distribution: ArchLinux
Created attachment 61439
--> https://bugs.winehq.org/attachment.cgi?id=61439
Alien:Isolation terminal output
Alien: Isolation (Steam version) crashes on startup.
There is an attempt for the game to load as a process named AI.exe is created
and a window pops up on a black screen but with the mouse cursor changing to
the in-game one. So the game at least attempts to boot up.
Specifically for Arch Linux which I use, there is a "trick" to get this game
running.
If you install the package "wine-staging-nine" from the official repositories
here : https://www.archlinux.org/packages/multilib/x86_64/wine-staging-nine/
the game boots correctly.
It does not boot up with plain wine-staging or vanilla wine + gallium nine
patches. So it probably needs a mix of patches from both projects.
I'm attaching a terminal output below.
GPU used: Radeon HD 6870
--
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=17101
Summary: Cancelling text with Scientific Workplace leaves last
character
Product: Wine
Version: 1.1.13
Platform: PC-x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: loic.grenie(a)gmail.com
Created an attachment (id=18937)
--> (http://bugs.winehq.org/attachment.cgi?id=18937)
Screenshots
When I delete text under Scientific Workplace, the end of the line is not
treated correctly. Was is most evident is that the last character(s) is(are)
not canceled.
I attach a vertical concatenation of 3 screenshots:
the first is the state before hitting backspace: I typed "abcdefghijkl" and
added an inline image,
the second is after hitting backspace (I cancel the "g"); notice how the last
"kl" are not correctly canceled and the image is not moved to the left
and the third is how it should have looked.
No error message is displayed while hitting backspace (it complains about IME
all the time but I think it's no big deal).
I have seen this problem at least in versions 1.0.1 (under Debian testing,
Ubuntu hardy and intrepid, both 32 and 64 bits) and 1.0.13 (Debian testing 64
bits). The situation is even worse under Ubuntu intrepid (32 bits OS, Wine
v1.0.1) as text disappears as soon as it is typed (Esc redisplays it briefly).
I can live with the image (visible at the end of the line) not correctly
positioned after backspace (it seldom occurs), but the last character not
canceled is a real (visual) pain.
I can test anything you wish and I understand programming/debugging.
Thank you for any help.
SurJector
--
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=47042
Bug ID: 47042
Summary: Ignore replies to patchset parts
Product: Wine-Testbot
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The TestBot treats every email as a potential patch.
This makes sense as replies to a patch could be a new version for that patch
which means it should be tested.
But replies to parts of patches are different. Here is what happened due to the
failure to recognize this.
I'm not sure why but the TestBot must have received the following emails in
this order (this is not the order of the send times but it matches the order in
which I received the emails in my inbox):
* [PATCH 1/5] ntoskrnl.exe: Implement PsLookupThreadByThreadId.
https://www.winehq.org/pipermail/wine-devel/2019-April/144085.html
Part 1/5 in a patch series. The TestBot created a PendingPatchSet object to
track the different parts.
* Re: [PATCH 1/5] ntoskrnl.exe: Implement PsLookupThreadByThreadId.
https://www.winehq.org/pipermail/wine-devel/2019-April/144088.html
The TestBot decided this looked like a patch because the HTML version
contains lines that start with "+++ ". Thus it treated this email as a new
version of the previous patch, like it usually does, and replaced patch 1 in
the PendingPatchSet.
* Re: [PATCH 2/5] ntoskrnl.exe: Implement KeAreApcsDisabled using critical
region functions.
https://www.winehq.org/pipermail/wine-devel/2019-April/144086.html
The TestBot created a job to test this patch but used the updated part 1 of
the patch set which in fact was an HTML email. This resulted in an invalid
patch and thus a failure to apply.
The TestBot probably did two things wrong:
1. It took a patch from an HTML attachment.
The TestBot already rejects those but somehow the $Part->effective_type ne
"text/html" test in Patch::NewPatch() did not work.
2. It replaced part 1 of a patchset with a new version.
One cannot send a new version of a part in a patchset: the whole patchset
must be resubmitted (*). So the TestBot should never replace a part in a
patchset.
It looks like this check should be done in PendingPatchSets::NewSubmission()
near the $Set->Parts->GetItem($PartNo) call.
The issue here is that we may receive emails out of order. So we could
receive a reply to part 1, and thus add it as part 1, before we receive the
actual email for part 1.
(*) Otherwise we'd have to keep the patchsets around and create new jobs for
all parts that follow the replaced part. And if multiple parts are replaced...
madness!
--
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=48031
Bug ID: 48031
Summary: Limit the size of the task logs
Product: Wine-Testbot
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The TestBot does not check the size of the reports and logs it downloads from
the VMs. These could be quite big and are even more likely to get big if
setting WINEDEBUG is allowed. So there should be a limit.
The TestAgent GetFile() API has no provision for putting a limit on the size of
the file being retrieved. But checking the size against a limit would come
quite naturally if the files are retrieved one chunk at a time (see bug 48030).
Note that the Wine rebuild logs are quite big (11MB).
--
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.