WINDOWS CE and platform development
Windows CE is Microsoft's operating system for embedded devices, and embedded devices can be described as a variety of diversified, which requires CE operating system to be customizable, so Microsoft is designed to design Windows CE as a modular operating system. To put it simply, we can imagine Windows CE into a box of building blocks, you can build any objects with blocks, but don't have to use all the blocks.
The object of Windows CE is the platform. It is an operating system subset that adapts to a fixed standard embedded device. The most famous platform is the Pocket PC, which is a platform for handheld a handheld computer without a keyboard. Due to the consistency of platform and hardware, sometimes we also use the name of the platform to call the entire system - the sum of the hardware and the operating system.
We can also develop platforms, developing tools are Microsoft's Platform Builder, Platform Builder's version number is consistent with the version number of Windows CE.
More programmers care about the development of applications, and application development is for specific platforms. We must install the target platform's SDK before developing to develop a development tool for the target platform.
Summary of Windows CE Development Environment
Another confidential concept is a version of the problem. Now you can see two generations of Windows CEs, which are based on Windows CE 3.0 and Windows CE.NET (ie, 4.0), respectively.
Microsoft will collectively known as Windows Mobile 2003 this year, and most of us is still used to use old.
The Pocket PC 2002 that is often seen on the market is a platform based on Windows CE 3.0, and Pocket PC 2003 is a platform based on Windows CE.NET. It should be noted that the kernel of Pocket PC 2003 is Windows CE.NET 4.2. The smartphone2003 is also based on Windows CE.NET. The initial version of SmartPhone is 2002, based on Windows CE 3.0, but Microsoft does not launch the Chinese version of Smartphone2002.
Clear the relationship between the platform and the CE, the relationship between the platform and the development tool is easy. Microsoft is provided to application developers include: Embedded Visual Tools 3.0, including Embedded Visual C 3.0 and Embedded Visual Basic 3.0; Embedded Visual C 4.0 and Visual Studio.Net.
The version number of the development tool is corresponding to the version number of the Windows CE. EVC3.0 and EVB3.0 are used to develop applications based on Windows CE 3.0 platforms, and more common platforms include: Pocket PC 2002, PCKET PC 2000, Palm-size PC, HPC. The EVC4.0 is used to develop a procedure for the Windows CE.NET platform, mainly including Pocket PC 2003 and Smartphone 2003.
Visual Studio.net develops support for embedded devices that require SDE, and SDE includes SDE in VS.NET 2003, which is not required to be installed. The program developed by Visual Studio.net requires the target platform to support .Net Compact Framework. Now supports the platform of the .NET Compact Framework has Pocket PC 2002 and Pocket PC 2003. It should be noted here that Smartphone 2003 is not supported .NET Compact Framework.
EVB development entry
Microsoft has announced that EVB no longer supports Windows CE.NET, so the final version of EVB is 3.0. However, due to the characteristics of EVB's easy-to-hand, it has become a rapidly developed unblocation of the Windows CE platform before VS.NET is shipped. Evb is still suitable for rapid development of small applications on the Windows CE 3.0 platform. If you are not a full-time Windows CE programmer, just need to develop a part of the entire system on the Windows CE platform, then EVB allows you to develop your you want with a short time. EVB's development environment is also very simple, you can download EVT 2002 from Microsoft's website, which contains EVC 3.0, EVB 3.0, and Pocket PC 2002 SDK and Smartphone 2002 SDK. Follow the prompts to install the EVB and Pocket PC 2002 SDK. The SDK contains an emulator. In the case of no actual devices, the simulator can be used to debug the program.
It should be noted here that the development environment and the simulator communicates between the network connection protocol, so there must be an active network connection on the computer used. If not, you can install Microsoft's virtual network card.
The EVB development environment is similar to VB, because the Windows CE application needs to debug on the simulator or actual device, so we must select the output target of the program. If you select emulation, after you press (or F5), the EVB will automatically start the simulator and download the program to the simulator.
Since new Windows CE.NET will no longer support EVB, Microsoft recommends that the EVB programmer uses VB.NET to develop new programs, and for the original EVB program, the migration path is given, about this discussion, you can refer to MSDN article "Moving from Embedded Visual Basic TO Visual Basic .NET".
EVC development
Whether it is a Win32 platform or a WinCe platform, Visual C is a powerful development tool. And EVC is also a mainstream development tool on Wince. The EVC supports the subset of the MFC class library, which provides developers to provide the most powerful support, making the VC programmers on the Win32 platform can easily migrate to the WinCe platform. However, since the MFC class library requires a DLL, this is a big burden for some embedded devices for some storage space, so Smartphone does not support MFC.
Said so much, let us create an EVC project. Is it very similar to VC, you need to remind you that it is necessary to choose the CPU type supported by the project while choosing the CPU type of the embedded device. The process of creating a project is the same. Of course, different platforms support engineering is different, such as Pocket PC 2003 has two projects supporting MFC and APIs, while Smartphone 2003 has only one project that supports API.
The EVC is more than a row of drop-down menu than the VC environment, which is used to select: Engineering, SDK, CPU types, and output devices. Take the Pocket PC as an example, debugging on the actual device should select Win32 (WCE ARMV4) Debug, and on the simulator, Win32 (WCE Emulator) Debug is required.
VS.NET development
I came to our .Net time, how do I say? It's all, everyone is blocked by java and .net? No matter how everyone is noisy, .Net Compact Framework is undoubtedly a big gospel for embedded programmers in their hands. Visual Studio .NET 2003 fully supports the development of mobile devices, well, let us start a fantasy .NET tour. Open vs.net 2003, select File - New - Project, open the above interface. Let us build a Visual C # project, then select Smart Device Application, then OK.
You are here to choose a target device: Pocket PC, Smartphone, Windows CE (referring to other platforms), the following is the selected engine type, we select "Windows Application", the left is the simulator supported by the selected platform. Finally click OK, we can enter the main interface of VS.NET.
Selecting the output device and the EVB is very similar, just select the output device without selecting the CPU type. Of course, because .NET is running on the virtual machine. In the CPU type, there are many embedded fields, .NET and JAVA can truly play their strengths.
Of course, we can also choose VB.NET as the language of the development of smart devices, the situation and C # is exactly the same. At present, smart devices have only support C # and VB.NET. Programmers with hobbies C may have to wait for a while.
Advice developed by Windows CE
It can be said that when we spend most of the time to port existing applications into Microsoft Windows CE. Generally speaking, this plan is not too difficult. We started to Microsoft Win32 code, and of course Windows CE is a Win32 application interface (API). Advantageously, our application (ie RAIMA Data Manager) has a convenient use interface and contains a library consisting of approximately 150 sub-functions, which are written by C language, which can be used to create, manage, and access. database.
According to the way of establishing an application, we originally ported it into Windows CEs and is a relatively simple C language programming practice. However, we have encountered some difficulties soon. Starting from a careless mistake, such as using the Microsoft Windows NT library on Windows NT-based Windows CE emulators, then violate Windows CE programming arms, such as "Don't give Unicode (International Standards Organization 10646 standard) character assignment odd numbers Memory address.
About 90% of the problem is more or less related to Unicode. Although Unicode programming is not difficult, it is easy to make an error when writing code to the single-byte character (I have many mistakes).
The following advice is based on our experience in writing RAIMA Data Manager on Windows CE, but I believe that they are worth learning from any other Windows CE program. After all, most of the Windows developers, when they create the first Windows CE application, truly use the win32 knowledge that has been mastered.
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 * /
Do not put a Unicode string into an odd memory address
On the Intel Series processor, you can store any variables or arrays in a monarch memory address, and will not cause any fatal errors. But in the h / PC, this is not necessarily possible? You must be cautious about the type of data greater than one byte, including Wchar_T defined as unsigned shorts. When you try to access them, placing them in an odd address will result in overflow.
The editor often reminds you on these issues. You can't manage the stack variable address, and the editor will check to determine if these addresses match if these addresses are matched. Similarly, the running time library must ensure that the memory allocated from the stack always satisfies a Word boundary, so you don't have to worry about it. However, if the application contains the code to copy memory area with the memcpy () function, or use some type of pointer arithmetic to determine the memory address, the problem may appear. Consider the following example:
INT sent_name (tchar * pszname) {char * p, * q; int Nlen = (_ tcslen (pszname) 1) * sizeof (tchar); p = maloc (header_size nlen); if (p) {q = p Header_size; _tcscpy ((tchar *) q, pszname);} / * etc * /
This code is allocated from the heap and copy a string, and leaves a header_size size in the beginning of the string. Suppose UNICODE is defined, then the string is a WideChar string. If header_size is an even number, this code will work normally, but if header_size is odd, this code will be wrong because Q Points will be odd.
Note that this problem does not occur when you test this code on the Windows CE emulator in the Intel Series processor.
In this example, just make sure the header_size is an even number, you can avoid problems. However, in some cases you may not do this. For example, if the program is input from a PC, you may have to use the prior defined binary format, although it is not suitable for H / PC. In this case, you must use a function that controls the string instead of the TCHAR pointer with a character pointer. If you know the length of the string, you can replicate the string with a memcpy (). Therefore, the function of using a Byte Analysis Unicode string may be sufficient to determine the length of the string in WideChars.
Translate between ANSI and Unicode strings
If your Windows CE application interface is on the desktop PC, you may have an ANSI string data (for example, a char string) in the PC. This is the fact even if you use the Unicode string in the program. You can't handle an ANSI string on Windows CE because you don't manipulate their library functions. The best solution is to convert the ANSI string into a Unicode string to use the H / PC, and then convert the Unicode string back to the ANSI string to use the PC. In order to complete these conversions, multibyToWideChar () and widechartomultibyte () Win32 API functions can be used.
For Windows CE 1.0 string conversion, cleavage (HACK)
These Win32API functions have not been completed in Windows CE 1.0 versions. So if you want to support CE 1.0 and support CE 2.0, you must use other functions. Convert ANSI string to Unicode strings to use WSPrintf (), where the first parameter uses a WideChar string and knows "% s" (capital) means a string. Since there is no WSSCANF () and WSPrintfa (), you must think of a UNICODE string back into an ANSI string. Since Windows CE 1.0 is not in Country Language Support (NLS), you may have to help Hack, as shown below:
/ * Definition / prototypes of conversion functionsMulti-Byte (ANSI) to WideChar (Unicode) atow () converts from ANSI to widecharwtoa () converts from widechar to ANSI * / # if (_WIN32_WCE> = 101) #define atow (strA, strW , LENW) / MultibyToWideChar (CP_ACP, 0, Stra, -1, Strw, LENW) #define WTOA (Strw, Stra, Lena) / Widechartomutibyte (CP_ACP, 0, STRW, -1, Stra, Lena, Null, Null) # else / * _WIN32_WCE> = 101) * // * MultiByteToWideChar () and WideCharToMultiByte () not supported on Windows CE 1.0 * / int atow (char * strA, wchar_t * strW, int lenW); int wtoa (wchar_t * strW, char * Stra, int LENA); Endif / * _WIN32_WCE> = 101 * / # IF (_WIN32_WCE <101) int Atow (char * stra, wchar_t * strw, int lenw) {int Len; char * pa; wchar_t * pw; / * START with LEN = 1, Not Len = 0, AS String Length Returnedmust Include Null Terminator, As MultibyTetowideChar () * / for (PA = Stra, PW = STRW, LEN = 1; LENW; PA , PW , LENW - , LEN ) {* pw = (lenw == 1)? 0: (wchar_t) (* pa); if (! (* pw)) Break;} returnon;} int WTOA (wxhar_t * strw, char * straigh, INT LENA) {INT LEN Char * Pa; Wchar_T * PW; / * START with LEN = 1, NOT LEN = 0, As String Length Returnedmust Include Null Terminator, As WidechartomultiTE () * / for (PA = stra, Pw = strw, len = 1 Lena; PA , PW , Lena--, LEN ) {PA = (LEN == 1)? 0: (char) (pw); if (! (* pa)) Break;} return;} # ENDIF / * _WIN32_WCE <101 * / This implementation of this implementation of Windows CE 1.0 is easier than using the WSPrintf () function, because using the WSPrintf () function is more difficult to limit the length of the string pointed to by the target pointer.
Select the correct string comparison function
If you want to classify the Unicode standard string, you will have the following functions to choose from:
WCSCMP (), WCSNCMP (), WCSICMP (), WCSNICMP () wcscoll (), wcsncoll (), wcsicoll (), and wcsnicoll () CompareString () The first class function can be used to compare the string, not refer to the local (Locale) or a foreign character. If you never want to support the foreign language, or you just want to test whether the contents of the two strings are the same, this type of function is very easy. The second class function uses the current local settings (system settings, unless you call the WSETLOCALE () function before the string comparison function is before comparing two strings. These functions can also be classified correctly. If the local characters "C" ("C" locale) is selected, these functions have the same function as the first class function.
The third type of function is the Win32 function CompareString (). This function is similar to the second type of function, but it allows you to specify the locale as a parameter instead of using the current local settings. The CompareString () function allows you to selectively specify the length of the two strings. You can set the second parameter to Norm_ignoreCase to make the function compare the string when it is more written.
Typically, even if the second parameter is not set to norm_ignoreCase, the CompareString () function is not used to case sensitive. We often use wcsncoll () functions to case sensitive unless you use local characters "C" ("C" locale). So, in our code, don't use the CompareString () function to case sensitive, and use the wcsncoll () function to case sensitive
Don't use a relative path
Unlike Windows NT, Windows CE does not have the current directory, so any path is just relative to the root directory. If your software uses a relative path to the file or directory, you are likely to move them elsewhere. For example, the path "./ABC" is treated as "/ ABC" in Windows CE.
Remove calls to calloc () and time () functions
The Calloc () function in the C run can not be used, but the malloc () function can replace the Calloc () function. And don't forget, the memory allocated when the calloc () function is initialized, and the malloc () function is different. Similarly, the Time () function cannot be used, but you can use the Win32 function getSystemTime () function instead of the TIME () function.
After the above warning, you will be happy to learn the two advice of the ultimate you surprised.
Do not need to change the call of Win32 input / output (I / O) file
Win32 input and output functions, Windows CE also supports. Allow you to access the object as you visiting the Win32 file system. CreateFile () function does not claim flag file_flag_random_access in Windows CE, but this flag is used only as an optional disk access and does not affect the function called.
Don't worry about the state of bytes
When we write the application to Windows CE, we have a wonderful discovery, which is the same as the byte state of the digital data type of Windows CE, like the INTEL structure, on all processors, Windows CE supports .
Like all database engines, the RAIMA Database Manager saves digital data in binary form in a database file. This means that a record is handled by a series of bytes whenever a series of bytes is written from the database or from the database, regardless of the content of its domain. As long as the database files do not pass any system, the byte status of digital data is solved. If the database file is accessed by a processor from the original system and with a different byte state, digital data will be misunderstood. Whenever you transfer files when you have a file with different processors, you will have this problem. On this issue, it is worthy of all types of processors use the same byte state.
When using Windows CE, these advice should cause you enough attention to avoid learning. This article is from: http://www.biplip.com/default.aspx? Tabid = 34 & Mid = 348 & CTL = view & itemid = 288
