Win CE Development Advice [1]
Do not use Windows NT libraries on the emulator
The first mistake discussed here is too stupid, but I still can't fall in, maybe you will. When you create a Windows CE program with Microsoft VC (version 5.0), you will find that the path (INCLUDE), library path (library), and executable path are automatically adjusted to match the choice of response target environment. Therefore, if you establish an application for the Windows CE emulator, you will find that the include path does not point to the win32 containing files (in the VC directory), but point to the Windows CE containing files (in the WCE directory). Don't modify it.
Since the Windows CE is running under Windows NT, the program running on the emulator can call the function in any Windows NT Dynamic Link Library (DLL), even if this DLL is not a member of the simulator. Obviously, this is not a good thing, because the same function may not be available on the handheld PC (H / PC) or Windows CE device, and your software is ultimately running on these devices.
When you load a non-Unicode application into the Windows CE emulator, you will find that many functions that are being used are not supported, such as the Character Functions defined by the National Standards Association (ANSI). This may encourage you to link the Windows NT running time library so that you can solve all the problems.
If you are programming with Windows CE, you can use the file and library files that you can use. The answer is that you don't use those containing files and library files used when writing a normal WIN32 or non-Windows CE program.
Don't confuse Tchars and Bytes
If you are writing non-Unicode applications on Windows CE, you might want to convert all strings from a single character (CHARS) (for example, C variable type WHCAR_T). Almost all WIN32 and runtime library functions supported by Windows CEs require wide character variables. Windows 95 does not support Unicode, however, in order to make the program code have portability, you must use the TCHAR type defined in tchar.h as much as possible, do not use WCHAR_T directly.
TCHAR is defined as WCHAR_T or CHAR, depending on whether the symbol Unicode of the preprocessor is defined. Similarly, all macros related to string processing functions, such as _tcsncpy macros, which are defined as Unicode functions WCSNCPY or defined as an ANSI function Strncpy, depending on whether Unicode is defined.
In existing Windows applications, some code may hint the character length is single byte. This is often used when allocating memory giving string, for example:
INT myfunc (char * p) {char * pszfilename;
PSZFilename = malloc (MaxFilelen); if (PSZFileName) Strncpy (PSZFilename, P, MaxFilelen); / * etc * /
In this code, the allocated memory block should be written (MAXFILEN * SIZEOF (CHAR), but most of the programmers like to simplify it to maxfilelen, because for all platforms, the value of SIZEOF (Char) is equal to 1. However, when you replace multiple characters with TChars, it is easy to forget this inherent concept, so write the code into the following form:
INT myfunc (tchar * p) {tchar * pszfilename;
PSZFileName = (Tchar *) Malloc (pszfilename) TCSNCPY (PSZFileName, P, MaxFilelen); / * etc * /
This is not. It will lead to an error. The error here is that the specified variable size in the malloc function is BYTES, but the third variable used in the _tcsncpy function is specified as TCHARS instead of bytes. When Unicode is defined, a TCHAR is equal to two bytes (bytes).
The above code segment should be rewritten as:
INT myfunc (tchar * p) {tchar * pszfilename;
PSZFileName = (Tchar *) Malloc (Maxfilelen * Sizeof (Tchar)); if (pszfilename) TCSNCPY (PSZFileName, P, MaxFilelen); / * etc * /
- Reprinted from blue ideal digital station
