Plugin interface descriptions for TC 7.5 (beta)
Moderators: Hacker, petermad, Stefan2, white
As I know there isn't a compiler switch for that and it's a big flaw I think. But even if there was, when somebody wants to code a unicode plugin and provide the Ansi interface too for the older TC then PChar as general type would be
incorrect. It's like if you use TCHAR* for Ansi functions in C, but you compile it as unicode.
incorrect. It's like if you use TCHAR* for Ansi functions in C, but you compile it as unicode.
Plugins: RamCopy, Transformer Framework
- ghisler(Author)
- Site Admin
- Posts: 50541
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
You mean that Delphi 2009 is Unicode-only now, and cannot create any programs for Win9x/ME any more?
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Basically delphi 2009 is unicode (unlike the previous versions) but it also knows ansi.
To make it easier for you to understand what i was talking about i show you an example:
1. The following 2 TC api functions in earlier versions than Delphi 2009 work like: (here pchar = pansichar by default)
function FsMkDir (RemoteDir: pchar): bool; stdcall; // Ansi declaration in fsplugin.pas
function FsMkDirW (RemoteDir: pwidechar): bool; stdcall; // Wide declaration in fsplugin.pas-ban
function FsMkDir (RemoteDir: pansichar): bool; stdcall; // This is how delphi handles the Ansi declaration
function FsMkDirW (RemoteDir: pwidechar): bool; stdcall; // This is how delphi handles the Wide declaration
2. The situation is the following starting from Delphi 2009: (here pchar = pwidechar by default)
function FsMkDir (RemoteDir: pchar): bool; stdcall; // Ansi declaration in fsplugin.pas
function FsMkDirW (RemoteDir: pwidechar): bool; stdcall; // Wide declaration in fsplugin.pas-ban
function FsMkDir (RemoteDir: pwidechar): bool; stdcall; // This is how delphi 2009 handles the Ansi declaration
function FsMkDirW (RemoteDir: pwidechar): bool; stdcall; // This is how delphi 2009 handles the Wide declaration
So as you see there isn't any problem with the types before delphi 2009, because pchar is pansichar and it works as it's expected.
But from delphi 2009 FSMkDir receives pwidechar in fact (since pchar is pwidechar) so it causes type incompatibility. TC sends pansichar, but receives pwidechar in the RemoteDir parameter
To make it easier for you to understand what i was talking about i show you an example:
1. The following 2 TC api functions in earlier versions than Delphi 2009 work like: (here pchar = pansichar by default)
function FsMkDir (RemoteDir: pchar): bool; stdcall; // Ansi declaration in fsplugin.pas
function FsMkDirW (RemoteDir: pwidechar): bool; stdcall; // Wide declaration in fsplugin.pas-ban
function FsMkDir (RemoteDir: pansichar): bool; stdcall; // This is how delphi handles the Ansi declaration
function FsMkDirW (RemoteDir: pwidechar): bool; stdcall; // This is how delphi handles the Wide declaration
2. The situation is the following starting from Delphi 2009: (here pchar = pwidechar by default)
function FsMkDir (RemoteDir: pchar): bool; stdcall; // Ansi declaration in fsplugin.pas
function FsMkDirW (RemoteDir: pwidechar): bool; stdcall; // Wide declaration in fsplugin.pas-ban
function FsMkDir (RemoteDir: pwidechar): bool; stdcall; // This is how delphi 2009 handles the Ansi declaration
function FsMkDirW (RemoteDir: pwidechar): bool; stdcall; // This is how delphi 2009 handles the Wide declaration
So as you see there isn't any problem with the types before delphi 2009, because pchar is pansichar and it works as it's expected.
But from delphi 2009 FSMkDir receives pwidechar in fact (since pchar is pwidechar) so it causes type incompatibility. TC sends pansichar, but receives pwidechar in the RemoteDir parameter
Plugins: RamCopy, Transformer Framework
Correct - the Embarcadero website states that Delphi 2009 has dropped support for Windows 9x, ME, NT4 - "applications compiled with Delphi 2009 will not work on those versions of Windows".ghisler(Author) wrote:You mean that Delphi 2009 is Unicode-only now, and cannot create any programs for Win9x/ME any more?
- ghisler(Author)
- Site Admin
- Posts: 50541
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
- ghisler(Author)
- Site Admin
- Posts: 50541
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
The official plugin descriptions for TC 7.50 have been available on our plugins page on www.ghisler.com for a while now. Please download them from there:
http://www.ghisler.com/plugins.htm
http://www.ghisler.com/plugins.htm
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
I have questions:
-The wcx documentation doesn't state anything about file extensions. Should we use wcx or uwcx?
ReadHeader is still listed as required, but the Unicode page states "use ReadHeaderEx". Could you clarify?
My plugin exports Unicode versions of all required functions, but I get "this is not a valid plugin".
Do I have to support legacy TC versions?
ADDED:
I found a mistake:
ReadHeaderEx is listed as ANSI-only.
-The wcx documentation doesn't state anything about file extensions. Should we use wcx or uwcx?
ReadHeader is still listed as required, but the Unicode page states "use ReadHeaderEx". Could you clarify?
My plugin exports Unicode versions of all required functions, but I get "this is not a valid plugin".

