CSE 898 Master's Project Report

Michigan State University

August 25, 1999

Abstract - Mobile computing has gained momentum and grown rapidly in recent years. Portable computing devices such as notebooks, palmtops, and handheld devices are readily available and are becoming quite common. Some devices have an embedded, proprietary operating system (OS), while other devices have an embedded, commercially available OS allowing different models to have the same base OS. Provided that development tools exist, developers should find porting an application to a different device using the same OS far easier than to one using a completely different OS.

In this project report, I will first review the growth of mobile computing and how that has affected the evolution of H/PCs and Windows CE. Next, I will discuss the software development products that were explored, plus my target platforms and environments. I will then focus on the paths and pitfalls of development that I discovered during the course of this exploration. Lastly, I will go over the software that I developed, my recommended changes for the Windows CE Software Development Kits (SDKs), and future work for this project. The reader is expected to be familiar with Win32 software development, with mobile computing devices, and with Winsock software development. Detailed descriptions of each software development package, and the target H/PC devices are beyond the scope of this paper, but can be found in the corresponding references.

In this project report, I will first review the growth of mobile computing and how that has affected the evolution of H/PCs and Windows CE. Next, I will discuss the software development products that were explored, plus my target platforms and environments. I will then focus on the paths and pitfalls of development that I discovered during the course of this exploration. Lastly, I will go over the software that I developed, my recommended changes for the Windows CE Software Development Kits (SDKs), and future work for this project.

In 1990, the first notebook computers were introduced. These machines were primarily used as secondary tools for traveling or for taking work home [6]. Now many people use their mobile computer as their primary and only machine in the office, and many work places encourage the use of mobile computers. In 1998, 20 percent of all personal computers installed were mobile or portable computers. The sales of portable computers increased by 24.6 percent from 1996 to 1997, while desktop computer sales increased by 14.6 percent over the same period. The annual growth rate for portables through 2001 has been forecast at 16.2 percent by International Data Corporation [6]. This steady growth has sometimes been attributed in part to the growth of the Internet and E-Business [7]. Both consumers and businesses have an interest in anytime anywhere computing and Internet access. The growth in mobile computing and the change in consumer computing needs have led companies such as Microsoft to reevaluate their development strategy. The old mantra for many computer-related companies was "a computer in every home and on every desktop". The focus is changing to include wireless computing and Internet-oriented applications [8].

Researchers soon recognized that traditional operating system designs assumed a static system, and were inadequate to handle the unique events encountered in the mobile computing environment [5,9,10]. The consumer desire for easy mobility causes a compromise between lighter, smaller devices and available system resources. Mobile devices have lower power, slower processors, smaller storage capacity and a smaller area for user input than their static cousins. Although a long battery life is desirable for mobile use, much of the total weight is the battery. Thus, a manufacturer faces a trade-off between either a larger battery that makes the weight inconvenient, or a lighter device that needs to be recharged more frequently. Since hard drives are relatively heavy and need a large amount of power, a device may opt for RAM and ROM chips that have less storage capacity. In addition, the OS for a mobile device also faces different network and security situations than those faced by a traditional OS.

Much work has been done evaluating and investigating solutions to various mobile OS topics, such as security [11], network [12], wireless operation [13,14], adaptive OS [15], and adaptive applications [16]. The uniqueness of this research prompted the ACM and IEEE to create a separate Mobile Computing and Networking Conference in 1994. This annual conference continues to grow and attract new research [17].

Commercial vendors and developers also looked at changes needed to create an OS that could handle the constraints of the resource poor embedded devices. Microsoft's answer was Windows CE.

Windows CE 1.0 was first unveiled at Comdex 1996 [18]. The first generation Windows CE devices, and all later generation devices to date, are PC companions meaning they are designed to exchange and synchronize data with a desktop computer [19]. Windows CE 1.0 includes a suite of applications, and both the OS and applications are embedded in the device's ROM. While documents and other programs may be downloaded and used on the device, in the event of power-loss, only the original OS and applications are in permanent storage. Although it has the same look and feel, Windows CE is not a ported version of Window 95. Windows CE was designed from the ground up to work with resource poor mobile devices [19, 20, 21].

Windows CE is a small, scalable, 32-bit Windows-compatible OS intended to work on a wide range of embedded devices with variable user input methods. It supports the Win32 programming model, and exports a subset of the Win32 API. Windows CE is targeted at small systems with limited memory. To enable accommodating variation in hardware and software features, Windows CE is modular. Thus, a vendor may only include the needed parts of the OS [19]. This results in a separate SDK for each platform.

Windows CE 1.0 supports the Philips, the NEC MIPS, and the Hitachi SH3 processors, and it supports a monochrome 480 X 240 screen size. Windows CE 1.0 provides a nice assortment of embedded applications such as Information Manager, which includes Calendar, and Tasks and Contacts, which can automatically synchronize with Microsoft Schedule+ 7.0a. In addition, Pocket Word, Pocket Excel, Pocket Internet Explorer and an Inbox for email are provided. Figure 1 shows a screen shot of Windows CE 1.0 [19]. Although the devices rely on a serial cable to synchronize with their host desktop computer, Windows CE 1.0 includes remote dial-up supporting TCP/IP and PPP protocols. These devices have 4 MB to 8 MB of on-device ROM, and from 2 MB to 4 MB RAM [19].

Figure 1: Screen Shot of Windows CE 1.0 [19]

Initially, Windows CE 1.0 devices were met with excitement and high expectation. However, by mid-1997, a common reaction seemed to be that these devices were too slow, the screens were too small and there was not sufficient memory. At a Microsoft Windows CE conference in May 1997, Microsoft announced its plans for Windows CE 2.0, which was formally announced to the public in September 1997 at the Embedded Systems Conference in San Jose [18].

Some of the improvements in Windows CE 2.0 are support for 256 color, support of 640 X 240 screen size, support for direct printing, cascading menus, support for microphones, and improved Pocket applications. In addition, Pocket PowerPoint and Pocket Outlook have been added. Pocket Internet Explorer has been integrated with the Explorer shell. Synchronization with the desktop computer has been improved with Windows CE Services, which handles document transferal and conversion between the different operating systems and different versions of an application, e.g. Pocket Word to Microsoft Word. Windows CE 2.0 also supports Ethernet LAN, SLIP protocol for wireless Cellular Digital Packet Data (CDPD), and built-in modems. These devices have from 8 MB to 16 MB RAM [22, 23].

In 1998, Microsoft announced Windows CE, Handheld PC Edition Version 3.0 having the Core OS System Version 2.11. Windows CE 2.11 or the H/PC Pro Edition includes Pocket Access, which includes ActiveX Data Objects (ADO) allowing synchronization with ADO-based databases on desktop or network servers. Improvements were made in the existing Pocket applications, plus color displays of 640 X 480, or 800 X 600 are supported. Processor support has been increased. In addition to the NEC MIPS and the Hitachi SH3 processors, Windows CE 2.11 also supports the Hitachi SH4 and the StrongArm 1100 processors. Communication support has been increased to included CompactFlash Type II, PCMCIA, and infrared (IrDA standard) protocols. The H/PC Pro Edition includes support for wired and wireless Ethernet adapters, parallel ports, fast infrared (Fast IR) and Universal Serial Bus (USB). These devices have 16 MB of on-device ROM, and from 16 MB to 32 MB RAM [24].

Two new releases of Windows CE are forthcoming from Microsoft - Windows CE 2.12 and Windows CE 3.0. An amusing but accurate observation is that "the only Microsoft product that seems to have been updated faster than Microsoft Internet Explorer is Windows CE" [25].

Windows CE 2.12 is an update to Windows CE 2.11 and should be released soon. Some of the expected changes include added security features to prevent the loading of untrusted DLLs and OEM modules. The shell is being improved, and a second, more powerful web browser is being added. The notification subsystem is being redesigned, although the former functions will be maintained for compatibility [25].

Windows CE 3.0 is codenamed Cedar and is a major version change. The scheduler is being redesigned to allow much improved real-time support. Nested interrupts will be supported and the number of thread priority levels is being increased. Four new thread functions will be added to support these changes. This version includes the features of the previous Windows CE versions plus the improvements of Windows CE 2.12. Windows CE 3.0 is expected to add TAPI and support incoming calls, in addition to the Simple Network Management Protocol (SNMP). An HTTP server component will be added, that will include both basic and NTLM client authentication support. In-process and out-of-process COM objects will be supported with all threading models. Windows CE 3.0 will implement a version of Microsoft Message Queue Service (MSMQ) to support distributed applications. Changes to the file system include increasing the object store from 16 MB to 256 MB. The database API is adding features to create, open and seek databases. The accessibility functions are being added back to the graphics API. A pre-release of Windows CE 3.0 is expected soon, but will not likely have all of the intended changes. Windows CE 3.0 will continue to be a modular OS. If the memory requirements of the new features are too high, a vendor does not need to include them on their version of Windows CE 3.0 [25].

