OS/2, eCS & ArcaOS - Technical > Applications

LarsenCommander - new test version

<< < (3/4) > >>

Rich Walsh:

--- Quote from: Andi B. on June 08, 2023, 11:19:04 am ---
--- Quote from: Andy Willis on May 20, 2023, 07:28:48 pm ---One thing that I would like I would like to see (maybe I can work it out) is to have lcmd.exe look for gl16os2.dll in its own directory first before looking at libpath, this would allow it to run without gl16os2.dll having to be in libpath.

--- End quote ---
Are you asking for some 'special' code in LCMD which loads the dll from the programs directory regardless of libpath setting? Are there some example programs for such?

--- End quote ---

The solution to this particular problem is to get rid of the DLL -- there's no reaon for it to exist. The original author claimed that VACPP 4.0 couldn't handle a 16-bit call so he created a separately-compiled file. But rather than simply linking it into the exe with all the other .obj files, he created a dll. Why?

VAC 3.65 has no problem with 16-bit calls, and AIUI, 3.65 is just 4.0 without the class libraries. I'd expect you could compile this file the same as all the others, then add it to the ilink cmd line. Even if you do need to use a different compiler, it should still link OK.

Lars:
I think, this misunderstanding stems from the fact that every IOPL example (which means 16-bit code use by the nature of IOPL support in OS/2) seems to imply that you need to put the IOPL code into a separate DLL. Well, you do not have to do that, just needs some additions to the def file and you can happily link 16-bit IOPL code to the rest of your 32-bit app.

Andi B.:
Thanks Rich and Lars. I'm thinking about your inputs and hope to find the time to come back to this.

Rich, to my understanding VAC4 is a complete different thing. It uses vacbld which creates a code store and compiles all sources at once (?) instead classic icc for every file and makefiles. But in the package of VAC4 there's also included v3.65 with a lot of information when you can or should switch from older versions to 4.0 or to 3.65. I read them long ago and probably forgot most of them. Anyway I'm thinking about switching to gcc since a while. But it's not that easy and so not top priority.

Currently I try to track down a memory leak in LCMD in some situations. Doing this I stumbled over a shortcoming in pmprintf which eats up all lower shared memory when loaded very heavy. So I try to improve pmprintf first (make use of high mem). While doing this I was bitten by a shortcoming of our os2ahci driver. Reproducing this problem, creating a ticket and help to track it down took a lot of time. So it's all about having to less time for all these interesting stuff to get finally solved. So better not giving any time frame....

Andi B.:
I've upload a new version here - https://sourceforge.net/projects/lcmd-git/files/

Mind this is a new project page at sourceforge as I'm using git instead svn now.

This is a lxlite stripped down debug version with the debug information in the *.dbg file. In case of an exception exceptq should be able to create a nice report. At least when the lcmd build in exception handlers will not catch it before (ToDo for future releases). Although debug symbols are compiled in, pmprintf.dll should not be needed for this build.

Changes from last release are -
- Fine tuning for dynamic copy buffer size adoption
- Reduce logging while copying huge amount of files (reduces memory needs and log file size)
- Disable playing priority games in hope of better overall system response
- Adding ExceptQ handler (not working yet as own exception is still active)
- Fixed some cppcheck warnings (thanks Andy Willis for that)
- Add some comments for using highmem in some places (currently not used)
- Add writing to PmPrintf queue in parallel to log file when #ifdef __DEBUG_TRACE__
- Use HighMem for copy buffer

Especially the tuning of the copy buffer algorithm makes a big difference in copy speed in so some cases. At least with my rather fast HDDs and SSDs and big files. But also with Samba shares or other source/targets differences can be observed. All my measurements gave good results. I think this is near to the maximum copy speed we can reach with an PM OS/2 application with progress bar. If you think copy speed now is slower than with any previous version please share your experience here with clear instructions to reproduce. I really tested a lot scenarios with different targets and think the current implementation is better then everything before. Mind 'copy' from command line is most of the time still a bit faster as it does not have the overhead of a graphical progress bar and no checks for interruption during copying a file.

Get ride of gl16os2.dll is still on the ToDo list though.

Dariusz Piatkowski:
Hi Andi,


--- Quote from: Andi B. on November 30, 2023, 07:13:48 pm ---I've upload a new version here - https://sourceforge.net/projects/lcmd-git/files/
...
Changes from last release are -
- Fine tuning for dynamic copy buffer size adoption
- Reduce logging while copying huge amount of files (reduces memory needs and log file size)
- Disable playing priority games in hope of better overall system response
- Adding ExceptQ handler (not working yet as own exception is still active)
- Fixed some cppcheck warnings (thanks Andy Willis for that)
- Add some comments for using highmem in some places (currently not used)
- Add writing to PmPrintf queue in parallel to log file when #ifdef __DEBUG_TRACE__
- Use HighMem for copy buffer

Especially the tuning of the copy buffer algorithm makes a big difference in copy speed in so some cases. At least with my rather fast HDDs and SSDs and big files. But also with Samba shares or other source/targets differences can be observed. All my measurements gave good results...
--- End quote ---

Application functionality seems to be spot-on.

File xfer performance wise, here are the results for movement of a test 800M AVI file:

1) from SAMBA share to ramdisk
OLD:  Peak=58,270K, Avg=43,550K
NEW: Peak=56,220K, Avg=46,516K

...so I'm thinking this is more about being network bound (1G LAN, but of course the Samba share box - NAS is the limitation here)

2) from ramdisk to SSD drive (Samsung 860 Evo, SATA)
OLD:  Peak= 82,788K, Avg=  45,545K
NEW: Peak=310,118K, Avg=220,910K

...here I'm thinking there is an OBVIOUS and huge difference! In fact I was floored by how much of a change this was, pretty much maxing out the throughput I would normally see on my DISKIO tests, so I'd say this is an extremely good result Andi!!! Cheers to you sir.

Now, a couple of further remarks as I'm wondering if you would consider looking into these further:

1) NOT an obivous bug, but maybe one???
Opening up a MP4 file causes my MPLAYER app to be started, but because I actually have a CMD that drives it (which accepts a parameter - [Input Scaling Factor] "%*" - that pops up as that INPUT box which allows me to input a scaling factor) the video starts playing, but I notice that the MPLAYER app actually was started twice.

This is why I'm thinking it maybe a bug...and perhaps only dealing with instantiating CMD started apps, because doing the very same thing for PDF files for example opens up a single instance of Lucide.

2) file type specific icons
Let me use the example of JPGs. If these have the icon stored as EA, LCMD pulls these in and shows them. However my NAS does not support EAs, and therefore all of the pics simply show a document icon as opposed to the DEFAULT PMVIEW icon.

This behavious applies to numerous other filetypes as well.

Would it therefore be possible to modify LCMD to use default APP-specific ICONS for particular filetype when the EAs do not have the icon information available?

Once again, thank you for maintaining and enhancing LCMD!!!

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version