Do I have to support legacy TC versions?
ADDED:
I found a mistake:
ReadHeaderEx is listed as ANSI-only.
- ghisler(Author)
- Site Admin
- Posts: 50541
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
- uwcx should be used only when there are two separate plugins for ANSI and Unicode. If there is only one plugin, use just WCX.
- You MUST implement the basic ANSI functions which are listed as required. You can return just "no more files" or other error if you are sure that no one with TC 7 or older will want to use the plugin, but the functions must be there.
- Support not, but export them (see reply to your second question). Why? This should prevent crashes of older TC versions installed on the same computer when they load your plugin.
- You MUST implement the basic ANSI functions which are listed as required. You can return just "no more files" or other error if you are sure that no one with TC 7 or older will want to use the plugin, but the functions must be there.
- Support not, but export them (see reply to your second question). Why? This should prevent crashes of older TC versions installed on the same computer when they load your plugin.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
- ghisler(Author)
- Site Admin
- Posts: 50541
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Well, but they could show errors all the time about missing functions, which would be very annoying...
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
In FSPLUGIN.HLP it is said for the CryptProc() function
However if I check the source of webdav_src.zip there are no functions CrpytProc()/FsSetCryptCallback().See the WebDAV plugin sources for an example on how to use these functions.
TC plugins: Autodesk 3ds Max / Inventor / Revit Preview, FileInDir, ImageMetaData (JPG Comment/EXIF/IPTC/XMP), MATLAB MAT-file Viewer, Mover, SetFolderDate, Solid Edge Preview, Zip2Zero and more
- ghisler(Author)
- Site Admin
- Posts: 50541
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Sorry, it seems that I added it only to my SFTP plugin, but not yet to the webDAV plugin. Therefore please check the code of the SFTP plugin instead:
http://ghisler.ch/board/viewtopic.php?t=19994
http://ghisler.ch/board/viewtopic.php?t=19994
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Hello,
there is a mistake in the [face=courier]RequestProcT[/face] implementation (in [face=courier]cunicode.cpp[/face]) leading to a wrong ansi callback function being called; here is an excerpt:
Must be changed to the following in order to have the correct callback function called:
there is a mistake in the [face=courier]RequestProcT[/face] implementation (in [face=courier]cunicode.cpp[/face]) leading to a wrong ansi callback function being called; here is an excerpt:
Code: Select all
BOOL RequestProcT(...)
{
if (RequestProcW) {
...
} else if (LogProc) { // wrong callback
...
}
Code: Select all
BOOL RequestProcT(...)
{
if (RequestProcW) {
...
} else if (RequestProc) { // ok
...
}
- ghisler(Author)
- Site Admin
- Posts: 50541
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact: