Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

SDK broken

C

charles_perrin

Nov
11
0
I'm working on a small plugin. At first I couldn't even get my plugin code to compile as the TakeCmd.h file included in the SDK (a freshly downloaded copy) is broken. In line 887 a semicolon is missing. After adding that, my code compiled.

I then added a few more bits and pieces and ran into strange linker errors, for functions GetLine and NthArgument.

After a lot of googling I found that some prototypes in the header file seem to be wrong. After more googling I was able to correct them and I now have a plugin that compiles and, so far, seems to work.

However, the fact that the plugin SDK (or one of the included header files) is so obviously broken is pretty disappointing. Getting a header file to compile is not exactly rocket science, is it?
 
charles_perrin said:
I then added a few more bits and pieces and ran into strange linker errors, for functions GetLine and NthArgument.
Click to expand...
The original (faulty) and revised (working) prototypes (there may be others I have not found):
Code: 
int WINAPI GetLine( HANDLE hFile, LPTSTR pszBuffer, int nMaxSize, int nEditFlag, LPCTSTR lpszMask=NULL );
int WINAPI GetLine( HANDLE hFile, LPTSTR pszBuffer, int nMaxSize, int nEditFlag, LPTSTR lpszMask=NULL );
Code: 
LPTSTR WINAPI NthArgument( LPTSTR pszLine, int nIndex, LPTSTR lpszBuffer, TCHAR **ppNthPtr );
LPCTSTR WINAPI NthArgument( LPCTSTR pszLine, int nIndex, LPTSTR lpszBuffer, TCHAR **ppNthPtr );
Additionally, in line 958 a HCICON is mentioned. Presumably, this should be HICON.
HTH.
 
rconn said:
You appear to be working from an old copy of the SDK - those GetLine and NthArgument prototypes (or for that matter, the functions themselves) haven't been used since v16.
Click to expand...
With respect that's bollocks. Those functions are declared in TakeCmd.h and, more importantly, they are actually in the libraries. If they are officially available, then I can use them?!
rconn said:
From where did you download the SDK?
Click to expand...
I went to https://jpsoft.com/all-downloads/plugins-take-command.html and downloaded the SDK from the obvious link there (on 2015-11-07).

Well, guess what. I just downloaded the SDK again from that very location and it seems that TakeCmd.h has been edited yesterday (by you?) though it still won't compile as it is now. Actually, it wouldn't even compile (see line 882). This is getting ridiculous.

Since the library timestamps are unchanged there's presumably still a mismatch between the TakeCmd*.lib files (32/64) and the declarations in TakeCmd.h. Simply fix those problems instead of talking about old copies lying on JPSoft's own server.
 
charles_perrin said:
With respect that's bollocks. Those functions are declared in TakeCmd.h and, more importantly, they are actually in the libraries. If they are officially available, then I can use them?!
Click to expand...

You *can*, but you wouldn't want to. TCMD v17 was a complete redesign of all of the string handling, so those functions are simply stubs that call the new code. The only reason they're still in there was to avoid breaking old plugins.
 
rconn said:
You *can*, but you wouldn't want to.
Click to expand...
It's always great if someone tells me what I would or wouldn't want to do.

At any rate, your waffling is no excuse for releasing stuff that's so obviously broken. Even "old code" couldn't be made to work with this version of the SDK w/o editing TakeCmd.h.

But hey, it's your product. I've just told you what I think doesn't work and that's it. I'm outta here.
 
I just tonight (11/11) DL'd from the link on the "Downloads ... Plugins" page ... https://jpsoft.com/downloads/sdk/sdk.zip
(That's the only place I could find it, but I didn't look very hard.)

The .H file there (7 Feb 15) seems to be the one the OP is complaining about. I used it in place of a working one. I got the three errors from already mentioned causes ... missing semicolon and HCICON

