Does PB regard .c in API structures as one byte in any case?

[clover]

I was confused about it for a long time.

Sometimes I need to compile my code in unicode mode. Generally, I found there are two kinds of declaration concerned with string in API structures, e.g.

[prototype with C from MSDN]

Code: Select all

typedef struct _WIN32_FIND_DATA { // wfd 
    DWORD dwFileAttributes; 
    FILETIME ftCreationTime; 
    FILETIME ftLastAccessTime; 
    FILETIME ftLastWriteTime; 
    DWORD    nFileSizeHigh; 
    DWORD    nFileSizeLow; 
    DWORD    dwReserved0; 
    DWORD    dwReserved1; 
    TCHAR    cFileName[ MAX_PATH ]; 
    TCHAR    cAlternateFileName[ 14 ]; 
} WIN32_FIND_DATA; 

Code: Select all

typedef struct { 
    WORD    wMid; 
    WORD    wPid; 
    MMVERSION vDriverVersion; 
    CHAR    szPname[MAXPNAMELEN]; 
    DWORD   fdwSupport; 
    DWORD   cDestinations; 
} MIXERCAPS; 

[in PureBasic]

Code: Select all

Structure WIN32_FIND_DATA
    dwFileAttributes.l
    ftCreationTime.FILETIME
    ftLastAccessTime.FILETIME
    ftLastWriteTime.FILETIME
    nFileSizeHigh.l
    nFileSizeLow.l
    dwReserved0.l
    dwReserved1.l
    cFileName.c[260]
    cAlternate.c[14]
    PB_Alignment.b[2]
EndStructure

Code: Select all

Structure MIXERCAPS
    wMid.w
    wPid.w
    vDriverVersion.l
    szPname.c[32]
    fdwSupport.l
    cDestinations.l
EndStructure

As is known to all, "TCHAR" stands for 16-bit in unicode and 8-bit otherwise while "CHAR" is 8-bit in any case, but in PB they are all declared as ".c". So when in unicode mode, TCHAR works well but CHAR is regarded as 16-bit by PB, when this structure is passed to Windows, error occurs.

But according to my debug, the answer is not! It seems as if PB deals .c in its structures as 8-bit despite it's unicode mode or not. But I'm not sure about it. So I want to know the truth.

[srod]

Code: Select all

Structure test
  a.c[10]
EndStructure

Debug SizeOf(TEST)

The above code outputs 10 in Ascii mode and 20 in Unicode mode, confirming that indeed .c is 8 bits wide in Ascii and 16 bits in Unicode. Your debug test must have been flawed.

For TCHAR, use .c (or a fixed length string). For CHAR use .b or .a as you see fit.

[Demivec]

Using the following, it shows the structure is sized correctly for each respective mode.

Code: Select all

Debug SizeOf(WIN32_FIND_DATA) ; =320 (non-unicode mode), =592 (unicode mode)

The difference in size is due to the 274 elements of '.c' type being twice as wide in unicode mode.

[Josh]

be carefully. you can get problems with translated c-structures. you have to compare the size of the c-structure with the size of the pb-structure. if there are differences, you have to pad the pb-structure at the correct places. sadly pb-structures are not automatic compatible to c-structures. see here