AvsPmod (Windows_x86) mod

[FranceBB]

Thank you Gispos!
About the avspmod mod and Windows XP incompatibility that Emulgator is mentioning, I think it has more to do with the lack of newer instruction sets than anything else.
In particular, even the latest version, 2.7.9.4 x86 seems to work just fine on Windows XP Professional x86:



The reason why I used "Info()" instead of just Version() is that I wanted to show the instruction sets.
As you can see, I'm running XP on a fairly "modern" CPU ("modern" as in "per XP times" of course) which has up to SSE4.2, in fact Avisynth is reporting:

MMX, ISSE, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, F16C

however in your case you're limited to up to SSE2 with the Pentium 4.
I'm pretty sure that the reason why it's not running is the lack of instruction sets for some commands.
There's also nothing wrong in Dependency Walker:

[gispos]

I think Emulgator suspects that the Python version is the problem because previous AvsPmod versions seem to be able to run under the old hardware/software.
It may be possible, I had changed Python and especially the wxPython version at some point because there were problems with UTF-8/Unicode, especially with wxPython.

[Emulgator]

Nothing to be concerned about recent AviSynth+ and recent AvsPmod, sorry for any disturbances !

Indeed I was doing a post-mortem for academic reasons, meaning to find about python/runtime dependencies,
seeing some development parallels (KiCAD 5 to 6, then to 7)
where a silent python upgrade had lead to incompatibilities, so KiCAD 6 would no longer run under Win7:
"Das Programm kann nicht gestartet werden, da api-ms-win-core-path-l1-1-0.dll auf dem Computer fehlt..."
The reason: KiCAD builds on python, developers updated python silently, and python 3.9.2 had dropped Win7 support.
A good soul built a special compile, and who was able to find his "api-ms-win-core-path-blender-0.3.1.zip",
unpacked and inserted api-ms-win-core-path-l1-1.0.dll had a running KiCAD 6 on Win7.
Until KiCAD 7 broke Win7 support completely.

And I am not asking to build especially for that vintage case.
This is only for maintaining some sahara-stable backwards-compatible emergency systems,
with basic but safe and frozen office, design, audio, video capabilities.
I may swap in runtimes and pythons into these older systems and see which combo holds up.

[FranceBB]

By the way Gispos, I almost forgot about this, but when you have a tiny bit of free time, do you mind clicking "merge" here (don't worry I resolved all conflicts a long time ago)? https://github.com/gispos/AvsPmod/pull/14
I know that you've added those a long time ago (and actually "thank you" for that ) but unfortunately the way GitHub works unless you click "merge" (you are the only one who can do it as the owner of that repository) it will stay there, pending, for the eternity and beyond xD

[pinterf]

Originally Posted by gispos

AvsPmod 2.7.9.4

* Further changes for the avisynth API 11:
- e.g. if AvsPmod was terminated and the memory was exceeded (to many scripts opened), it could happen that AvsPmod did not terminate. 
- for API 10 and before a Destroy() call was sufficient which could lead to problems with API 11

It's strange because, from AvsPmod's perspective, the only relevant behavior change was the infamous "don't call release on the array itself." Anyway, when memory is exceeded, anything can happen; even Schrödinger's cat may or may not have successful encoding session.

[gispos]

Originally Posted by FranceBB

By the way Gispos, I almost forgot about this, but when you have a tiny bit of free time, do you mind clicking "merge" here (don't worry I resolved all conflicts a long time ago)? https://github.com/gispos/AvsPmod/pull/14
I know that you've added those a long time ago (and actually "thank you" for that ) but unfortunately the way GitHub works unless you click "merge" (you are the only one who can do it as the owner of that repository) it will stay there, pending, for the eternity and beyond xD

"Pull request successfully merged and closed"
"You're all set — the branch has been merged."

I hope Github calms down now.

Originally Posted by pinterf

It's strange because, from AvsPmod's perspective, the only relevant behavior change was the infamous "don't call release on the array itself." Anyway, when memory is exceeded, anything can happen; even Schrödinger's cat may or may not have successful encoding session.

I was surprised by that too, but when the program ends, each script must be released individually in a loop, then there are no problems.
With a simple Destroy(), Python is probably not acting in the spirit of the new Avisynth diva.