Socket Tools by Catalyst & compatibility with Jose' API files

[Marty Francom]

Jose,
   I use Socket Tools by Catalyst and their seems to be conflicts that I am
not able to figure out how to fix.  I ran across this statement and wonder
if you can comment.

"The Catalyst Website talks about NOT linking with the Microsoft WinSock API
routines because of duplicate function names.  It appears that the Jose
Roca's includes use the Microsoft Winsock API and do get included in a
compile with FF 3.5."

http://forums.catalyst.com/viewtopic.php?f=3&t=1463
http://www.catalyst.com/

I only need Socket Tools for the ability to use  FTPS  and HTTPS  file upload and download protochol.
Do you have any suggestion for alternate FTPS and HTTPS tools?

[José Roca]

If you don't want to include WinSock, then add %WIN32_LEAN_AND_MEAN = 1 before any #INCLUDE.

[Marty Francom]

 José,
    Thanks for the suggestion but I am not having much success.
I keep running into conflict type error messages. Try to fix one and
then get a different error message.
    I created a very simple FF35 project that just opens a form.
It just includes the Catalyst SocketTools include files.
    This is asking a lot, but could you take a look and see if the
SocketTools Include can somehow be made compatible with
your API files.  I am at a lost to know what to do.  I am hoping
you can spot a simple solution.
     Attached is the FF35 project and the SocketTools Include files.
And a screen print of the last error message.

[José Roca]

Well, you asked for a way of not including WinSock, based in I don't know which rumours...

Remove %WIN32_Lean_And_Mean = 1 and rem

Code Select Expand


'TYPE SYSTEMTIME
'    wYear AS WORD
'    wMonth AS WORD
'    wDayOfWeek AS WORD
'    wDay AS WORD
'    wHour AS WORD
'    wMinute AS WORD
'    wSecond AS WORD
'    wMilliseconds AS WORD
'END TYPE


in CODEGEN_CTTEST_CSTOOLS7INC_MODULE.inc file.

That's all, folk!

[Mike Stefanik]

We define SYSTEMTIME because it's used in several of our structures and functions. It looks like a fairly simple change we can make with our include file to avoid this issue with yours:

Code Select Expand


#IF NOT %DEF(%SYSTEMTIME_DEFINED)
%SYSTEMTIME_DEFINED = 1
TYPE SYSTEMTIME
    wYear AS WORD
    wMonth AS WORD
    wDayOfWeek AS WORD
    wDay AS WORD
    wHour AS WORD
    wMinute AS WORD
    wSecond AS WORD
    wMilliseconds AS WORD
END TYPE
#ENDIF


[José Roca]

Another solution is to remove it and add #INCLUDE "Win32Api.inc" in your file. The conflict comes because I use explicit alignment in structures, not the default BYTE alignment.

[Mike Stefanik]

For anyone interested, when converting C/C++ headers, you need to be careful when it comes to structure alignment in PowerBASIC because there are some differences. For example, with the SYSTEMTIME structure, in C/C++ it doesn't matter if you use use #pragma pack to set 1, 2, 4 or 8 byte alignment (the default); the structure is always 16 bytes in size. In PB, using those alignment qualifiers produces different sizes (and incompatible alignments). For example:

Code Select Expand


#pragma pack(4)
typedef struct _MYSYSTEMTIME
{
  WORD wYear;
  WORD wMonth;
  WORD wDayOfWeek;
  WORD wDay;
  WORD wHour;
  WORD wMinute;
  WORD wSecond;
  WORD wMilliseconds;
}


The sizeof() that structure is 16 bytes with 4-byte alignment. It would be the same if you used #pragma pack(1) or #pragma pack(8). However, you can't use PB's TYPE member alignment in the same way as #pragma pack, or you'll run into problems. For example:

Code Select Expand


Type MYSYSTEMTIME DWORD
    wYear As WORD
    wMonth As WORD
    wDayofWeek As WORD
    wDay As WORD
    wHour As WORD
    wMinute As WORD
    wSecond As WORD
    wMilliseconds As WORD
End Type 


The size of that structure in PB would be 32, not 16, because it's aligning each member on a 4-byte boundary (what the PB documentation says it will do), but that does not correspond to how #pragma pack actually works in C/C++ where specifying an alignment larger than the natural alignment of a type does not change the type alignment.

Bottom line, you cannot use the #pragma pack directive as an indicator of what qualifier should be used for structure alignment in PB. Unfortunately they work differently, and the two are not compatible. Most structures in the Windows SDK uses #pragma pack(8), with some notable exceptions like the multimedia API, but if you tried to put QWORD modifiers on those TYPE defintions in PB, virtually all of them would be the wrong size. Just something to be aware of.

Edit: And having emoticons enabled in this post made it interesting to read. ;)

[José Roca]

This is why, in my headers, each and every one of the more than 7800 structures that they contain have been checked with the results of M$ C++ compiler.

For example, this one:

Code Select Expand


' // Size = 48 bytes
TYPE GESTUREINFO QWORD FILL   ' Must be 8 byte aligned
   cbSize       AS DWORD    ' UINT // size, in bytes, of this structure (including variable length Args field)
   dwFlags      AS DWORD    ' DWORD // see GF_* flags
   dwID         AS DWORD    ' DWORD // gesture ID, see GID_* defines
   hwndTarget   AS DWORD    ' HWND // handle to window targeted by this gesture
   ptsLocation  AS POINTS   ' POINTS // current location of this gesture
   dwInstanceID AS DWORD    ' DWORD // internally used
   dwSequenceID AS DWORD    ' DWORD // internally used
   ullArguments AS QUAD     ' ULONGLONG // arguments for gestures whose arguments fit in 8 BYTES
   cbExtraArgs  AS DWORD    ' UINT // size, in bytes, of extra arguments, if any, that accompany this gesture
   alignment__  AS DWORD    ' // To keep 8 byte alignment
END TYPE


Must be 8 byte aligned. QWORD FILL does it, but the last (same behaviour than DWORD FILL, by the way). So I have needed to use a filler member at the end.

[Theo Gottwald]

This is why, in my headers, each and every one of the more than 7800 structures that they contain have been checked with the results of M$ C++ compiler.

Jose, Jose this is just unbelievable how much effort you have been putting into this!