https://bugs.winehq.org/show_bug.cgi?id=50865
Bug ID: 50865
Summary: Map editor of Heroes of Might and Magic 5 completely
not working
Product: Wine
Version: 6.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: galdralag(a)bk.ru
Distribution: ---
Created attachment 69677
--> https://bugs.winehq.org/attachment.cgi?id=69677
Screenshot
Heroes of Might and Magic 5.
Map editor starts, shows left and right panels with games elements. But on
place of map it shoes garbage rectangle.
See attached screenshot.
--
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=56359
Bug ID: 56359
Summary: Winedbg is broken when trying to break
Product: Wine
Version: 8.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winedbg
Assignee: wine-bugs(a)winehq.org
Reporter: rikul(a)inbox.ru
Distribution: ---
Steps to reproduce:
1. Run "wine64 winedbg notepad"
2. "c"
3. Ctrl+C (might need to do it twice if nothing changes the first time)
It broke starting from
[b1f59bc679a8c2dea18a6789a5b9b1a1ae825129] makefiles: Add support for multiple
PE architectures.
Reverting it fixes winedbg, however reverting stops helping after
[cc2cfb9b792bee681b96c5859084fd6d4d0bbed7] loader: Make the loader
position-independent on 64-bit.
--
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=6946
Aida Jonikienė <aidas957(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aidas957(a)gmail.com
--- Comment #23 from Aida Jonikienė <aidas957(a)gmail.com> ---
Does this bug still exist in the latest Wine version?
--
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=55630
Bug ID: 55630
Summary: DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 is not
handled in GetAwarenessFromDpiAwarenessContext
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: umu618(a)hotmail.com
Distribution: ---
Now
GetAwarenessFromDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2)
returns DPI_AWARENESS_INVALID, which is incorrect.
Should add the following:
```
case (ULONG_PTR)DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2:
return DPI_AWARENESS_PER_MONITOR_AWARE;
```
--
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=6254
Alban Browaeys <prahal(a)yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |prahal(a)yahoo.com
--- Comment #93 from Alban Browaeys <prahal(a)yahoo.com> ---
> James McKenzie 2011-05-07 23:15:14 UTC
>
> This bug has not been forgotten, but AJ wanted this function implemented in a different way that is correct. First EM_DISPLAYBAND must be implemented and then EM_FORMATRANGE. This is being investigated.
Could we have the plan AJ envisioned? I doubt he will implement it himself
nowadays.
So at least someone else could implement it.
Right now, we know AJ will not accept anything out of his plan, but we do not
know what is the plan.
Or is the plan only that EM_DISPLAYBAND must be implemented first then
EM_FORMATRANGE?
I have been paying for crossover since 2003 to contribute financially.
There were a lot of improvements in a lot of domains. But 1 in the 10 Windows
apps I use on Linux is broken by this missing feature:
(endless loop of:
01b0:fixme:richedit:editor_handle_message EM_FORMATRANGE: stub
01b0:fixme:richedit:editor_handle_message EM_FORMATRANGE: stub).
I would like to get rid of this riched20 native dll.
I have been looking at this bug for more than 15 years...
I know AJ is great but he is not eternal. If at least we could know what he
wants for riched20 to implement this function.
--
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=56346
Bug ID: 56346
Summary: Sketchup Make 2017 Extension Manager to install Ruby
extension crashes.
Product: Wine
Version: 9.0-rc5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dlbeeson(a)netzero.net
Distribution: ---
SketchUp Make 2017. Runs well, BUT can not EXPORT. On windows Export pops up
window with about 6 options. On MX Linux and Wine, only option is DAE. When try
to run Extension Manager, which would install a STL converter (among other
things) it crashes. So you can not install the Ruby extensions to export in STL
format, for 3D printing. Please help. Thank you.
--
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=56364
Bug ID: 56364
Summary: Crazy Factory: Hang when starting new game
Product: Wine
Version: 9.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: winebugzilla(a)tasossah.com
Distribution: ---
Created attachment 76101
--> https://bugs.winehq.org/attachment.cgi?id=76101
Minimal reproducible example: client
Crazy Factory (AppID 13494, also known as Gadget Tycoon) hangs when starting a
new game (Main Menu -> Offline game -> Freeplay). This is not a regression, but
has last been tested under wine-staging 9.2.
The game (client) spawns the server (CrazyFactoryServer.exe), waits for it to
finish initialising by calling WaitForSingleObject() and WaitForInputIdle(),
and then looks for its HWND so that it can communicate with it using window
messages.
I have written a standalone test case which reproduces this issue in Wine
without requiring access to the original software.
To reproduce:
1. Download client.c and server.c
2. Compile them as follows:
- i686-w64-mingw32-gcc server.c -l ole32 -mwindows -o server.exe
- i686-w64-mingw32-gcc client.c -o client.exe
3. Run client.exe
Under Windows XP: client.exe reports "HWND Found" and exits.
Under Wine: client.exe hangs on WaitForInputIdle().
The only way in Wine to get WaitForInputIdle() to return is by running
everything in a virtual desktop, clicking on the start menu (which makes the
server show up in the taskbar), clicking on the server in the taskbar, and then
clicking on the server's window decoration and moving it around.
Unfortunately, since the game itself runs in fullscreen, one can not click and
drag the server window. Instead, to get the game working as-is, one can patch
the binary (556b01b1afa97f39d361fe692bc3477a2577a25abf91f4a92e88a561bd5bd561
GadgetTycoon.exe) by setting the byte at offset 0x241ED from 0xFF to 0x01. This
sets the dwMilliseconds parameter on WaitForInputIdle() to 0x01 (instead of
INFINITE), which makes it time out, thus avoiding the hang and getting the game
running.
--
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=56366
Bug ID: 56366
Summary: Worms Blast characters become grey/untextured
Product: Wine
Version: 9.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: iodreamify(a)gmail.com
Distribution: ---
Created attachment 76106
--> https://bugs.winehq.org/attachment.cgi?id=76106
wine log
If you play a game vs cpu, when 2 characters are on screen, one or both of them
will become grey as if they're untextured. Sometimes it's the whole character
and sometime only their weapon or boat. It doesn't seem to be tied to any
action or event, they'll become grey and then rendered correctly again with
color.
Tested this with Wine 9.3 inside Wine Steam.
Also, in puzzle mode, when there's a single player, it doesn't seem to happen
as fast or at all.
Steps to reproduce:
1. open game
2. choose game vs cpu
3. select deathmatch
4. swim around in game a bit
Kernel Version: 6.7.5-arch1-1 (64-bit)
mesa 24.0.1-1
Graphics Platform: X11
Graphics Processor: Mesa Intel® HD Graphics 3000
--
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=54346
Bug ID: 54346
Summary: (Multithreaded) Applications sometimes get heap
corruption on exit due to ignoring critical sections
in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: dmusic
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
(Multithreaded) Applications sometimes get heap corruption on exit due to
ignoring critical sections in Wine. For instance dmloader:loader:
0118:warn:sync:RtlpWaitForCriticalSection process
L"Z:\\home\\fgouget\\wine\\wine-gitlab\\dlls\\dmloader\\tests\\i386-windows\\dmloader_test.exe"
is shutting down, returning STATUS_SUCCESS
...
0118:warn:sync:RtlpWaitForCriticalSection process
L"Z:\\home\\fgouget\\wine\\wine-gitlab\\dlls\\dmloader\\tests\\i386-windows\\dmloader_test.exe"
is shutting down, returning STATUS_SUCCESS
0118:err:sync:RtlLeaveCriticalSection section 00140074 "dlls/ntdll/heap.c: main
process heap section" is not acquired
Normally this does not cause the test to fail. But when running with
WINEDEBUG=heap this frequently leads to heap corruption because:
* Each call to the heap API triggers a heap validation.
* Each heap_validate() call is requires taking the main process heap lock.
* More contention makes the "not acquired" events more likely.
* Leading to multiple threads manipulating the heap at the same time, thus
causing corruption.
Also, be aware that when heap corruption is detected due to WINEDEBUG=heap,
Wine raises an exception which kills the process.
Also note that although dmloader:loader looks like it is not multithreaded (no
CreateThread() call), it loads dlls that create their own thread:
* winealsa.drv/midi.c -> notify_thread
* winealsa.drv/mmdevdrv.c -> alsa_timer_thread
* winepulse.drv/mmdevdrv.c -> pulse_mainloop_thread, pulse_timer_cb
...etc.
So this issue probably impacts most audio / multimedia applications and Wine
tests.
The "main process heap section is not acquired" errors most often look like
they are caused by the following functions which are all called on
DLL_PROCESS_DETACH:
* msacm32.MSACM_WriteCache() calling RegSetValueExA()
* ucrtbase.msvcrt_free_io() calling DeleteCriticalSection() when WINEDEBUG=heap
Ignoring the critical sections during shutdown is intentional and was
introduced by the 7def0f200f11 commit to fix bug 42470. See
RtlpWaitForCriticalSection():
/* Don't allow blocking on a critical section during process termination */
if (RtlDllShutdownInProgress())
{
WARN( "process %s is shutting down, returning STATUS_SUCCESS\n",
debugstr_w(NtCurrentTeb()->Peb->ProcessParameters->ImagePathName.Buffer) );
return STATUS_SUCCESS;
}
However that commit also had to add todo_wine statements to kernel32:loader so
it's not clear that is is correct.
--
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.