Plugin interface descriptions for TC 7.55 (beta)

[MVV]

Perhaps you can present these folders as virtual files and solve it that way?

You won't be able to browse them in such case.

[white]

Perhaps you can present these folders as virtual files and solve it that way?

You won't be able to browse them in such case.

Might be solved by implementing FsExecuteFile, changing RemoteName to new path and return FS_EXEC_SYMLINK?

Another approach that might work:
Include a virtual file "copy this folder" in each folder. Don't do anything with this file when copied (FsGetFile), but copy the folder when executed (FsExecuteFile).

[MVV]

Have you tried to return FS_EXEC_SYMLINK? How '..' will work for redirected folder?

Search will not work with virtual files anyway...

[white]

Have you tried to return FS_EXEC_SYMLINK?

No, I don't know if it works. Maybe not if I read this.

How '..' will work for redirected folder?

I don't know

Search will not work with virtual files anyway...

Correct.

[MVV]

I've noticed that WCX header file contains definition of callback function type tPkCryptProcW, but there is no definition for function PkSetCryptCallbackW that would pass it.

[ghisler(Author)]

I will check it, thanks.

[MVV]

Another notice and a question.

There are functions in WCX API that pass callbacks. Some of them just pass function pointers:

Code: Select all

PkSetCryptCallback(tPkCryptProc pPkCryptProc,int CryptoNr,int Flags)

(like most other callback setters in W?X interfaces do)

But some pass function pointer and some data pointer:

Code: Select all

SetChangeVolProc(HANDLE hArcData, tChangeVolProc pChangeVolProc1)

(help says that value should be stored somewhere and one you can use hArcData returned by OpenArchive to identify that place)

So does TC pass the same callback pointer for all hArcData values or there may be different callbacks for different archives? I expect that first case is correct because second one looks weird (it implies runtime code generation since there will be no way for TC to detect for which plugin/archive callback is called).

[Vi$oR]

I will consider it - but I think that developpers should be clever enough to install the hlp viewer for Windows 7.

There is no official HLP viewer for Windows 10. It is possible to unpack HLP file and use it in the RTF format, but it is not friendly to the developers.

[Hacker]

Yeah, I also vote for providing the guides in CHM. Do I really have to get some HLP converter just to read the guides under Windows 10?

Roman

[MVV]

I think that much more changes would be required in code than just adding const for some function arguments in case of adding Unicode support... And, these functions are exported by DLL, they don't need to be called from another plugin source file, so no signature matching is required.
The only case when adding Unicode support is just straightforward as you say is when all plugin code uses TCHAR and Windows API for working with strings, and no CRT or STL where ANSI and Unicode require completely different functions and classes. But I don't think that most plugins work like that:)

[Hacker]

Yay!

Roman

[ghisler(Author)]

Btw, I'm still offering a $200 reward for anyone porting an existing plugin (without source) to 64-bit for which there is no 64-bit version yet, or to create a new 32bit+64bit plugin. There is also a $100 reward for recompiling an existing plugin with source to 64-bit.