Resolves https://bugs.winehq.org/show_bug.cgi?id=9127 . (Some of the named programs in that issue may require additional currently-missing functionality, I didn't check; but if so, that's separate issues.)
Tested with
- winetest on Windows 7
- winetest on Windows 10
- winetest in Wine, of course
- microkiri https://bugs.winehq.org/show_bug.cgi?id=9127#c102
- Wagamama High Spec Trial Edition https://wagahigh.com/download_trial.php#normal (ダウンロード means download)
- Ninki Seiyuu no Tsukurikata Trial https://archive.org/details/sayou_trial
(WMV files in microkiri and Wagamama don't work, but that's separate issues. Also, they need the LC_ALL=ja_JP env, or they throw various goofy errors.)
--
v8: quartz/tests: Add tests for CLSID_CMpegVideoCodec.
quartz/tests: Add tests for new CLSID_MPEG1Splitter functionality.
winegstreamer: Improve and clean up some debug logs.
winegstreamer: Implement a little more of IAMStreamSelect in CLSID_MPEG1Splitter.
winegstreamer: Implement CLSID_CMpegVideoCodec.
winegstreamer: Add program stream and video output support to CLSID_MPEG1Splitter.
winegstreamer: Add WG_MAJOR_TYPE_VIDEO_MPEG1 media type.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938
Hey!
First, thanks for addressing this. The fact that CTRL+C closes cmd was the reason I created https://bugs.winehq.org/show_bug.cgi?id=55197.
I have some questions about the current cmd behavior:
- `CTRL+C` creates a new line, but does not write a new prompt to stdout.
Typing text will make text appear again on the original line. Microsoft cmd will create a new prompt, and make new text input appear after that.
- This is probably a feature request, but I think it would be useful to close cmd by pressing CTRL+D (EOF). Other repl's, such as python have this behavior.
If you prefer me to create bugzilla issues for these, let me know.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3312#note_47736
On Thu Oct 5 15:45:41 2023 +0000, YuriK7 wrote:
> We built proton-ge entirely, with as you can see in the previous link,
> the makefile where the gst and ffmpeg build parameters are set.
This doesn't seem to be a problem with this MR, and therefore doesn't really belong here. I'm taking it to the Glorious-Eggroll Discord.
If it does turn up an actual issue, I will, of course, fix it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_47723
This patchset implements dynamic resource handling, and in particular NOOVERWRITE buffer maps, in situations where we don't have GL_ARB_buffer_storage. This is relevant e.g. on MacOS but probably also on some ARM CPUs where write combined memory has different performance characteristics than windows games expect [0].
Some benchmark results from hl2 (chosen because it is very CPU heavy on modern systems and heavy use of dynamic resources), tested on a MacBookPro14,3 on Linux with GL_ARB_buffer_storage disabled.
"csmt usr" means with patch "wined3d: Avoid heap_alloc in update_sub_resource.", "heap usr" without this patch.
"no dyn" means the current upstream code with buffer storage disabled. "sysmem dyn" means the entire patchset of this MR with buffer storage disabled. "BO dyn" is current wine code with GL_ARB_buffer_storage available. I also double checked that this patchset has no impact on this default case. "heapalloc dyn" means the current code in cs_map_upload_bo that returns HeapAlloc'ed memory, just enabled for dynamic buffer maps. This code is faster than sysmem dyn because it doesn't re-upload the entire BO after a DISCARD map. It also happens to be incorrect for non-DISCARD maps because we aren't allowed to throw away existing data, but I think it isn't ever used for maps in practise due to mutually exclusive flag checks in the callers and callee.
Summary: This patchset improves performance measurably (240 fps to 327 fps). The patch that avoids HeapAlloc calls when setting shader constants has an impact, but it is relatively small - much smaller than I expected. Plus the ntdll heap code is pretty good by now.
csmt usr heap usr
no dyn 246 240
sysmem dyn 327 318
BO dyn 382 369
heapalloc dyn 344 335
0: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8301
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4019
This should implement error page navigation similar to native, which is unfortunately mostly undocumented.
Briefly, native uses a local resource in some DLL (the exact one varies by Windows version and locale, so it's not reliable to test) which has a bunch of html error pages for various errors (404 is a different resource than 405, etc). In Windows XP this is in `shdoclc.dll` (which is where I placed it as well, because we already use it in Wine), in Windows 10 it's somewhere in `system32\en-US\ieframe.dll` (or something like that), for US locale at least.
To keep it simple for now, this only adds one error page called `ERROR.HTM` though, which is generic and displays the error code (given via a query). That said, it should still probably be localized somehow, but I've no idea how to localize html resources…
The error page is navigated with URL of the form `res://C:\windows\system32\.../NAME.HTM#original_url`, and some of the notifications are special cased to return the original_url from the fragment (on native as well, tests included).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4016