https://bugs.winehq.org/show_bug.cgi?id=45647
Bug ID: 45647
Summary: chromium x64 sandbox >=win10 needs win10 csrss heap
Product: Wine
Version: 3.13
Hardware: x86
OS: Linux
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
Created attachment 62076
--> https://bugs.winehq.org/attachment.cgi?id=62076
Patch to provide csrss heap and fake win10 heaps
Follow up to bug 45646.
Starting with win10, the chromium sandbox tries to find a certain heap that's
shared with csrss.exe. It does this by enumerating all process heaps, looking
in the internal structure for the right flags. For that it assumes the internal
structure behind the opaque handle...
We need to do 2 things here.
1) Provide a csrss heap in the first place
2) Return handles that have a heap structure similar to win10 heap behind them
--
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=44960
Bug ID: 44960
Summary: Unable to use python WMI winmgmts object
Product: Wine
Version: 3.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: wmi&wbemprox
Assignee: wine-bugs(a)winehq.org
Reporter: 20917771(a)student.uwa.edu.au
Distribution: ---
Created attachment 61068
--> https://bugs.winehq.org/attachment.cgi?id=61068
A minimal test case
I am trying to use pywin32 to wait on an external process using its PID. I used
winetricks WMI. I am using Ubuntu 16.04 LTS with Wine 3.5. I have attached a
minimal example of the Python script. I expect it to wait for the other process
to complete. Instead, I get the following output and the process exits
immediately:
0009:fixme:kerberos:kerberos_SpInstanceInit 65536,0x7e0413a0,(nil): stub
0033:fixme:kerberos:kerberos_SpInstanceInit 65536,0x7e0913a0,(nil): stub
0009:err:ole:apartment_getclassobject DllGetClassObject returned error
0x80004002 for dll L"C:\\windows\\system32\\wbem\\wbemdisp.dll"
0009:err:ole:create_server class {172bddf8-ceea-11d1-8b05-00600806d9b6} not
registered
0009:fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported
0009:err:ole:CoGetClassObject no class object
{172bddf8-ceea-11d1-8b05-00600806d9b6} could be created for context 0x15
0009:err:ole:create_server class {8bc3f05e-d86b-11d0-a075-00c04fb68820} not
registered
0009:fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported
0009:err:ole:CoGetClassObject no class object
{8bc3f05e-d86b-11d0-a075-00c04fb68820} could be created for context 0x14
Traceback (most recent call last):
File "test.py", line 10, in <module>
wmi = win32com.client.GetObject('winmgmts:')
File "C:\Python27\lib\site-packages\win32com\client\__init__.py", line 72, in
GetObject
return Moniker(Pathname, clsctx)
File "C:\Python27\lib\site-packages\win32com\client\__init__.py", line 87, in
Moniker
moniker, i, bindCtx = pythoncom.MkParseDisplayName(Pathname)
pywintypes.com_error: (-2147221164, 'REGDB_E_CLASSNOTREG', None, None)
--
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=51819
Bug ID: 51819
Summary: Joining a LAN Game in Battlefield 2 crashes the app
Product: Wine
Version: 6.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fzatlouk(a)redhat.com
Distribution: ---
Created attachment 70704
--> https://bugs.winehq.org/attachment.cgi?id=70704
stdout
Attempting to join a LAN Game in Battlefield 2 ends with game crash, both with
32 or 64 bit prefixes. Single Player and hosting LAN games work flawlessly.
Tested on wine staging 6.16, both with and without dxvk. I'll add debugger
output and test with newer wine later.
--
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=45988
Bug ID: 45988
Summary: Hard Reset Redux and Shadow Warrior 2: no videos in
game
Product: Wine
Version: 3.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: petrushkinsn(a)gmail.com
Distribution: ---
Created attachment 62547
--> https://bugs.winehq.org/attachment.cgi?id=62547
wine terminal output running Hard Reset Redux
No videos between levels, nor starting video with developer logo etc.
In Hard reset redux, if i open Extras - Movies in main menu and select any
movie - nothing happens.
In Shadow Warrior 2, if i open Extras - Movies and select movie, screen blanks
for less than a second and then nothing hapens.
Both logs created with run game, go to extras - movies, try to start movie,
exit game.
--
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=44003
Bug ID: 44003
Summary: Origin: BF3WebHelper.exe crashes because injection of
igo32.dll fails.
Product: Wine-staging
Version: 2.20
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: bernhardu(a)mailbox.org
CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de,
sebastian(a)fds-team.de
Distribution: ---
Created attachment 59662
--> https://bugs.winehq.org/attachment.cgi?id=59662
Standalone demonstration of the issue similar to what Origin does.
When starting a game from Origin a crash dialog for BF3WebHelper.exe is shown.
Shift+right click - "Debug" seems to get another thread further, so it can
successfully then still execute Firefox.exe.
Used a self built wine-2.20 with the whole staging patch set applied.
Tried to get an idea of what happens:
- Origin calculates the entry point for LoadLibrary using the kernel32 fake dll
and the base address of its own process.
- CreateProcess with suspended flag is called for BF3WebHelper.exe
- Memory for the to be loaded dll is reserved and filled in
the new process ("...\\igo32.dll").
- A second thread in the new process is created by CreateRemoteThread using
the calculated entry point for kernel32.fake.LoadLibrary above.
- This thread crashes because it looks like in the in memory kernel32 module
is something different/uninitialized at the used entry point.
With +BF3WebHelper.exe:all crash does not happen.
(But is still not executing LoadLibrary and seems not to crash by "accident".)
Attached is a demonstration of what happens.
--
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=52991
Bug ID: 52991
Summary: Wine Ignores "Emulate a virtual desktop" option being
checked, blocks me from running programs
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: splatsniper112010(a)outlook.com
Distribution: ---
as the description says, Wine seems to be ignoring the "Emulate a virtual
desktop" option being checked, and keeps blocking me from running programs. The
weird thing is, it's actually worked before. I had not too long ago uninstalled
wine to check if winamp was causing some lag on a game that i was trying to
blay (BTW winamp didn't seem to be uninstalling), and before that, wine was
working WITH the emulate a virtual desktop option!
--
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=53693
Bug ID: 53693
Summary: La-Mulana immediately goes into excessive CPU usage
freeze and makes wm do the same upon killing
Product: Wine
Version: 7.17
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winex11.drv
Assignee: wine-bugs(a)winehq.org
Reporter: galtgendo(a)o2.pl
Distribution: ---
A word of warning: this will be a bit ranty.
At some point La-Mulana did work in wine - with some caveats. Namely, some
portions of one of boss fights *felt* like certain elements moved at incorrect
relative rate to the other making it significantly harder. I call that a
"physics" bug - I know at least one other game that was *definitely* affected
by such problem (youtube Let's play videos have clearly shown it).
I don't recall when that was, might have been a few years already.
Now, however, upon starting it CPU usage spikes to the point when everything
becomes unresponsive. What's even more annoying, if I login at a different
console (as there's no hope for the current xsession) and kill the game, the
window manager (openbox) goes into same spike and also needs killing to restore
things to a working state. What may or may not matter: if both are killed, the
terminal window the game was started in also closes.
Also, this might or might not be somehow hardware related. As I've said, I
don't recall when it worked, but I might have been still on integrated Intel,
now I'm on integrated AMD. This might be unrelated, but on the other hand I
recall that quite a few WolfRPG games that worked decently at some point with
hardware rendering now go into slideshow mode unless set to software. Then
again, hardware rendering in WolfRPG has often been a bit flaky, sometimes
going straight into crashes (some of them even reproducible on Windows) so
that's a poor indicator of anything.
--
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=47788
Bug ID: 47788
Summary: Combobox should not close while using keyboard letters
Product: Wine
Version: 4.16
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
Example:
- Run "wine control intl.cpl"
- On the first tab, click the top combox to open it
- Type down a few letter, like 'G', 'E', 'R'
It should jump to the first entry starting with "GER" while keeping the
combobox open. Instead it closes the combobox.
Might relate to bug 42898.
--
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=38486
Bug ID: 38486
Summary: Sim City 3000 crashes / doesn't load
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: rufusthompsoncox(a)yahoo.co.uk
Distribution: ---
Created attachment 51331
--> https://bugs.winehq.org/attachment.cgi?id=51331
Error details
Sim City 3000 crashes / doesn't load. Error details attached.
--
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=50920
Bug ID: 50920
Summary: Implement a 32-bit OpenGL wrapper that forwards calls
to a 64-bit display window through IPC
Product: Wine
Version: 5.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: opengl
Assignee: wine-bugs(a)winehq.org
Reporter: milasudril(a)gmail.com
Distribution: Ubuntu
It is getting harder to run 32-bit OpenGL apps. In particular If you install
the CUDA driver for NVIDIA, you will only get the 64-bit driver. A possible
solution would be to create a separate 64-bit process, that is responsible to
forward OpenGL calls from the 32-bit application to the 64-bit driver.
Some thoughts about implementation possibilities:
* OpenGL never use pointers as handles, but 32-bit ints. Thus it should be
possible to implement a working IPC solution without any pointer translation
table.
* Immediate mode (legacy) OpenGL, will naturally generate more IPC calls.
However, these functions could be implemented in wine, and glEnd could be the
trigger to flush any buffers and to issue the IPC call.
Some thoughts about drawbacks:
* Increased number of context switches which causes increased latency. However,
it is possible to use IPC to have a 32-bit WINE process communicating with
JACK, with sufficiently low latency for realtime audio, which has slightly
higher requirements on low latency then video output, so it should be feasible.
Some thoughts about implementation difficulties:
* Each OpenGL command will need an id, but perhaps this could be auto-generated
--
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.