Using the Microsoft Windows CE Platform Builder, Windows CE can be compiled for a wide range of embedded system devices. The modular design of the OS allows a developer to select what to include. After generating the custom Windows CE OS, the Platform Builder can create an SDK to support software development. Despite the ability for Windows CE to be compiled for existing devices, the development of Windows CE was paralleled by the development of new embedded system devices, designed around Windows CE specifications and abilities [18].

The new devices, Handheld Personal Computers (H/PCs), also called PC Companions, were aimed at the niche between a Personal Digital Assistant (PDA) and a notebook computer. The H/PCs were designed to be lighter, smaller, and less costly than a notebook computer, yet still have more powerful applications and more sophisticated connectivity than a PDA [26]. Figure 2 shows an image of a typical Windows CE 1.0 H/PC [19]. The actual size of the device is approximately 7 inches long, 4 inches deep and 1 inch thick when closed.

Figure 2: Image of a Typical Windows CE 1.0 H/PC [19]

NEC, Philips, LG Electronics, Casio and Hewlett Packard (HP) were the original licensed vendors producing new Windows CE devices. When Windows CE 1.0 was unveiled in 1996, only the NEC MobilePro 200 and the Casio A-10 were shipping [18]. The Casio and NEC models followed the strict Microsoft specifications, resulting in little difference between them [27, 28]. Philips and HP released Windows CE 1.0 devices in 1997, and both varied from the Microsoft specifications to include additional features [18, 26, 29, 30]. Casio responded by introducing the A-11 [28], and NEC also improved its product line releasing the MobilePro 400 and MobilePro 450 [27]. Table 1 shows a comparison chart of these devices.

Table 1: Comparison of Some Windows CE 1.0 H/PCs

An interesting side note is that, prior to Windows CE, HP released the HP 200LX that used MS DOS 5.0 as its OS. This device had a CGA compatible 640 X 240 display and included Pocket Quicken and Lotus 1-2-3 release 2.4 [31].

When Windows CE 2.0 was released in 1997, NEC, Casio, Philips, HP and LG Electronics announced new hardware. Other vendors such as Sharp also joined the Windows CE group and produced new Windows CE devices. Casio released the A-20, and introduced the Casio Cassiopeia E-10, a Palm-Size Personal Companion (PPC) [32]. Philips produced the Velo 500 [33, 34], and NEC unveiled two Windows CE 2.0 devices, the MobilePro 700 and the MobilePro 750c [34, 35, 36]. HP first released the HP 340LX and the HP 360LX [30], and later produced the HP 620LX Palmtop PC and HP 660LX Palmtop PC [55]. Sharp introduced the Mobilon HC-4100 and Mobilon HC-4500, followed by the Mobilon HC-4600 [34, 37]. Table 2 presents a comparison chart of these devices.

Table 2: Comparison of Some Windows CE 2.0 H/PCs

Prior to the release of Windows CE 2.0 devices, consumer interest in Windows CE devices seemed to be faltering. This trend changed with the release of H/PC devices with larger, color screens and more memory, coupled with a richer OS having new and improved applications. Consumer interest in Windows CE devices increased, and critical opinion of Windows CE devices seemed to improve greatly [18, 38].

Windows CE 2.11, released in fall of 1998, was much anticipated. The new OS improved communications, added applications, and - possibly most importantly - gave vendors much greater design flexibility. The size of Windows CE 2.11 devices can range from small PPCs (Casio Cassiopeia E-105) to medium H/PC Pro's (HP Jornada 680) to large H/PC Pro's (Sharp Mobilon PV-6000). Screen displays can be monochrome or color, and vary from 480 X 240, to 640 X 240, to 640 X 480, to 800 X 600 [39]. NEC, Casio, HP, LG Electronics and Sharp were joined by Compaq, Everex, Fujitsu, Hitachi, NTS Computer Systems, Samsung and Vadem in producing Windows CE 2.11 devices [39]. Philips has not yet produced new hardware using the new OS [33]. Casio has not produced H/PC Pro hardware, but has gone with PPC devices continuing with the Cassiopeia line [40]. In late 1998, HP unveiled the HP Jornada 820. Geared towards traveling business people, the Jornada 820 feels like a mini-notebook computer [53]. HP later added to its Windows CE 2.11 devices with the introduction of the Jornada 420, a PPC, and the Jornada 680, a mid-size H/PC Pro [41, 42]. In early 1999, NEC released the MobilePro 770 [43], and later released the MobilePro 800, which is a large size H/PC Pro device [44]. Sharp produced the Mobilon PV-5000 followed by the Mobilon PV-6000, which are both are large size H/PC Pro devices. Thus far, all H/PC and H/PC Pro devices have been a clam shell design. The Mobilon PV-6000 introduced a new easel design that allows it to have one of the largest screens at 9.4", but also makes it one of the heaviest devices at 3.2 pounds [45]. Table 3 presents a comparison chart of these devices.

Table 3: Comparison of Some Windows CE 2.11 H/PC Pro's

If Windows CE 2.0 devices favorably changed the growth of Windows CE, then Windows CE 2.11 Palm-Size Personal Companions (PPCs) and H/PC Pro devices caused it to soar. The advantages of the medium and large size H/PC Pro devices over conventional portable computers are smaller size, lighter weight, instant power-on, longer battery life and better durability due to far fewer moving parts [39]. Although Windows CE PPCs are competing against an older, strong PDA market, a recent PC Magazine review states that PPCs, such as the Cassiopeia, are easier to use and have better applications [46]. Businesses that do much of their work in a mobile setting, such as the healthcare industry, have long looked at the use and benefit of PDAs and electronic devices. In 1997, the Visiting Nursing Association of NY purchased 1400 Fujitsu pen tablets for its home healthcare nurses to input patient demographics and procedures. While the medical profession is beginning to use and rely on these devices, a common opinion seems to be that such devices take too long to learn and proprietary operating systems are costly to build and maintain. The arrival of the Windows CE OS and Windows CE devices presented big advantages to businesses. Training time is reduced since users have a familiar Windows desktop and applications. The H/PC allows a user to make notes, make appointments, and update records away from their desk, and later easily synchronize this information with their desktop computer via Windows CE Services. Documents created with Microsoft desktop products can also be converted via Windows CE Services and used in Windows CE Pocket applications [47]. These advantages have caused businesses, such as the healthcare industry, to shift to Windows CE devices. In 1998, Physix, Inc. introduced PocketChart, a Windows CE virtual charting application, that allows users to update charts, document treatment plans, and send prescriptions to the pharmacy. Physicians take the H/PC devices on their rounds and upload the new information to the primary computer later [47, 48]. In 1999, the Stanford University Cardiology faculty announced that they are developing Windows CE applications to be used for entry and reporting of patient data and test results, and are incorporating the use of Microsoft Access databases. They are also working on wireless communication of patient monitoring information, such as ECG data, to the host computer and Windows CE devices [49].

Although Windows CE 2.12 and Windows CE 2.0 have been announced by Microsoft, at the time of this paper no new Windows CE devices for these OS's have been announced by vendors.

Windows CE was chosen as the target environment for this project. Four software development packages were considered for evaluation. These software packages are Microsoft products.

Both the Windows CE Toolkit for Visual C++ 5.0 and the Windows CE Toolkit for Visual J++ 1.1 were released as part of the July 1998 MSDN distribution. Optionally, one could have purchased these packages from a reseller. A computer running Windows NT 4.0, Service Pack 3 is the required OS and development platform. The development platform used for this project is a 200 MHz Pentium with MMX and 96 MB RAM, running Windows NT 4.0 at SP 4.0. Both Toolkits were designed to be installed as add-ons to Microsoft Visual Studio 97, Professional or Enterprise versions. One could also add these Toolkit packages to the Professional or Enterprise versions of, respectively, Microsoft Visual C++ 5.0 or Microsoft Visual J++ 1.1. Thus, either Visual Studio or the appropriate programming language had to be installed prior to Windows CE Toolkit installation. I used Visual Studio 97 Professional, and added Service Pack 3 for that product prior to Toolkit installation. Windows CE 1.0 and Windows CE 1.01 are supported directly by this Toolkit, plus cross-compilers are provided that support the following processors: NEC MIPS and Hitachi SH3. Windows CE 2.0 support could be added by obtaining and installing a free download, Microsoft Windows CE Platform SDK, Handheld PC Edition, Version 2.0.

After installation of the above software, all three versions of Windows CE were supported from within either Visual C++ 5.0 or Visual J++ 1.1. A developer simply chooses to create a WCE application, selects which platforms to include and clicks 'OK' to create the application. After the application workspace is created, the Windows CE version may be easily selected and changed from the workspace menu. Likewise, the target platform or processor may be easily selected and changed from the menu, provided that the platform was included when the WCE application was created. Both Toolkits also provide an emulator to allow the WCE application to be run on the desktop development computer in place of a real Windows CE device.

These two Toolkits were only investigated briefly at the beginning. Since the primary target platform, the HP Jornada 820, was not supported by these toolkits, work did not continue with these Toolkits.

