On Thu Oct 5 17:32:10 2023 +0000, Aidan Khoury wrote:
> 1. Yes, however not easily. With my sample PE (which is what I used to
> make the "normalized" buffers), it was not complex enough to emit patch
> transformations when I used the mspatchc API. I tried for about a dozen
> hours before giving in and using an existing real world buffer, which I
> extracted from the adobe installers.
> 2. Possible, yet extremely complicated as patch transformations appear
> pretty complex.
> The source of the buffers is the adobe acrobat x86_64 installer.
Does that mean that the test data is copyrighted?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3870#note_47745
On Tue Oct 3 16:18:47 2023 +0000, Zebediah Figura wrote:
> > Oh! Okay, I will use `RtlImageNtHeader` and then do the bounds checks
> afterwards :)
> I suppose it's a matter of taste, but personally I don't find this an improvement...
So, should I make the effort or no?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3870#note_47741
On Thu Oct 5 17:32:10 2023 +0000, Jeffrey Smith wrote:
> The three .h files in your tests are --in effect-- huge data blobs,
> which is something that should usually be avoided in source code repositories
> as far as is possible. I haven't had a chance to look in detail at how
> you are using them,
> but here a couple of things you may want to investigate:
> 1. Can the tests be accomplished with smaller sample files?
> 2. Better yet, can the buffers be --at least partially-- generated
> programmatic at test time? (as I did with `setup_pe_with_sections` in
> my tests)
> BTW, what was your source for those three buffers?
1. Yes, however not easily. With my sample PE (which is what I used to make the "normalized" buffers), it was not complex enough to emit patch transformations when I used the mspatchc API. I tried for about a dozen hours before giving in and using an existing real world buffer, which I extracted from the adobe installers.
2. Possible, yet extremely complicated as patch transformations appear pretty complex.
The source of the buffers is the adobe acrobat x86_64 installer.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3870#note_47740
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