Cross-platform C SDK logo

Cross-platform C SDK


Next ❯
This page has been automatically translated using the Google Translate API services. We are working on improving texts. Thank you for your understanding and patience.

While civilians (i.e., nonprogrammers) often fantasize about winning the lottery, the equivalent for many programmers is the rare opportunity to create a new library from scratch, without the constraints that often frustrate their desires to extend and improve an existing library. Philip J. Schneider - Industrial Light + Magic

The NAppGUI implementation has been split into several libraries written in ANSI-C (C90) with small parts in C++98 (Figure 1). The project compiles without problems in all versions of Visual Studio (since VS2005), Xcode (since 3) and GCC (since 4). It can be used for developing high-performance applications written in C on Windows, macOS, and Linux systems. A clear line has been drawn that separates packages oriented to computation and data access (back-end) from those intended for the presentation or interface layers (front-end). We have also followed certain Standards whose bases are centralized in the Sewer library, which, although it does not incorporate much functionality, does define the basic types and configuration macros common to all the project.

NAppGUI SDK dependency schema.
Figure 1: NAppGUI architecture.
  • Packages that do not contain platform dependent code.
  • Packages that contain platform dependent code under a common interface.
  • Sewer: Basic types, assertions, Unicode, standard C library, math functions.
  • Osbs: Operating system services. Portable API on files, directories, processes, threads, memory, etc.
  • Core: Commonly used non-graphical utilities. Memory auditor, data structures, I/O channels, lexical analysis, etc.
  • Geom2D: 2D geometry. Transformations, vectors, polygons, collisions, etc.
  • Draw2D: Vector drawing API, images and fonts.
  • Gui: High-level user interface composer.
  • OSApp: Desktop applications. Message loops.
  • INet: Internet protocols and services, such as HTTP.

1. A little history

I started working on this project unconsciously, in the middle of 2008 when I was finishing my studies in Computer Engineering at the University of Alicante. He wanted to develop a physical systems simulator that would work on both PC-Windows computers and Apple iMacs without having to duplicate all the work. The technological alternatives of the time, such as GTK or Qt, did not convince me at all since they were too heavy, complicated to use and slow, so they would end up tarnishing the quality, elegance and effort that I was putting into my mathematical calculation algorithms. After spending several months evaluating different libraries for cross-platform programming, I downloaded some technical manuals from Apple to program directly in Cocoa, the manzanita manufacturer's base technology for developing software on iMac. In the middle of 2010 I started to see the first results and this was encouraging. I had built an application with my simulator prototype in just 500Kb (Figure 2), in contrast to the 30+Mb of dependencies required by third-party solutions. The code was compact and clean, the application worked at breakneck speed and, above all, it had a professional appearance that was somewhat reminiscent of iMovie, it allowed 3D views to be manipulated like in a video game and provided technical simulation data in real time. This inspired me to continue working on drawing a barrier between the reusable part of the application and the part that depends on a specific technology. This would allow my simulator to be adapted to different computer models and operating systems.

Screenshot of the iMech physical simulator.
Figure 2: iMech simulator, based on a primitive version of NAppGUI.

At the same time, in September 2008 I rejoined the labor market after six years at the University, a market in which I am still currently (May 2021), although the last few years I have been working as a freelancer from home, which allows me to organize the agenda and optimize my time to the maximum. In these years I have not abandoned my personal project, I have continued working on it part-time simply for pure hobby. Its development has allowed me to investigate and delve into interesting areas for me and constantly recycle myself. In 2013 I made my first foray into the world of entrepreneurship as a co-founder of iMech Technologies, a software company with which I am still linked and whose main objective was the sale of the simulation engine that I had previously created. By not coming up with a solid marketing strategy, we didn't achieve our initial goals with iMech, but we were able to turn it around by adding new customers and it's still alive today.

In mid-2015 I began to consider the fact that all the technical effort made during these years has enough entity to become a product by itself. It was then when I created the NAppGUI project and started migrating all the iMech libraries dedicated to cross-platform development. Over the last few years I've completed support for Cocoa and included support for Win32 and Gtk+. I have created this documentation in Spanish and English, with the help of Google translation services.

On December 31, 2019, I upload to GitHub the first public pre-compiled version of NAppGUI.

In May 2020 I start the development of the first commercial application programmed entirely with NAppGUI.

On September 8, 2021, I release the source code of NAppGUI on GitHub, making it an Open Source project under the MIT license.

Next ❯