Although the release of this product was briefly advertised on the Microsoft web site, in March of 1999 only a picture of the product could be found on the Windows CE developers web site. In April of 1999, the Windows CE Toolkit for Visual J++ disappeared from the Microsoft products list, and the picture was removed. This may have coincided with various court cases in which Microsoft was then involved. Microsoft Visual J++ 6.0 is still sold by Microsoft [50]. However, all current searches on the Microsoft web site for the Windows CE Toolkit for Visual J++ direct the user either to the Windows CE Toolkit for Visual C++ 6.0 or to the Windows CE Toolkit for Visual Basic. These are now the only two Windows CE Toolkits discussed on the Windows CE web site [51, 52]. Hence, the Visual J++ toolkit and the Java language were not included in my project.

The Windows CE Toolkit for Visual C++ 6.0 was first released as a beta in October 1998. This product was the first Windows CE Toolkit to support the ARM processor and the HP Jornada 820. I used the beta, until the Toolkit was released in March 1999. At that time, the released Toolkit was only available from resellers, but has since been released in the MSDN distribution.

Again, a computer running Windows NT 4.0, Service Pack 3 is the required OS and development platform. The development platform used for this project is, once again, a 200 MHz Pentium with MMX and 96 MB RAM, running Windows NT 4.0 at SP 4.0. This Toolkit was designed to be installed as an add-on to Microsoft Visual Studio 6.0, Professional or Enterprise versions. Again, Visual Studio had to be installed prior to the Windows CE Toolkit installation. I used Visual Studio 6.0 Enterprise and added Service Pack 2 for that product prior to installation of this Toolkit. Windows CE 1.0 and Windows CE 1.01 support have been dropped from this Toolkit. The Windows CE Toolkit for Visual C++ 6.0 supports Windows CE 2.0 and 2.01, plus cross-compilers are provided that support the following processors: NEC MIPS, Hitachi SH3, Hitachi SH4, and StrongARM 1100. Although later releases of this Toolkit may include Windows CE 2.11 support, initially support for the H/PC Pro Edition could only be added by obtaining and installing a free download, Handheld PC Professional 3.0 SDK.

After installation of the above software, all three versions of Windows CE were supported from within Visual Studio's Visual C++ 6.0. As with the earlier Toolkits, a developer simply chooses to create a WCE application, selects which platforms to include and clicks 'OK' to create the application. After the application workspace is created, the Windows CE version and the target platform may be easily selected and changed from the workspace menu. The Windows CE Toolkit for Visual C++ 6.0 again provides an emulator to allow the WCE application to be run on the desktop development computer in place of a real Windows CE device. This Toolkit was the primary software development package that was investigated and used for software development.

The Windows CE Toolkit for Visual C++ 6.0 supports five different processors and allows easy cross-compilation of processors and versions of Windows CE. I was able to compile my developed software for all supported Windows CE versions and processors, and tested my software on two actual devices.

The HP Jornada 820 was chosen as the primary platform for software development since it runs the most recent version of Windows CE. The intent was to develop network utilities for Windows CE , and it was felt that Windows CE 2.11 was most likely to support the necessary functions. The HP Jornada 820 used in this project has a 32-bit, 190 MHz StrongArm SA-1100 processor, 16 MB ROM, and 16 MB RAM. The OS is Windows CE 3.0, Core System Version 2.11. User input is done through a keyboard and a touchpad. The display is 640 X 480 X 256 colors, with a built-in VGA-Out port where the external monitor display can be 1024 X 768 X 256 colors. The Jornada 820 has an integrated 56Kbps, v. 90 modem, a USB port, a serial port, a Fast IrDA infrared port plus a built-in speaker and microphone. The rechargeable battery lasts around 10 hours. The Jornada 820 is light, weighing around 2.5 lbs., and it is small with its size being about the same as two CD jewel cases laid side by side [53]. Figure 3 shows an image of a HP Jornada 820 [54].

Figure 3: HP Jornada 820 [54]

The device comes preinstalled with all of the applications previously mentioned with Windows CE 2.11. HP also includes some utilities to configure such settings as the screen brightness, and some communications tools, e.g. HP dialup. However, I found that the standard Windows CE communications tools were easy to use. HP also included a CD-ROM with the latest version of Windows CE Services to allow the Jornada 820 to synchronize with a desktop computer.

Since the development platform had a serial mouse and a modem, I found that getting the synchronization to work between the Jornada 820 and the desktop computer was non-trivial. I suspect that I would have had no problems had the system used a PS/2 mouse. I found that the Jornada 820's synchronization software had to be set to use the serial port COM 1 at a baud rate of 19200. I then set the modem to use COM 3 and the serial mouse to use COM 2. Once the serial port settings were in place, the synchronization using the Windows CE Services worked fine.

A minor problem that bears mentioning is the occasional freeze or hanging of communication between the Jornada 820 and the desktop computer at the initialization of synchronization. When this occurred, simply removing the serial cable from the Jornada 820 momentarily and then reseating it was enough to reset the connection. This could be done while Windows CE Services was attempting to communicate with the Jornada 820 without stopping and restarting Windows CE Services. Reseating the serial cable is actually recommended by HP as a possible fix for this problem.

The HP 620LX Palmtop PC was chosen as the secondary platform for software development, since it was available in-house and runs Windows CE 2.0. Thus, the two platforms will test the ease of cross-compilation for two different processors and two different versions of Windows CE.

The HP 620LX used in this project has a 75 MHz Hitachi SH3 RISC processor, 10 MB ROM, and 16 MB RAM. The OS is Windows CE 2.0. User input is done through a keyboard or a Pen & Touch interface. The display is 640 X 240 X 256 colors. The 620LX has a serial port, and an IrDA infrared port plus a built-in speaker and microphone. The 620LX is very light weighing just over 1 lbs., and it is small with its size being slightly larger than a checkbook. The device comes preinstalled with all of the applications previously mentioned with Windows CE 2.0. HP again includes some utilities and tools [55]. Figure 4 shows an image of a HP 620LX [56].

Figure 4: HP 620LX [56]

Information on Windows CE development is growing. However, when I started this project it was somewhat limited. The first helpful source of information that I found was the Microsoft Windows CE web site for Developers. This provided a checklist on software necessary to develop for platform X using environment Y, overviews of Windows CE versions, white papers on Windows CE architectural designs, technical papers on Windows CE development issues and suggestions on books for developers. Much of the information here is high-level. For example, The Windows CE Communications Model [57] provides a nice architectural overview of communications in Windows CE, but gives no specifics to help figure out why the ICMP functions do not work.

In addition to web help, Microsoft also provided two mailing lists with Windows CE information, The Windows CE Developer News Flash and the Windows CE News Wire. These two lists have since been combined under the Windows CE News Wire. Subscribing to this mailing list is very worthwhile. While the bulk of the announcements are of little interest at least one announcement in every other issue is extremely helpful.

Windows CE newsgroups are available on the Internet news servers, and on the MSDN news server. While both can be helpful, the MSDN newsgroups for developers filter out the non-developer questions and seem to have a more knowledgeable group of developers reading it. In addition, some Microsoft developers occasionally answer or provide insight on various problems. The downside of the MSDN newsgroups is that one must be a MSDN member to read them, although that may no longer be true.

All of the Windows CE Toolkits provide release notes. While reading through them the first time is rather dull, when one hits the first compilation or link error it is a good idea to look through them. Several oddities occur with certain libraries, certain processors, and certain versions of Windows CE . The release notes do help with debugging.

Each SDK also comes with release notes. It is definitely worthwhile to read these. If nothing else, one begins to realize that just because a program does or does not compile for the emulator can have little bearing on whether or not the program will work for a specific platform. One also realizes that differences may exist in the same function used in different versions of Windows CE .

If one has access to the MSDN library, it should be installed on the development platform. The help files that come with Windows CE are tailored to that OS. These help files often provide little or no help on general Win32 functions or procedures.

If one has little or no experience with Win32 programming, the book Programming Microsoft Visual C++ Fifth Edition [58] is a must. I worked through the first six chapters to get a good foundation in Win32 development. This book stresses the use of MFC, which turns out not to be recommended for Windows CE. Still, the book is still very helpful as a Visual C++ programming reference. Another Visual C++ reference is Microsoft Visual C++ 6.0 Programmer's Guide [59]. While lacking in the great examples found in the Kruglinski book, the Zaratian book is somewhat helpful, too.

High-level information on Windows CE can be found in Inside Microsoft Windows CE [21]. This was helpful with getting familiar with what Windows CE is, but provided no help for applications development. The best book and reference for Windows CE application development is Programming Microsoft Windows CE [20]. This book has great examples, clear explanations, good hints on problems to avoid and helpful suggestions. If you are doing Windows CE development, get this book! I worked through chapters 1-5, and 10 to get a good foundation in Windows CE style programming. This book stresses the use of the Win32 API functions, and avoids the use of MFC. The reasons for this will be discussed later. Microsoft Windows CE Programmer's Guide [60] is also a nice programming reference. Early in my project, this book provided the only easily referable and complete list of Windows CE API functions.