I also got errors due to missing declarations for PLUGININFO and KEYINFO (but those may have been added to my "good" header by me). After putting them in, I still got many linker errors (because of the "const" business).
Code: 
alert.obj : error LNK2001: unresolved external symbol "int __stdcall Command(wchar_t const *,int)" (?Command@@YGHPB_WH@Z)
bytes.obj : error LNK2001: unresolved external symbol "void __stdcall UnicodeToASCII(wchar_t const *,char *,int)" (?UnicodeToASCII@@YGXPB_WPADH@Z)
bytes.obj : error LNK2001: unresolved external symbol "int __stdcall error(int,wchar_t const *)" (?error@@YGHHPB_W@Z)
clipboard.obj : error LNK2001: unresolved external symbol "int __stdcall QueryIsDirectory(wchar_t const *)" (?QueryIsDirectory@@YGHPB_W@Z)
clipboard.obj : error LNK2001: unresolved external symbol "int __stdcall QueryIsFile(wchar_t const *)" (?QueryIsFile@@YGHPB_W@Z)
crunch.obj : error LNK2001: unresolved external symbol "int __stdcall GetLine(void *,wchar_t *,int,int,wchar_t const *)" (?GetLine@@YGHPAXPA_WHHPB_W@Z)
f_SET.obj : error LNK2001: unresolved external symbol "int __stdcall WildcardComparison(wchar_t const *,wchar_t const *,int,int)" (?WildcardComparison@@YGHPB_W0HH@Z)
grep.obj : error LNK2001: unresolved external symbol "void __stdcall ASCIIToUnicode(char const *,wchar_t *,int)" (?ASCIIToUnicode@@YGXPBDPA_WH@Z)
isusb.obj : error LNK2001: unresolved external symbol "wchar_t * __stdcall QueryTrueName(wchar_t const *,wchar_t *)" (?QueryTrueName@@YGPA_WPB_WPA_W@Z)

FWIW, I've uploaded the one I call "good" and use in all my plugins. Since it's in an old place here, it has almost certainly had some work done by me.
 

Attachments

The .H file there (7 Feb 15) seems to be the one the OP is complaining about.
Click to expand...

I don't know how you downloaded such an old version -- I just downloaded it again and takecmd.h has a date of 11/11/2015 (I had uploaded an updated copy this morning) and none of those missing references.) That version you're referencing is pre-v18 -- are you sure it's the version you just downloaded?

If so, then apparently the sdk.zip file is being cached somewhere between jpsoft.com and you.

