Does PB regard .c in API structures as one byte in any case?
Posted: Thu Jun 24, 2010 9:36 am
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]
[in PureBasic]
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.
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;
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
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.