Windows Sockets Network Programming [61] provides very solid information on Winsock concepts and programming. I also found a very helpful web site on Winsock and Windows programming, Vijay Mukhi's Technology Cornucopia [62]. This site has simple and clear explanations and examples, and is a worthwhile visit for anyone beginning Winsock programming. Lastly, I found some very helpful public domain or GNU source code, which assisted me greatly with the FTP client. These were dftp written by D. C. Asonye, NcFTP written by M. Gleason, and WS_FTP written by J. A. Junod.

The look and feel of Windows CE software development is very much like Win32 development. The windows and dialog box procedures function the same way, many of the functions have the same name, and the same development interface, Visual Studio, can be used by either development environment. But in reality, Windows CE development is more of a second cousin to Win32, rather than a sibling. They may look and feel the same, but the nitty, gritty details of "how do I get X to happen" can range from slightly to very different. A developer will be much further along assuming that Windows CE development is its own beast to be learned, than assuming they just have to do things a little differently from Win32 development.

The Microsoft Windows CE web site lists the technical paper, Porting Windows 95 Programs to Windows CE [63]. This paper claims that Windows 95 based applications can be ported with less effort than writing from scratch. This may be true at times. I tried porting a Win32 Windows for Workgroups/DOS program, and found I had far less problems just writing the program from scratch. The Porting... paper lists the major porting concerns as follows: understanding the differences between the Win32 API and the WinCE API; understanding the differences between the standard MFC and MFC for Windows CE; memory limitations; energy limitations; varying hardware; and differences in testing.

The WinCE API is smaller than the Win32 API and supports a reduced feature set. For example, fewer windows styles, colors and fonts are supported. The WinCE API has specific extensions to support the varying hardware capabilities of different devices, such as touch screens. While designed to match the functionality of standard MFC, MFC for Windows CE has differences in available classes and supported features. RAM is generally limited on a Windows CE device. A Windows CE application should be written to use as little memory and storage as possible. A Windows CE program should also be written to conserve on energy consumption. Unnecessary computations should be removed, and an application should shut down unneeded features when idle. To best handle hardware differences on various target platforms, an application should be written for the lowest common denominator of functions and features. Testing with the emulator may only be helpful for devices using standard Windows CE. Nonstandard hardware platforms will need another method for application testing [63].

I found most of the information in Porting Windows 95 Programs to Windows CE to be helpful. Several areas are mentioned as potential problems: API functions, MFC, testing and emulation, using Unicode, and communications issues. Although the information is accurate, I found some either misleading or not sufficiently stressed. Specifically, the porting issues occurring with API functions, MFC and Unicode need to be stressed since the resulting problems can be considerable.

MFC is stated to have significant differences between Windows CE and Win32. However, what is not really mentioned is that MFC can automatically pull in various libraries that can cause compilation or linking failures. I found this out via link errors and Windows Knowledge Base articles.

MFC is provided for Windows CE and one can find MFC examples that compile, link and work on a Windows CE device. Nonetheless, my primary programming reference, Programming Microsoft Windows CE, warns against using MFC and encourages using API functions. Boling states that most Windows CE devices do not include the MFC library in their ROM in order to save space. Thus, the MFC and OLE32 DLLs required by a MFC application must be downloaded with the application. Even then, using MFC is problematic. For example, Windows CE 2.0 PPCs do not support MFC. Another consideration is whether the target device will have sufficient RAM to handle an MFC application. An API program is typically smaller, more efficient and has a smaller footprint when running than an MFC program. Since Windows CE devices are resource poor compared to desktop computers, the amount of necessary RAM for an application is a far bigger concern for a Windows CE developer than for a NT developer [20].

Although Microsoft Windows CE Programmer's Guide did not specifically warn against using MFC, I noticed that most of their example code used API functions and not MFC [60]. I took the hint and chose to develop my applications using API functions.

The various SDKs and Toolkits do a reasonable job alerting one to potential difficulties in compiling the same code under different versions of Windows CE. The obvious cause is the change in supported functions and features among the different versions. For example, ICMP functions, which may be used for a 'ping' program, are supported in Windows CE 2.11 but not in Windows CE 2.0.

In Windows CE 2.0, if one wishes to print to the screen and to a log file something like:

one must:

If one wishes to send a command to a socket in early versions of Windows CE , prior to Windows CE 2.11, one must:

This may not seem like a huge problem, but it is a tedious and pervasive process that unnecessarily increases the size of the code. My solution was to write my own, limited sprintf function.

I suspect that fewer problems would occur if a program were first written for an older version of Windows CE and then ported to a newer version. The drawback to this approach would be that a developer may not be able to easily take advantage of features in the newer version.

The Windows CE Toolkits do provide an emulator to allow a WCE application to be run on the desktop development computer in place of a real Windows CE device. This is quite convenient as it allows a developer to test a program on the different versions of Windows CE without having different Windows CE devices. The drawback occurs in the fact that a program is not tested on a real device. Some Microsoft information states that emulator testing is only a problem for applications aimed at nonstandard hardware devices [63]. However, a developer is first alerted to potential problems in the Windows CE Toolkit SDK release notes. The release notes warn that the ability of a program to run on the emulator does not mean it will run on a device X. In addition, successful tests on device X do not guarantee that a program will run on device Y. Problems occur because different devices are using different processors and have different hardware designs. The SDK release notes and the Windows CE help files list many compilation and link errors that are processor specific.

Windows CE devices using the same version of Windows CE can have different processors, different display sizes and have different user input. For example, Windows CE 2.11 currently supports four different processors, four different display sizes and three different input methods - keyboard, touchpad and touchscreen. When developing a program, a Windows CE developer must decide what platforms will be supported. Once the target platforms are known, a developer needs to consider the variations in screen display, input methods and processors that occur. If all variations are to be supported, a developer must then decide how best to design the program.

A developer has essentially three options. The first option is to create one program, which accommodates all platforms without limiting the functionality of any platform due to another. For example, multiple dialog boxes could be included and displayed only on the appropriate screen size. While providing the best experience to a user for all platforms, the resulting source code will be complex and the executable could be larger than necessary if extra functions or dialog boxes are included.

Another design option is to create multiple versions of the program - one version for each platform. Thus, no device would be limited by another, the source code for each version will be simpler than that from option one, and the size of the program will be as small as possible. The drawback here affects the developer, who would have to maintain multiple versions of code. Multiple versions of source code for one program makes errors of omission probable - meaning a fix or change is added to one version, but accidentally omitted from another.

The third design option is to maintain one version of code, but limit the program by the device supporting the least functions and features. This option is recommended by Microsoft - write an application for the lowest common denominator of functions and features [63]. Although a program may not use all available features on all target devices, this approach keeps the program small, keeps the source code simple, and makes code maintenance easier on a developer. I chose this design method.

Once the target platforms are chosen and a design method is selected, a developer must ensure to accommodate the various targets. A program will need to handle the different input methods and the different Windows messages generated by the OS. Dialog boxes will need to fit within the screen display of the device having the smallest resolution.

A developer should also be aware that different errors can occur with different targets. As noted in section E, processor specific compilation and link errors are already known to occur. Processor specific problems are nice because these generally cause the program build to fail. Problems caused by differences in screen display or input methods are more difficult to spot. A program will compile, and problems can remain hidden until a developer or a user runs the program on a real device. Nothing I read stressed the problems that could occur if a developer does not take into account the variations in screen size or input methods on different Windows CE devices. If a program uses a function that depends upon a specific input method, for example a touchscreen message, this part of a program may freeze on a Windows CE device that does not have a touchscreen. Problems caused by differences in screen display may be revealed by use of the emulator provided in the Toolkit. Yet, the emulator can not be depended upon completely. As previously mentioned, even if a program compiles and works for the emulator, it may behave differently on an actual device.

When I ported my programs from the Jornada 820, with its 640 X 480 display, to the 620LX, I found that I did need to resize the dialog boxes for the 640 X 240 display. I could have created two versions of the programs -one for each display type. Since I wished to maintain just one version of the program, I chose to resize the boxes for the smaller display. While this is easier on me, the developer, some of the resulting boxes do feel cramped on the larger display of the Jornada 820.

The SDK that I used for this project was the Handheld PC Professional 3.0 SDK, since my primary device is an H/PC Pro. I was able to cross compile for the older Windows CE versions using this SDK. For the most part, I had few problems with this SDK. However, it had the feeling of a late beta. The help is not well organized, and, as I previously mentioned, functions are listed in the help that are not actually defined in the existing libraries. I suspect that these missing functions will be implemented in the future, but the help files were not edited to reflect this.

The programming goal of this project was to produce network utilities for Windows CE devices. Two utilities were successfully written in the course of this project, a time client and an FTP client.

Some hints and ideas for this time client were obtained from Vijay Mukhi's time client example [62]. I compiled a version of E_Time for all platforms currently supported by the Windows CE SDKs for Windows CE 2.00, Windows CE 2.01, and Windows CE 2.11. The version for Windows CE 2.11 was tested on the emulator, and on the ARM platform (HP Jornada 820). The version for Windows CE 2.00 was tested on the SH3 platform (HP 620LX). The X86 emulator version did not compile for Windows CE 2.00 or Windows CE 2.01, when linking with winsock.lib. I have made the executables available to the public as freeware.