(The other places where sdk.zip is located is in each version directory; i.e. https://jpsoft.com/downloads/v18/sdk.zip).
 
My bad! I had sdk.zip (old) and sdk(1).zip (new) on my desktop and I looked at the wrong one. But even when using the 11/11 one, I got all the linker errors coming from the LPTSTR vs. LPCTSTR difference.

But now I'm really at a loss as to how this thing even builds. "Library Directories" specifies "g:\4sdk17;$(LibraryPath)" and Linker\input\additionalDependencies merely includes "takecmd.lib". But g:\4sdk17 doesn't even exist!!!!! Is there a way to find out what takecmd.lib it's actually using? (VS2010)

When I change everything to use the newly DL'd stuff, I still get these:

alert.obj : error LNK2001: unresolved external symbol "wchar_t * __stdcall NthArgument(wchar_t const *,int,wchar_t *,wchar_t * *)" (?NthArgument@@YGPA_WPB_WHPA_WPAPA_W@Z)
crunch.obj : error LNK2001: unresolved external symbol "int __stdcall GetLine(void *,wchar_t *,int,int,wchar_t const *)" (?GetLine@@YGHPAXPA_WHHPB_W@Z)
 
In the one I DL'd tonight, the header says
Code: 
LPTSTR WINAPI NthArgument( LPCTSTR pszLine, int nIndex, LPTSTR lpszBuffer, TCHAR **ppNthPtr );
int WINAPI GetLine( HANDLE hFile, LPTSTR pszBuffer, int nMaxSize, int nEditFlag, LPCTSTR lpszMask=NULL );
while the LIB has
Code: 
?NthArgument@@YGPB_WPB_WHPA_WPAPA_W@Z (wchar_t const * __stdcall NthArgument(wchar_t const *,int,wchar_t *,wchar_t * *))
?GetLine@@YGHPAXPA_WHH1@Z (int __stdcall GetLine(void *,wchar_t *,int,int,wchar_t*))

For NthArgument, the header has it returning LPTSTR while the LIB has it returning LPCTSTR.
For GetLine, the header says the last arg is LPCTSTR while the LIB has LPTSTR.
 
P.S., the LIB I'm using (successfully) is from 2009 (renaming it kills the build)! But I still can't figure out how it's being found!
 
vefatica said:
But now I'm really at a loss as to how this thing even builds. "Library Directories" specifies "g:\4sdk17;$(LibraryPath)" and Linker\input\additionalDependencies merely includes "takecmd.lib". But g:\4sdk17 doesn't even exist!!!!! Is there a way to find out what takecmd.lib it's actually using? (VS2010)
Click to expand...

That's entirely on your end - there's nothing in the SDK that references G: or 4SDK17.
 
vefatica said:
When I change everything to use the newly DL'd stuff, I still get these:

alert.obj : error LNK2001: unresolved external symbol "wchar_t * __stdcall NthArgument(wchar_t const *,int,wchar_t *,wchar_t * *)" (?NthArgument@@YGPA_WPB_WHPA_WPAPA_W@Z)
crunch.obj : error LNK2001: unresolved external symbol "int __stdcall GetLine(void *,wchar_t *,int,int,wchar_t const *)" (?GetLine@@YGHPAXPA_WHHPB_W@Z)
Click to expand...

I've uploaded an updated takecmd.h to fix those two definitions.
 
Is still get this error.
Code: 
alert.obj : error LNK2001: unresolved external symbol "wchar_t * __stdcall NthArgument(wchar_t const *,int,wchar_t *,wchar_t * *)" (?NthArgument@@YGPA_WPB_WHPA_WPAPA_W@Z)
The header and LIB differ in return type (LIB has const).
 
OK, after casting several LPCTSTRs to LPTSTRs. My biggest plugin builds (32/64) using only the latest sdk. And it works with TCCs going back to version 9.

A couple things would make life easier on plugin authors.
1. Put the declarations of the PLUGININFO and KEYINFO structs in TakeCmd.h.
2. Get rid of the declaration of "char TccKeyWords[]", or tell us how to avoid this.
Code: 
alert.obj : error LNK2005: "char * TccKeyWords" (?TccKeyWords@@3PADA) already defined in 4utils.obj
bytes.obj : error LNK2005: "char * TccKeyWords" (?TccKeyWords@@3PADA) already defined in 4utils.obj
clipboard.obj : error LNK2005: "char * TccKeyWords" (?TccKeyWords@@3PADA) already defined in 4utils.obj
cliplines.obj : error LNK2005: "char * TccKeyWords" (?TccKeyWords@@3PADA) already defined in 4utils.obj
clockage.obj : error LNK2005: "char * TccKeyWords" (?TccKeyWords@@3PADA) already defined in 4utils.obj
...
In my case, 4utils.h includes takecmd.h, and every source file includes 4utils.h.

Also, can you include a header and libs for the Oniguruma stuff? I have them but have no idea where they came from
 
_stristr() is also in need of some work. To match the export, the header should say that BOTH its arguments are LPCTSTR. Now, it says
Code: 
LPTSTR WINAPI _stristr( LPTSTR pszStr1, LPCTSTR pszStr2 );
while in the LIB is
Code: 
?_stristr@@YGPA_WPB_W0@Z (wchar_t * __stdcall _stristr(wchar_t const *,wchar_t const *))
 
Would it make sense to add a md5 or sha1 signature of the sdk.zip file on the plugin page along with the download link?
 
You must log in or register to reply here.
Back
Top