[WCP] Accelerator for archives browsing

[Horst.Epp]

There isn't property wcpatcher in dropdown list ...
https://yadi.sk/i/v4ZsvAINXubATw

Same problem here

[remittor]

There isn't property wcpatcher in dropdown list ...
https://yadi.sk/i/v4ZsvAINXubATw

Field "Property" may be empty: Image: https://i.imgur.com/F2W0WaL.jpg

[mikedepetris]

There isn't property wcpatcher in dropdown list ...
https://yadi.sk/i/v4ZsvAINXubATw

I guess you are not using a supported TC version?

[Ovg]

I guess you are not using a supported TC version?

You are wrong, I use TC 9.50 β11 (as stated in my signature) with plugin v 0.6

[Horst.Epp]

I guess you are not using a supported TC version?

You are wrong, I use TC 9.50 β11 (as stated in my signature) with plugin v 0.6

I also use TC 9.50 β11 as one can see in my signature.
The property if definitely empty.

[mikedepetris]

Yes I had a try installing and configuring as Admin, putting it as the first content plugin, nothing works in 9.50B11 x64 and 32 bit

[remittor]

Yes I had a try installing and configuring as Admin, putting iot as the first contect plugin, nothing works in 9.50B11 x64 and 32 bit

For viewing log use DbgView++
Also may try increase log level via INI-file.

[ghisler(Author)]

I don't recommend that you use this plugin for general use: While the plugin speeds up the opening of the archive, the list of all files created by TC is also needed in other places, e.g. when unpacking entire subdirectories. I have optimized the reading of the linear list in beta 12, so it should be considerably faster (although not as fast as this plugin, this would require a lot of internal changes).

[remittor]

... the list of all files created by TC is also needed in other places, e.g. when unpacking entire subdirectories.

WCP-plugin does not change the list of all files created by TC.
The plugin only replaces this list for a short time, when a list of elements is formed for display on the panel.
This replacement has no effect on the unpacking process!
Even the process of adding and removing is not affected, but the visual glitches are stunning.

[remittor]

I have optimized the reading of the linear list in beta 12, so it should be considerably faster (although not as fast as this plugin, this would require a lot of internal changes).

Test results for TotalCmd 9.50b12 32-bit (test conditions are the same):

Code: Select all

  Old algo  |   New algo  |  WCP-plugin |  items |  comment/directory
------------|-------------|-------------|--------|--------------------------
46527.07 ms | 18235.67 ms |  3958.95 ms | 506900 |  file collection building
 4615.79 ms |   298.40 ms |     0.17 ms |      1 |  [root dir]
 4830.28 ms |    40.43 ms |     3.11 ms |    130 |  [AP\kernel\kernel]
 5653.89 ms |   321.66 ms |     4.66 ms |    188 |  [AP\external]

The increase in speed is impressive! Bravo!

But you can increase the speed by another 30% by using the StrCmpIW function!

[remittor]

Addon for imgcfg.ini for support 9.50b12a

; TotalCmd 9.50b12a 32-bit
[2020-01-10]
g_WcxItemList=0x7C1D50
WcxProcessor=0x694E3C
WcxProcessor_loop_end=0x69678E
TcCreateFileInfo_dd=0x695F78
tc_wcsicmp=0x780A04

; TotalCmd 9.50b12a 64-bit
[2020-01-10-x64]
g_WcxItemList=0xC79490
WcxProcessor=0x527260
WcxProcessor_loop_end=0x5297E2
TcCreateFileInfo_dd=0x528BC7
tc_wcsicmp=0x41F9C0

[ghisler(Author)]

2remittor
Thanks for the tests with beta 12!
I'm reluctant to use StrCmpIW because I don't know what it does internally. For example, it might return "identical" for some strings, e.g. one user had the problem that StrCmpLogicalW returns identical for strings starting with a dash and string without, e.g. "-test.txt" and "test.txt".

I tried to implement a tree for just the directories, but it was very slow. How do you store directories within a directory? Do you use a balanced tree for that too? I only tried with a linear list.

[remittor]

I'm reluctant to use StrCmpIW because I don't know what it does internally.

Function StrCmpIW logically performs the same as your function tc_wcsicmp.

shlwapi.dll@StrCmpIW from disasm

Code: Select all

int __stdcall StrCmpIW(LPCWSTR psz1, LPCWSTR psz2)
{
  return CompareStringW(GetThreadLocale(), NORM_IGNORECASE, psz1, -1, psz2, -1) - CSTR_EQUAL;
}

StrCmpIW from ReactOS

Code: Select all

int __stdcall StrCmpIW(LPCWSTR psz1, LPCWSTR psz2)
{
  return wine_compare_string(NORM_IGNORECASE, psz1, strlenW(psz1), psz2, strlenW(psz2));
}

https://github.com/mirror/reactos/blob/master/reactos/dll/win32/kernel32/winnls/string/sortkey.c#L335

For example, it might return "identical" for some strings, e.g. one user had the problem that StrCmpLogicalW returns identical for strings starting with a dash and string without, e.g. "-test.txt" and "test.txt".

Function StrCmpLogicalW works differently: https://docs.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-strcmplogicalw

I tried to implement a tree for just the directories, but it was very slow. How do you store directories within a directory?

See: https://www.ghisler.ch/board/viewtopic.php?f=14&t=54681&p=367899#p367899
See methods: find_directory, get_next.

I am currently working on porting this code to the PAXZ-plugin. And it became clear that need to implement a recursive version of the function get_next, so that can get a complete list of all the elements.

TREE-like structures for PAXZ wcx-plugin

Do you use a balanced tree for that too? I only tried with a linear list.

Balanced trees are not needed at all.
And without this, the search is very fast, because the hash of the name is used: https://github.com/remittor/wcpatcher/blob/935fe73c025ec03497c9fc51ad165b10d92102c6/src/wcp_filetree.cpp#L121-L154

[remittor]

2ghisler
Today I added unnecessary functions to WCP-plugin. But they will be needed in the WCX-plugins (PAXZ).

get_path: Constructs the full path to the specified element. To do this, build the entire branch, starting from the root.

get_next: Enumeration of all elements starting from the specified dir (in this case, it is possible to limit the depth). class TTreeEnum

[dindog]

impressive! what WCP stand for, by the way, never heard of it before.