The readme file and an example log file for E_Time are in Appendix A. Figure 5 displays a screen shot of E_Time. Table 4 provides an overview of source code file and executable file information. Table 5 lists current program features.

Figure 5: Screen Shot of E_Time

Table 4: E_Time File Information

Table 5: E_Time Program Information

E_FTP is a Windows Sockets FTP Client that contacts and connects to port 21 (FTP) of any FTP server, and follows the protocol described in RFC 959 to perform the transfer of files between the client and the server [65]. Table 6 shows the FTP Commands implemented in this client based on RFC 959. Several RFC 959 commands were not implemented in order to keep the client simple and ensure completion of this project by the target date. These commands are listed in Table 7.

ABOR was the only command that I attempted to implement but did not due to difficulties. This command tells the server to abort the previous FTP service command and any associated transfer of data. I intended to use this to abort file transfers. RFC 959 does state that this command may not be implemented on all servers and may need special action to force a server to recognize it. I found that ABOR indeed did not work well with all of the servers that I tested. I abandoned implementing my abort with this RFC 959 command. Instead, my abort command simply closes the data socket. This may be abrupt, and graceless, but it worked in all cases that I tested.

Table 6: RFC 959 FTP Commands Implemented in E_FTP

Table 7: RFC 959 FTP Commands Not Implemented in E_FTP

After entering the fully qualified domain name, user name and password, E_FTP allows a user to log onto any FTP server using port 21. E_FTP creates a log file, e_ftplog.txt, to store connection information and command messages to assist with troubleshooting. This client also provides a test routine, which makes a control connection to Microsoft's FTP site, changes the transfer mode and requests the connection status. This routine logs its activity in a file, e_chklog.txt, which can also be helpful to troubleshoot connection problems. Once connected to a server, a user may change, create or delete remote directories, plus list the contents of a directory. When viewing the contents of a directory having a large number of files, the number of files may exceed the screen buffer size which is set at 100 lines. To assist with this problem, the directory contents are also saved in a file, LIST.TXT. A user may retrieve and store one or multiple files, abort transfers, and delete remote files one at a time. E_FTP includes a large amount of error checking for both the network connection and file handling functions. I also attempted to provide useful error statements for different problems. To assist with troubleshooting problems occurring during a 'Get Multiple Files From Host', the list of names matching the file name pattern is saved in NLIST.TXT. There a user can see exactly what the function attempted to retrieve. User help is incorporated into the program as brief comments on each dialog box. To help keep the size of the program small, I did not include a detailed help file. Detailed help is provided in a readme.txt file, which a user may choose to download.

The only known limitation in E_FTP occurs with number of files that may be retrieved by mget or 'Get Multiple Files From Host'. If the file name pattern generates a list of matching names larger 4K (4096 bytes), only the final 4K will be retrieved. This limit is not affected by file sizes, but only by the number of and size of the file names. To determine if this problem has occurred, a user only needs to check the size of the file NLIST.TXT. If the size of that file is greater than 4096 bytes, then the user should split the transfer by using patterns that will select a smaller number of files. For example, instead of using *.*, a user could do multiple transfers - first using a*.*, then b*.*, and so on. This limitation only occurs with mget.

The readme file and example log files for E_FTP are in Appendix B. This includes a readme.txt, which details the operation of the program from the user perspective. Figures 6 and 7 show screen shots of E_FTP. Table 8 provides an overview of source code files and executable file information. Table 9 lists current program features.

Again, I compiled a version of E_FTP for all platforms currently supported by the Windows CE SDKs for Windows CE 2.00, Windows CE 2.01, and Windows CE 2.11. The version for Windows CE 2.11 was tested on the emulator, and on the ARM platform (HP Jornada 820). The version for Windows CE 2.00 was tested on the SH3 platform (HP 620LX). As before, the X86 emulator version did not compile for Windows CE 2.00 or Windows CE 2.01, when linking with winsock.lib. However, it compiled fine for the actual platforms. I made the executables available to the public as freeware.

Some hints and ideas for this FTP client were obtained from the following: Vijay Mukhi's FTP client example from VIJAY MUKHI'S TECHNOLOGY CORNUCOPIA; Public domain WS_FTP code written by John A. Junod and later modified by L. Kahn; and freeware NcFTP source code written by Mike Gleason.

Figure 6: Screen Shot of E_FTP - File Menu

Figure 7: Screen Shot of E_FTP - File Transfer

Table 8: E_FTP File Information

Table 9: E_ FTP Program Information

After working with the Windows CE Toolkits and SDKs, I found this software development package to be very useful. Overall, the Windows CE Toolkits worked quite well. Nonetheless, I did find a few items that should be improved to better serve the developer.

As noted previously, functions are listed in the help that are not defined in the libraries. The Windows CE help files should correctly reflect the functions currently available in and supported by the SDK. I found the inaccurate information quite frustrating at times - especially when I was working with the various FTP functions. These functions were beautifully defined in the help, and listed in one of my programming references [60]. They just did not make it into the libraries. Microsoft should consider improving the accuracy of the help files.

In the time since I completed the programming portion of my project, I have noted that Microsoft has reorganized and improved the online help available through MSDN. In early 1999, little information was available beyond the three books and the few technical papers that I have already mentioned. Moreover, the information was somewhat difficult to find. Now the MSDN online library has a huge selection of technical references and background papers specifically for Windows CE [66]. I have not reviewed the content of most of the papers, but the selection of topics is excellent. Microsoft also now offers many online seminars that cover user and developer Windows CE topics [67].

Windows CE is continuing to grow and evolve. This project has investigated useful tools for development of software for Windows CE embedded system devices, and has initiated some software development. Future work can be done with the current software that was developed in this project. Future work can also be done on new software using the paths and pitfalls discovered in this project as guidelines.

E_Time is a simple time client that returns the exact response of any timeserver using port 13. This client could better serve a mobile user by providing time zone adjustment based on user input of their current location. E_Time would be able to contact more timeservers if it were modified to accept user input of the timeserver port number. Other ports, such as port 37, can also provide time information. The data returned by this time client only provides information to the user. A Windows CE device does not make use of it. A user must manually alter the time. Modifying this time client to provide automatic time synchronization of a Windows CE device and a user selected timeserver would be a nice additional feature.

E_FTP provides a very basic FTP client. It could be enhanced in terms of FTP functionality, Windows CE performance, user convenience and Windows CE interface with other systems.

Implemented in E_Time but not in E_FTP, the acceptance of either the IP address or the hostname of an FTP server would provide a nice choice to a user. The client should also be modified to accept user input of the FTP server port number to allow connection to servers not using port 21. The implementation of the remaining commands listed in Table 7 would make this FTP client compliant with RFC 959.

Log files can take up space unnecessarily. Since minimizing the use of storage space is a Windows CE development guideline, a user should be able to toggle file logging on or off. Another development guideline is efficient and minimal use of memory. Memory efficiency for E_FTP could be improved by the implementation of dynamic linked lists instead of buffers and arrays. As previously noted, a 4KB limitation exists on the list of names that are retrieved by mget. If linked lists were implemented, this limit the on buffer size for the NLST command could be easily removed. Memory could also be better used and socket conflicts avoided by modifying the client to allow only one instance of FTP to execute.

The user experience could be better improved by providing some additional error checking and input choices. While get and mget warn a user that a file will be overwritten, put and mput do not do this. E_FTP should be modified to include overwrite error checking on files sent to the server. This could be implemented with the STOU command. Another useful error check is to verify that a filename does not match a directory - either locally or remotely. This would avoid some odd transfer errors. The user experience would be improved by allowing the entry of a local folder path. In actuality, Windows CE does not use the concept of a local directory. However, users are familiar with this idea. Currently, that information can only be included in filenames for get and put. Files transferred with mput must be in the same folder as e_ftp.exe. Likewise, files that are retrieved with mget are saved in the same folder as e_ftp.exe. The client should be altered to allow a separate entry line for the local file path for all transfer commands - appending the filename to this path for the actual command. An additional change that would benefit the user experience is the ability to rename files during the overwrite check. Thus, a transfer may not have to be aborted.

E_FTP handles ASCII and BINARY file transfer modes, but does not perform file conversions of Microsoft application files. Though a user may not always want file conversion to occur, Microsoft application documents usually need to be converted prior to use by the Pocket applications on a Windows CE device. This FTP client could be modified to detect whether a file is a Microsoft application file (*.doc, *.xls, etc.) and handle the conversion between desktop and Windows CE files accordingly. The file conversion feature should be selective and not process non-Microsoft application files. For example, a binary executable should be transferred with no conversion.

A telnet client was proposed but was not developed in the course of this project. Although Windows CE provides no command line interface, sufficient API functions exist to create the user command line interface. One obstacle that will need to be overcome is the interpretation and processing of the various IAC messages. I found references to a public domain Winsock telnet client, Ewan Telnet. Unfortunately, I did not locate the source code for this program. If found, this code could assist in designing a Winsock telnet client for Windows CE.

