180 likes | 210 Views
Learn essential techniques and tools for successful cross-platform C and C++ development. Explore operating systems, architectures, build environments, and runtime libraries to achieve portability. Discover why cross-platform development is crucial, addressing market opportunities and bug exposure. Delve into migration strategies, targeting standard run-time libraries and abstraction layers. Gain insights into emulation layers and frameworks like Borland CLX and Synchronet XPDEV. Understand compiler, linker, and build tool challenges, navigating file system and device issues. Overcome platform-dependent hurdles with conditional compilation and target-specific solutions.
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)