This is the same script Andreas already posted the most recent (and therefore updated) version in this very thread.

For anyone that's looking for the backup info (INF) the package Doug pointed to certainly has that. But I would advise against using the CMD file that's included there as opposed to the updated one that's provided by Andreas here.

You can turn ON the same log in your smplayer by going here: Options => Prefeerences => Advanced => Logs tab, then check box teh SMPlayer entries (both). This at least will tell you if smplayer is grabbing the right data and sending it over to mplayer to play back.

Re: GUI clients...makes sense you guys. I do have a coding editor already that I use for all my projects, that being Visual SlickEdit. It has the version control framework already in place, although of course it is up to you to configure the client specfiic things. Our OS/2 version is ancient by comparison to the modern releases, so as is to be expected those newer versions support the numerous CVS, SVN, Git, etc. right ouf-of-the-box.

..I see where it fails but I could not reproduce nor do I see why you've got the invalid whole numberI added a few verification to check not going into an invalid whole number into this part of the code as well. Also added routine if the input file could not be read "already open" or other errors ( if ffmpegh started well with parameters but the radio button isn't on ! them, click on it to display latest messages)...

Looks to me like the program is not using a fully qualified DLL_LIST filename due to no fault of it's own. It seems this is the result of the WPS program object defintion I created, where I have the following:

NOTE: whatever way you're handling the trap is also preventing (here on my machine) me from going back to the GUI window itself to actually close the program, instead I use 'kill' which does successfully close it.

2) re-do the start, same input command line, but now I actually modify the text-field which stores the input parameter the program was originally started with, so instead of just using the filename (usr_dll_list.dlh) I now use a fully qualified name so that includes the complete path (g:\util\misc\usr_dll_list.dlh), this produces the following successfull output:

The way to get around this is to modify the WPS Program object to set the INPUT_PARAMETER to show a fully qualified path, which I tested and am happy to report that it works.

I did not try setting the WORKING_DIRECTORY in the Program object to see what impact, if any, it had.

Alright, I would say this works. Unless there were any other changes in this test build (other than the DEBUG stuff) I think I can go back to using the previous release and just use a fully qualified pathname as the input parameter.

Hmm, alright, so for what it's worth I am thinking an install of SVN will get me places faster.

A while back I grabbed SVN 1.7.21 from Paul's site (unable to get to it at the moment to check for updates). The official SVN (http://subversion.apache.org/docs/release-notes/) is up to 1.14 level now, with 1.13 being classified as production release.

Are there any plans to at least get us party further than our 1.7.x release?

...Did you run ffmpeghigh -q usr_dll.DLH to do the query for the corresponding DLLs ?Wihtout specifying the dll list, no chance to find DLLs loaded out of the default defined into ffmpeghigh

This is the case for -l -q or -u option. in each case, add the file including a dlls list to get information from these dlls.

No, see the way I was running these is to define the program object where I would pass the '-l dll_list.dlh' parameter. The GUI window then comes up, but the dll/load_list text field is empty. Therefore, each time I would select 'Query' or 'Free' no wonder i was getting the results I saw. I was anticipating / expecting that the program surely knew what DLLs I was inquiring about since I passed that list in at start-up-time as an input parameter after all.

So for example, having started the program in that fashion, when I press the radio button next to the '*DLL' label I see the following output:

This behaviour is what confused me. Because in the 1st example above the program knows what DLL it is looking at (that which was loaded from the INPUT command line) but in the 2nd case it does not, that is because when pressing the 'Free' or 'Query' button it's actually attempting to take the input from the text-feld instead.

Now that I understand how the GUI part works the results are correct whenever I pass the actual dll_list.dlh I originally started the program with.

So here is a request/suggestion: when such a DLL list is passed along to the program at load time, can you automatically list that name in the text field? That way when you have multiple GUIs started you do not have to wonder which one is which...and best of all, even if you have a single one running you do not have to re-type the dll_list.dlh each time into that field.

...Did you load ffmpeg dlls prior the query ?If you would like check the loaded DLL, be sure to specify the dll list for the -q and -u option.From what I could see, rxu function was unable to find handle for the given dlls...

No, I did not load any other DLLs high, just SNAPWRAP.DLL.

I am not sure why the other DLLs show up in both the Free and Query lists, I assume that it's because your code is looking for the presence of the '~ffmpegH' file and getting that info from there?

...It might be time for you to consider moving up in the AMD world. I seem to remember that you said your son has a Ryzen based machine - if so there is a simple test you can do - make a disk image of your working system, copy it to another disk then borrow the Ryzen box and swop its HD for your copy - power up and see what happens...

Actually, I do intend to test that box out eventually, however, for the time being I am waiting for AOS to release a UEFI capable USB stick boot since that AMD box does not have a DVD reader. Otherwise, the only way to do this is by doing what you describe and I really can't afford to take a chance that anything might impact that box (dreaded disk mix-up, etc.). My son is using that right now to finish up a bunch of his school projects so from that perspective it's what I consider to be a "production box" status.

I hope you aren't marking snapwrap.dll to load high, remember that anything that accesses a 16 bit function should not be loaded high...

Actually...yup, loading high and both VLC and mplayer certainly seems to be fine with it. No issues so far anyways.

Not sure that this particular DLL has ever caused a problem in the past, however in my attempts to try to minimize the amount of shared-memory consumption I figured I would toss as many things into high-memory as possible and see how they pan out.

!Information! no ~ffmpegH file found ! (this could be normal at first load request) --------------------------------------------------------- No query handle found for DLL: X264150 - an RC99 will be set fo this DLL on free No query handle found for DLL: LIBVPX5 - an RC99 will be set fo this DLL on free No query handle found for DLL: SDL2 - an RC99 will be set fo this DLL on free No query handle found for DLL: POSTPR55 - an RC99 will be set fo this DLL on free No query handle found for DLL: AVDEVI58 - an RC99 will be set fo this DLL on free No query handle found for DLL: SWRESA3 - an RC99 will be set fo this DLL on free No query handle found for DLL: SWSCAL5 - an RC99 will be set fo this DLL on free No query handle found for DLL: AVFILT7 - an RC99 will be set fo this DLL on free No query handle found for DLL: AVCODE58 - an RC99 will be set fo this DLL on free No query handle found for DLL: AVFORM58 - an RC99 will be set fo this DLL on free No query handle found for DLL: AVUTIL56 - an RC99 will be set fo this DLL on free No query handle found for DLL: VLCCORE - an RC99 will be set fo this DLL on free No query handle found for DLL: VLC - an RC99 will be set fo this DLL on free End of dynamic handle acquisition (query), process continues...

I used to do a whole lot of professional software development, but that was primarly Oracle database/ERP stuff. Still, in those days I lived by the Visual SlickEdit environment which is also part of the reason why I bought that IDE package for our OS/2 platform when it was still available. It is discontinued now and sadly they will not opensource it (I asked repeatedly but was told that was not a possibility).

In my case that is the setup I have to support multiple C/C++ compiler environments. The best part of it is due to the fact that a VSE (VisualSlickEdit) project can be configured as based on a particular compiler toolset. So today I have the following: GCC and IBM C/C++ 3.6.5. Even if you were looking to have multiple GCC releases (like the old trusty 4.9.x or the newer 9.x) you could define these as well and make sure that your environment is setup correctly. I am actually trying to work through some of that right now, but as it turns out there is never enough time to allocate to these things, so progress is glacialy slow...LOL!

Othewrise, I think OpenWatcom is a good and matured true IDE, with all the various bells and whistles.