During the course of this project, Windows CE Toolkit for Visual C++ 6.0 was investigated as a development tool for Windows CE applications targeted at embedded devices. The original plan for this project was to include the Java programming language. This was not done since the corresponding Windows CE Toolkit for Visual J++ 6.0 was not released by Microsoft.

Windows CE Toolkit for Visual C++ 6.0 was found to be a very useful tool for Windows CE application development. The Toolkit and SDK are installed on a desktop computer running Windows NT as an add-on to either Microsoft Visual Studio 6.0 or Microsoft Visual C++ 6.0. The Toolkit runs within Visual C++ 6.0 adding options to create a Windows CE application project, and allowing a developer to choose which processor platforms to include in the project. Once the project is built, the cross compilation feature of the Toolkit allows a developer to easily change the target processor or the target version of Windows CE used for the program build. Windows CE Toolkit for Visual C++ 6.0 supports all current versions of Windows CE and all current processor platforms. In addition, an emulator is provided to allow a Windows CE program to be run on the development desktop computer instead of the actual Windows CE device.

The primary Windows CE target device for this project was the HP Jornada 820, which has a StrongARM processor and runs Windows CE 2.11. The secondary device was the HP 620LX, which has a SH3 processor and runs Windows CE 2.0. Thus, the cross compilation feature of the Windows CE Toolkit for Visual C++ 6.0 could be investigated, plus the ease of porting an application from one version of Windows CE to another.

Various paths and pitfalls of Windows CE development were discovered in the course of this project. At the outset of this project, information on Windows CE programming was limited, but several good references were found and are listed in the body of this report. Although Windows CE development looks and feels like Win32 development, a developer will be much further ahead if Windows CE development is treated like a new and separate beast to be learned. Porting a 16-bit Win32 API Winsock program to Windows CE proved extremely difficult, and was abandoned in favor of development from scratch. Programming references favored using the Windows CE Win32 API functions and recommended cautious use of MFC functions. When porting a program from Windows CE 2.11 to Windows CE 2.0, differences in file handling functions and string functions had to be overcome. Although testing a program on the built-in emulator can be helpful, the true test is to try a program on the actual device. Developing programs for different Windows CE devices require a developer to be aware of how a program is affected by the screen size, input method and processor on each target device. A developer must decide between maintaining multiple versions of code that use the separate features on each device, or have one version of code that works on the lowest common denominator between the target devices. Although it is a nice development tool, the Windows CE Toolkit for Visual C++ 6.0 has the feel of a beta product. Help files list functions that are not defined in libraries, and some libraries do not link with their defined symbols correctly.

The results of this investigation were used to develop two Windows CE utilities. E_Time, a simple time client, and E_FTP, an FTP client, were written. The primary recommendations for improvements of Windows CE Toolkit for Visual C++ 6.0 are to improve the accuracy and organization of the help.

Future work for this project can be done on the existing FTP client. Performance efficiency can be improved by replacing buffers and arrays with dynamically linked lists. The client would be more useful if it handled file conversion of Microsoft application files between the desktop application files and pocket application files. Future work can also be done on a telnet client using the paths and pitfalls found in this project as guidelines.

I would like to thank Dr. Matt Mutka for acting as my project advisor and giving me the opportunity to work on this project. I would also like to thank Dr. Diane Rover and Dr. Anthony Wojcik for being members of my committee.

***************************************************************************

E_Time; Version 1.0

Written by:

Esther V. V. Reed Internet: <reedevv@cse.msu.edu>

MSU Dept. of CSE August 1999

E_Time is a Windows Sockets Time Client, that was written as part of

my Master's Project while working towards a Master's Degree in Computer

Science & Engineering at Michigan State University, East Lansing, MI.

The executable is released into the public as freeware.

This time client contacts PORT 13 (daytime) of any time server and

reports back the exact response. No adjustment is made based on the

time zone of the server and the time zone of the user. Time zone

adjustment, plus allowing a user to choose to contact different PORTS

(e.g. PORT 37) might be nice future features.

Some hints and ideas were obtained from Vijay Mukhi's time client example

found at VIJAY MUKHI'S TECHNOLOGY CORNUCOPIA (http://users.neca.com/vmis/).

I compiled a version of E_Time for all platforms currently supported

by the Windows CE SDK's for Windows CE 2.00, Windows CE 2.01, and

Windows CE 2.11. The version for Windows CE 2.11 was tested on the

emulator, and on the ARM platform (HP Jornada 820). The version for

Windows CE 2.00 was tested on the SH3 platform (HP 620LX). The X86

emulator version did not compile for Windows CE 2.01, when linking with

winsock.lib. However, it compiled fine for the actual platforms. I am

making the executables available, but be aware that this version were not

tested, meaning various dialogue boxes and menus may not display correctly.

#########################################################################

DISCLAIMER:

THE INFORMATION AND EXECUTABLE PROVIDED IS PROVIDED AS IS WITHOUT WARRANTY

OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO

THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR

PURPOSE. IN NO EVENT SHALL ESTHER V. V. REED BE LIABLE FOR ANY DAMAGES

WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS

OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF ESTHER V. V. REED HAS BEEN

ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

#########################################################################

*****************************************************************************

BEGIN Get Time

0 = WSADATA structure initialized.

Use server IP = 192.5.41.41

0 = Descriptor reference for control socket.

100 = Number of bytes sent; Sent 'Hello'.

Received from IP address 192.5.41.41:

Tue Aug 17 23:43:14 1999

END Get Time.

QUITTING E_Time.

Thank you for using E_Time. Goodbye!

BEGIN Get Time

0 = WSADATA structure initialized.

Use server name = junk

0 = Descriptor reference for preliminary socket.

ERROR: Failed to receive host information. Server could be down.

BEGIN Get Time

0 = WSADATA structure initialized.

Use server name = tock.usno.navy.mil

0 = Descriptor reference for preliminary socket.

Received server IP address of 198.116.61.158

1 = Descriptor reference for control socket.

100 = Number of bytes sent; Sent 'Hello'.

Received from Server tock.usno.navy.mil:

Wed Aug 18 00:07:21 1999

END Get Time.

QUITTING E_Time.

Thank you for using E_Time. Goodbye!

***************************************************************************

E_FTP; Version 1.0

Written by:

Esther V. V. Reed Internet: <reedevv@cse.msu.edu>

MSU Dept. of CSE August 1999

E_FTP is a Windows Sockets FTP Client, that was written as part of

my Master's Project while working towards a Master's Degree in Computer

Science & Engineering at Michigan State University, East Lansing, MI.

The executable is released into the public as freeware. If you find my

program useful, let me know. I'd appreciate it!

OVERVIEW:

=========

This FTP client contacts and connects to PORT 21 (FTP) of any FTP

server, and follows the FTP protocol described in RFC 959. I have

implemented the following FTP Commands listed in RFC 959: USER, PASS,

CWD, CDUP, QUIT, PORT TYPE, RETR, STOR, DELE, RMD, MKD, PWD, LIST,

and STAT. NLST is used in combination with RETR to create an mget.

Mput is also implemented using STOR.

ABOR did not work well with all of the servers that I tested, so

I did not implement this with my abort command. My abort command

simply closes the data socket. This may be abrupt, and graceless,

but it works in all cases that I tested.

AVAILABLE VERSIONS:

===================

I compiled a version of E_FTP for all platforms currently supported

by the Windows CE SDK's for Windows CE 2.00, Windows CE 2.01, and

Windows CE 2.11. The version for Windows CE 2.11 was tested on the

emulator, and on the ARM platform (HP Jornada 820). The version for

Windows CE 2.00 was tested on the SH3 platform (HP 620LX). The X86

emulator version did not compile for Windows CE 2.01, when linking

with winsock.lib. However, it compiled fine for the actual platforms.

I am making the executables available, but be aware that this version

was not tested, meaning various dialogue boxes and menus may not

display correctly.

INSTALLING / UNINSTALLING E_FTP:

================================

Download the appropriate binary of 'e_ftp.exe' to your CE device,

and move it to a folder of your choice. That's it. E_FTP is

installed.

E_FTP is a self-contained program, and writes NOTHING to the

Windows CE registry. To uninstall it, delete the binary, 'e_ftp.exe'

and any of the log files that it created. These are listed below.

To run E_FTP, either double-click or open the file 'e_ftp.exe'.

LOG FILES:

==========

The program will create a few files to log information. These will

all be located in the same folder as the program 'e_ftp.exe'.

e_ftplog.txt and e_chklog.txt will created when the program starts.

The other files, LIST.TXT and NLIST.TXT, will only be created when

you run the commands that need them. The log and information files are:

* e_ftplog.txt -- logs network, error and terse status messages

to and from E_FTP; if something isn't working

right, look here first. This file is kept

and appended. You can clear it when you

start the program, but aware that if you

never clear it, the file will grow continuously.

* e_chklog.txt -- logs E_FTP test info; if you can't connect

