180 likes | 202 Views
Cross-Platform Development with C and C++. Pre-conference Tutorial by Rob Swindell. Platform. Operating System (Windows, Linux, FreeBSD) Architecture (x86, 68K, IA64, PowerPC, MIPS, ARM) Build environment Run-time libraries (libc, glibc, MFC, VCL, CLX) Compiler Linker
E N D
Cross-Platform Development with C and C++ Pre-conference Tutorial by Rob Swindell
Platform • Operating System (Windows, Linux, FreeBSD) • Architecture (x86, 68K, IA64, PowerPC, MIPS, ARM) • Build environment • Run-time libraries (libc, glibc, MFC, VCL, CLX) • Compiler • Linker • Build tools (make, IDE)
Operating Systems • Windows • Win16 • Win32 • Windows 95/98/Me • Windows NT/2000/XP • Windows CE • Win64 • Unix variants • GNU/Linux • BSD (BSD/OS, FreeBSD, NetBSD, OpenBSD, OS-X) • AIX, Solaris, Xenix, HP-UX, etc.
Portability • “Portable source code” • Slippery term, use with caution • Portable to where? • Indicates potential • “Cross-platform source code” • Preferred term • Indicates status • Is printf() portable?
Portable? int sum(int a, int b){ return a+b; } printf(“sum=%d”,sum(9876,54321)); Borland C++ 5.5 results: sum=64197 Borland C++ 3.1 results: sum=-1339 Is this an Operating System, Architecture, or Build Environment issue?
Why Develop Cross-platform? • Increased market opportunity • Encourages modular design • Help expose bugs • Keep code standards-compliant
Techniques • Migrating to a new development environment • Abandoning old environment • Targeting a Standard Run-time Library • ANSI/ISO • Standard C Library • Standard C++ Library • POSIX.1 (IEEE Standard 1003.1) • Section A – Base Unix API • Section B – Real-time extensions • Section C – Threads • POSIX Libraries exist for Win32 (commercial and open source)
Techniques (continued) • Targeting an Abstraction Layer • NSPR (Netscape Portable Run-time) [non-GUI] for C or C++ • Borland CLX (Component Library, Cross-platform) for C++ • Qt [C++ and GUI only] • These technologies are often referred to as frameworks • Targeting an Emulation Layer • Unix/POSIX on Windows: Cygwin, UWIN, Interix • Windows on Unix: Winelib, Wind/U, Visual MainWin • DOS/conio on Unix/curses: libconio
Borland CLX • Component Library, Cross-platform • Dual licensed • Easy migration from VCL • BaseCLX • RTL classes and components • VisualCLX • Native GUI components and data-aware visual controls • DataCLX • Highly scalable data-access components • NetCLX • Web application framework and components
Synchronet XPDEV • C library for cross-platform development • Open source (cvs.synchro.net) • LGPL licensed • Small and modular • Utilizes a combination of abstraction and emulation • Borland, Microsoft, and GNU tool chains • Targets Win32, Linux, and FreeBSD • Some Win32 API functions on Unix (_beginthread) • Some DOS/conio functions on Unix (getch) • Some POSIX functions on Windows (sem_init) • Some Unix libc functions on Windows (glob)
Issues • File Systems • Path delimiters and drive letters • Filename case sensitivity and length limits • Text line termination sequences (LF vs CRLF) • Wildcard expansion • Architecture • Endianness • Multi-processor • Multi-byte character sets/Internationalization • Example: Windows CE uses Unicode only
Compiler Issues • Integer bit-width • struct/union packing and alignment • #pragmas and language extensions • Command-line switches (some are standard) • Object file formats (COFF, ELF, OMF) • Object files (.o vs .obj) • Library files (.a vs .lib, .so vs .dll) • Symbol/function name mangling/decorating • Calling conventions (__cdecl vs __stdcall)
Build Issues • Makefiles • Borland and GNU makefile syntax are not compatible • Use make “include” files to reuse build rules and logic • Project files • IDE-specific • Scripts • Typically, operating system specific
Application Configuration • Unix has no “Windows Registry” • Use configuration (.ini) files instead • Use CLX TMemIniFile component • Unix uses well-known files for system configuration • /etc/hosts • /etc/resolv.conf
Device Issues • Hardware-enabled applications are difficult to develop cross-platform • Device access facilities are operating system dependent • Cross-platform kernel-level (device driver) development can be very challenging • Invariably requires platform-specific modules • Seemingly unified platforms (e.g. Win32, Unix) are distinctly different at the kernel level
Solutions • Using existing cross-platform emulation and abstraction libraries • CLX, Qt, NSPR, Cygwin, Synchronet XPDEV • Conditional compilation using the C/C++ preprocessor • #if defined(_WIN32) • #elif defined(__linux__) • #elif defined(__unix__)
Solutions (continued) • Target-specific header files defining platform-dependent macros • include/unix/guiwrap.h • include/win32/guiwrap.h • Include path determines which macros are defined • Compiling target-specific source modules • src/unix/getproc.c • src/win32/getproc.c • Build file determines which source files are built
Conclusion Cross-platform development projects can be challenging, fun, and rewarding! Thank you for your time, Rob Swindell (rob@synchro.net)