to your server, try the test. It tests a

control socket connection to ftp.microsoft.com.

If this works, your network is probably fine,

and you need to check the host name, userid

and password. If it doesn't work, make sure

your network is up. This isn't a 100% test,

since sometimes this server is off-line.

This file is also kept and appended. You can

clear it when you start the program, but aware

that if you never clear it, the file will also

grow continuously.

* LIST.TXT -- Lists only the most recent 'contents of the

remote directory'. If the file list is larger

than the screen buffer, you won't see the top

of your list. Look here to see the whole list.

* NLIST.TXT -- Lists only the most recent matches from 'get

multiple files'. If something isn't working

right, look here to see what your pattern

matches on the FTP server.

USER HELP:

==========

Main menu:

The main menu has 4 sections.

'E_FTP' contains commands to make, break and check host

connections, and to exit the the program.

'Directory' contains commands for the remote directory:

make one, delete one, change directories, list the directory

name, and get the contents.

'File' contains commands that handle file transfers, delete

a remote file, and set the file transfer mode.

'Help' contains a short readme, program version and platform

info, and a FTP test routine.

Dialogue boxes:

Most of the dialogue boxes contain a short sentence with

help, where I thought it necessary. Key points:

'CONNECT TO HOST' -- Do NOT use an IP address. Use the

the fully qualified domain name. That is, use

something like ftp.microsoft.com or pilot.msu.edu

or arctic.cse.msu.edu. Do not use numbers like

35.8.2.41 -- they won't work.

'CHANGE REMOTE DIRECTORY' -- You have three choices:

(1) .. moves up one direcotory level;

(2) list the full path starting with /, for example,

/user/userid/mywebdir/enddir;

(3) list the path referring to where you are at, meaning

if the current remote directory is /user/userid,

to finish the example above just enter (no leading

/) mywebdir/enddir -- and you'll end up at

/user/userid/mywebdir/enddir.

'MAKE / DELETE REMOTE DIRECTORY' -- You can use either choice

(2) or (3) above to add the path to the directory.

'GET SINGLE FILE FROM HOST' --

Transfer mode -- shows the current setting, but you

can change it with a click.

Remote directory -- shows the current setting, but you

can change this using the same 3 choices in

'CHANGE REMOTE DIRECTORY'.

Remote file name -- must match exactly. No * or ? here.

New file name -- Use this to change the local file name.

Since CE designates all files by their full path,

you can include the path of where you want the

file to go, AS LONG AS the folders already exist.

If you don't designate a path, the file will end

up in the same directory as 'e_ftp.exe'.

This operation may be aborted.

'GET MULTIPLE FILES FROM HOST' -- All files are copied to the same

directory as 'e_ftp.exe'.

Transfer mode and Remote directory -- same as above.

Remote file name --

may match a file name exactly; or may include...

* -- wildcard covering any number of characters;

? -- wildcard for a single character.

This operation may be aborted.

'PUT SINGLE FILE ON HOST' --

Transfer mode and Remote directory -- same as above.

Local file name -- Since CE designates all files by their

full path, you can include the path of where

you want the file to come from, AS LONG AS the

folders and file exist. If you don't designate the

directory, the file must be in the same directory

as 'e_ftp.exe'.

Remote file name -- Use this to change the remote file name.

No * or ? here.

This operation may be aborted.

'PUT MULTIPLE FILES ON HOST' --

Transfer mode and Remote directory -- same as above.

Local files -- Since CE designates all files by their

full path, you can include the path of where

you want the file to come from, AS LONG AS the

folders. If you don't designate the directory,

the file must be in the same directory as 'e_ftp.exe'.

As far as the file name, it may match a file name

exactly; or it may include...

* -- wildcard covering any number of characters;

? -- wildcard for a single character.

This operation may be aborted.

'DELETE SINGLE FILE ON HOST' --

Remote directory -- same as above.

Remote file name -- must match exactly. No * or ? here.

LIMITATIONS ON FILE TRANSFERS:

==============================

Other than available physical space, there are no limits on the sizes

of the files that may be transferred. Currently, the program does

not check in advance if sufficient space is available either on the

server or on the client. If the user does not check, the transfer

will just fail when there is no more space.

Both ASCII and BINARY transfers are supported, however the program

does not handle format conversions between Windows CE and other

windows environments. This means the file will transfer as is,

and the Pocket applications may or may not be able to handle the

file. I found that text files were fine, and the Excel 97 files that

I transfered were fine for Pocket Excel. While simple Word 97 files

were fine, some Word 97 files, that included complex features, stumped

Pocket Word and failed to open correctly. Binaries must be compiled

for the CE version and hardware platform that you are using.

The only known limitation occurs with number of files that may be

retrieved by mget or 'get multiple files'. If the file name pattern

generates a list of matching names larger 4K (4096 bytes), only the

final 4K will be retrieved. This limit is NOT affected by file sizes,

but only by the number of and size of the file NAMES. The list of

matching names is also printed in NLIST.TXT. If that files is

greater than 4096 bytes, then the user should split up the transfer

and use patterns that will select smaller number of files. For

example, instead of using *.*, a user could do multiple transfers --

first using a*.*, then b*.*, and so on. This limitation ONLY occurs

with mget. Get, put and mput have no such limits.

ACKNOWLEDGEMENTS:

=================

Some hints and ideas for this FTP client were obtained from the following:

- Vijay Mukhi's FTP client example found at

VIJAY MUKHI'S TECHNOLOGY CORNUCOPIA (http://users.neca.com/vmis/).

- Public domain WS_FTP code written by John A. Junod,

and later modified by L. Kahn.

- freeware NcFTP source code written by Mike Gleason

found at ftp://ftp.probe.net/pub/ncftp/.

- Douglas Boling's "Programming Microsoft Windows CE" from

Microsoft Press.

#########################################################################

DISCLAIMER:

===========

THE INFORMATION AND EXECUTABLE PROVIDED IS PROVIDED AS IS WITHOUT WARRANTY

OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO

THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR

PURPOSE. IN NO EVENT SHALL ESTHER V. V. REED BE LIABLE FOR ANY DAMAGES

WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS

OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF ESTHER V. V. REED HAS BEEN

ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

#########################################################################

*****************************************************************************

BEGIN FTP connect.

0 = socTmpCtl; Descriptor reference for control socket.

0 = connect succeeded

control socket address = PORT 35,9,48,186,2,035.9.48.186

Received: 220 ftp Microsoft FTP Service (Version 4.0).

Command Sent: USER anonymous

Received: 331 Anonymous access allowed, send identity (e-mail name) as password.

Command Sent: PASS xxxxxx

Received: 230-This is FTP.MICROSOFT.COM

230-Please see the dirmap.txt file for

230-more information.

230 Anonymous user logged in.

Command Sent: TYPE A

Received: 200 Type set to A.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/" is current directory.

User anonymous successfully logged onto host ftp.microsoft.com

END FTP connect.

Command Sent: STAT

Connection Status:

211-ftp Microsoft Windows NT FTP Server status:

Version 4.0

Connected to 35.9.48.186

Logged in as test@test

TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: STREAM

No data connection

211 End of status.

ERROR: FTP connection exists. Ignoring this connection request.

Begin closing connection.

Command Sent: QUIT

Disconnected from host ftp.microsoft.com with 0 errors.

BEGIN FTP connect.

1 = socTmpCtl; Descriptor reference for control socket.

0 = connect succeeded

control socket address = PORT 35,9,48,186,2,035.9.48.186

Received: 220 arctic FTP server (SunOS 5.6) ready.

Command Sent: USER reedevv

Received: 331 Password required for reedevv.

Command Sent: PASS xxxxxx

Received: 230 User reedevv logged in.

Command Sent: TYPE A

Received: 200 Type set to A.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv" is current directory.

User reedevv successfully logged onto host arctic.cse.msu.edu

END FTP connect.

BEGIN GET MULTIPLE FILES from host.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv" is current directory.

Command Sent: TYPE I

Command Sent: TYPE A

Begin creating listen socket.

2 = descriptor reference for listen socket.

0 = listen socket bind succeeded

PORT 35,9,48,186,4,207Command Sent: PORT 35,9,48,186,4,207

Reply from PORT cmd: 200 PORT command successful.

Command Sent: CWD transfer

Received: 250 CWD command successful.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

Command Sent: NLST HP*.*

Received after get: 150 ASCII data connection for /bin/ls (35.9.48.186,1231) (0 bytes).

[3] accept from 35.9.20.20 port 20

Received: 226 ASCII Transfer complete.

Get directory list succeeded.

Command Sent: TYPE I

Begin creating listen socket.

4 = descriptor reference for listen socket.

0 = listen socket bind succeeded

PORT 35,9,48,186,4,208Command Sent: PORT 35,9,48,186,4,208

Reply from PORT cmd: 200 PORT command successful.

Command Sent: CWD /user/reedevv/transfer

Received: 250 CWD command successful.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

Command Sent: RETR HPTEST1asc.PXL

Received after get: 150 Binary data connection for HPTEST1asc.PXL (35.9.48.186,1232) (1655 bytes).

[5] accept from 35.9.20.20 port 20

Received: 226 Binary Transfer complete.

Get single file succeeded.

Begin creating listen socket.

6 = descriptor reference for listen socket.

0 = listen socket bind succeeded

PORT 35,9,48,186,4,209Command Sent: PORT 35,9,48,186,4,209

Reply from PORT cmd: 200 PORT command successful.

Command Sent: CWD /user/reedevv/transfer

Received: 250 CWD command successful.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

Command Sent: RETR HPTEST1bin.PXL

Received after get: 150 Binary data connection for HPTEST1bin.PXL (35.9.48.186,1233) (1655 bytes).

[7] accept from 35.9.20.20 port 20

Received: 226 Binary Transfer complete.

Get single file succeeded.

Begin creating listen socket.

8 = descriptor reference for listen socket.

0 = listen socket bind succeeded

PORT 35,9,48,186,4,210Command Sent: PORT 35,9,48,186,4,210

Reply from PORT cmd: 200 PORT command successful.

Command Sent: CWD /user/reedevv/transfer

Received: 250 CWD command successful.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

Command Sent: RETR HPWORD1asc.pwd

Received after get: 150 Binary data connection for HPWORD1asc.pwd (35.9.48.186,1234) (959 bytes).

[9] accept from 35.9.20.20 port 20

Received: 226 Binary Transfer complete.

Get single file succeeded.

Begin creating listen socket.

10 = descriptor reference for listen socket.

0 = listen socket bind succeeded

PORT 35,9,48,186,4,211Command Sent: PORT 35,9,48,186,4,211

Reply from PORT cmd: 200 PORT command successful.

Command Sent: CWD /user/reedevv/transfer

Received: 250 CWD command successful.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

Command Sent: RETR HPtext1asc.txt

Received after get: 150 Binary data connection for HPtext1asc.txt (35.9.48.186,1235) (172 bytes).

[11] accept from 35.9.20.20 port 20

Received: 226 Binary Transfer complete.

Get single file succeeded.

Begin creating listen socket.

12 = descriptor reference for listen socket.

0 = listen socket bind succeeded

PORT 35,9,48,186,4,212Command Sent: PORT 35,9,48,186,4,212

Reply from PORT cmd: 200 PORT command successful.

Command Sent: CWD /user/reedevv/transfer

Received: 250 CWD command successful.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

Command Sent: RETR HPtext1bin.txt

Received after get: 150 Binary data connection for HPtext1bin.txt (35.9.48.186,1236) (196 bytes).

[13] accept from 35.9.20.20 port 20

Received: 226 Binary Transfer complete.

Get single file succeeded.

Multiple get succeeded. Received 5 file(s).

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

BEGIN PUT MULTIPLE FILES on host.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

Command Sent: TYPE A

Command Sent: CWD /user/reedevv/transfer

Received: 250 CWD command successful.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

Begin creating listen socket.

14 = descriptor reference for listen socket.

0 = listen socket bind succeeded

PORT 35,9,48,186,4,213Command Sent: PORT 35,9,48,186,4,213

Reply from PORT cmd: 200 PORT command successful.

Command Sent: CWD /user/reedevv/transfer

Received: 250 CWD command successful.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

Command Sent: STOR HPtext1bin.txt

Received after put: 150 ASCII data connection for HPtext1bin.txt (35.9.48.186,1237).

[15] accept from 35.9.20.20 port 20

Received: 226 Transfer complete.

Put single file succeeded.

Begin creating listen socket.

16 = descriptor reference for listen socket.

0 = listen socket bind succeeded

PORT 35,9,48,186,4,214Command Sent: PORT 35,9,48,186,4,214

Reply from PORT cmd: 200 PORT command successful.

Command Sent: CWD /user/reedevv/transfer

Received: 250 CWD command successful.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

Command Sent: STOR HPtext1asc.txt

Received after put: 150 ASCII data connection for HPtext1asc.txt (35.9.48.186,1238).

[17] accept from 35.9.20.20 port 20

Received: 226 Transfer complete.

Put single file succeeded.

Multiple put succeeded. Put 2 file(s).

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

BEGIN PUT SINGLE FILE on host.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

Begin creating listen socket.

18 = descriptor reference for listen socket.

0 = listen socket bind succeeded

PORT 35,9,48,186,4,215Command Sent: PORT 35,9,48,186,4,215

Reply from PORT cmd: 200 PORT command successful.

Command Sent: CWD /user/reedevv/transfer

Received: 250 CWD command successful.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

Command Sent: STOR newFile.txt

Received after put: 150 ASCII data connection for newFile.txt (35.9.48.186,1239).

[19] accept from 35.9.20.20 port 20

Received: 226 Transfer complete.

Put single file succeeded.

Command Sent: PWD

CURRENT REMOTE DIRECTORY:

257 "/user/reedevv/transfer" is current directory.

BEGIN 'Remote Dir LIST'.

Begin creating listen socket.

20 = descriptor reference for listen socket.

0 = listen socket bind succeeded

PORT 35,9,48,186,4,216Command Sent: PORT 35,9,48,186,4,216

Reply from PORT cmd: 200 PORT command successful.

Command Sent: LIST

Received: 150 ASCII data connection for /bin/ls (35.9.48.186,1240) (0 bytes).

[21] accept from 35.9.20.20 port 20

Received directory list. See LIST.TXT:

226 ASCII Transfer complete.

Begin closing connection.

Command Sent: QUIT

Disconnected from host arctic.cse.msu.edu with 0 errors.

QUITTING E_FTP.

Thank you for using E_FTP. Goodbye!

BEGIN FTP TEST.

0 = WSADATA structure initialized.

22 = soc1; Descriptor reference for socket.

0 = bind succeeded

0 = listen succeeded

0 = select succeeded

23 = soc0; Descriptor reference for socket.

0 = connect succeeded

0 = getsockname succeeded

socket info = PORT 35,9,48,186,2,035.9.48.186

recv 46 bytes: 220 ftp Microsoft FTP Service (Version 4.0).

send 16 bytes: anonymous user login

recv 72 bytes: 331 Anonymous access allowed, send identity (e-mail name) as password.

send 21 bytes: anonymous password

recv after sending password: 33 bytes: 230-This is FTP.MICROSOFT.COM

recv#2 98 bytes: 230-Please see the dirmap.txt file for

230-more information.

230 Anonymous user logged in.

send 9 bytes: binary mode

recv 20 bytes: 200 Type set to I.

send 7 bytes: get FTP connection status

recv 232 bytes: 211-ftp Microsoft Windows NT FTP Server status:

Version 4.0

Connected to 35.9.48.186

Logged in as test@test.test

TYPE: BINARY, FORM: Nonprint; STRUcture: File; transfer MODE: STREAM

No data connection

send 7 bytes: quit session

recv 65 bytes: 211 End of status.

221 Thank you for using Microsoft Products!

FTP TEST DONE.

total 116

drwxr-xr-x 4 reedevv staff 1024 Aug 17 20:20 .

drwxr-xr-x 46 reedevv staff 4096 Aug 17 15:57 ..

-rw-r--r-- 1 reedevv staff 1655 Jul 18 19:35 HPTEST1asc.PXL

-rw-r--r-- 1 reedevv staff 1655 Jul 18 19:34 HPTEST1bin.PXL

-rw-r--r-- 1 reedevv staff 959 Jul 18 19:35 HPWORD1asc.pwd

-rw-r--r-- 1 reedevv staff 172 Aug 17 20:19 HPtext1asc.txt

-rw-r--r-- 1 reedevv staff 184 Aug 17 20:19 HPtext1bin.txt

-rw-r--r-- 1 reedevv staff 699 Aug 8 17:09 disclaim.txt

drwxr-xr-x 2 reedevv staff 512 Aug 3 22:14 junk

-rw-r--r-- 1 reedevv staff 24576 Aug 3 21:57 junk.exe

-rw-r--r-- 1 reedevv staff 1894 Jul 24 20:17 junk1

-rw-r--r-- 1 reedevv staff 1894 Jul 24 20:17 junk2

-rw-r--r-- 1 reedevv staff 699 Aug 17 20:20 newFile.txt

-rw-r--r-- 1 reedevv staff 5344 Aug 8 13:42 ntwordlBIN2.doc

-rw-r--r-- 1 reedevv staff 1894 Aug 7 14:15 sched1

drwxr-xr-x 2 reedevv staff 512 Aug 17 19:39 test

-rw-r--r-- 1 reedevv staff 76 Aug 3 00:02 test.txt

-rw-r--r-- 1 reedevv staff 76 Aug 3 00:02 test2.txt

-rw-r--r-- 1 reedevv staff 1894 Jul 18 19:15 unixtextASC2.txt

-rw-r--r-- 1 reedevv staff 1894 Jul 18 19:15 unixtextBIN2.txt

HPTEST1asc.PXL

HPTEST1bin.PXL

HPWORD1asc.pwd

HPtext1asc.txt

HPtext1bin.txt