simple-todo-c: a Windows todo list in pure C and the Win32 API

A 60 KB executable, and that is the whole pitch

simple-todo-c is described as a lightweight, native Windows todo application built with pure C and the Win32 API, and the size badge in the readme says 60 KB. The project presents itself as demonstrating advanced Windows GUI programming and system integration capabilities, which is a fair description of what a small Win32 program is: there is no framework underneath, so every window, message and control is explicit. The technical details list is short and honest. It is written in pure C, it uses the Win32 API for the GUI, it has system tray integration, it produces a lightweight native executable, and it uses modern Windows visual styles with a manifest. That last item is the one that makes a 2005 era API look contemporary, because without an application manifest declaring the visual styles the controls fall back to the old Windows 95 look. The topic list adds tray-application and winapi-application, and the release history shows v0.9 from 2025-05-29, v0.8 from 2025-05-26 and v0.7 from 2025-05-20, with the last push to the repository on 2026-04-07.

Building it needs MinGW-w64 and a batch script

The requirements are Windows, MinGW-w64 as the GCC compiler, and the Windows SDK, which is included with MinGW. The build steps start with installing MinGW-w64, either by downloading from the MinGW-w64 website or by using MSYS2, and adding the MinGW bin directory to your system PATH. Then you clone the repository and change into it.

   git clone https://github.com/Efeckc17/simple-todo-c.git
   cd simple-todo-c

And you build by running the batch script.

   .\build.bat

There is also a debug.bat script at the top level of the repository alongside build.bat, and a DEBUGGING.md file that the readme points to for instructions on debugging the application with Visual Studio, VS Code or other tools. That file is worth knowing about before you start, because a Win32 program with a message loop and a tray icon is a different debugging experience from a script, and the guide exists because someone has already worked that out. The repository is MIT licensed with a LICENSE file at the top level.

The source tree is seven files, and the split tells you the design

The project structure in the readme is a good map of the design.

.
├── src/
│   ├── app.manifest
│   ├── main.c           # Application entry point
│   ├── todo.c           # Todo management logic
│   ├── todo.h           # Todo data structures and declarations
│   ├── gui.c            # GUI implementation
│   └── utils/
│       ├── search.c     # Search functionality implementation
│       └── search.h     # Search function declarations
├── bin/                 # Compiled executable
├── build.bat            # Build script
└── README.md            # This file

The separation is the interesting part. main.c is the entry point and the Win32 plumbing, todo.c and todo.h hold the data structures and the management logic with no GUI dependency at all, and gui.c is the window and control code that knows nothing about the file format. search sits in its own utils subdirectory rather than inside todo.c, which is a small sign the author treats it as a separable concern. app.manifest is the file that carries the visual styles declaration. So the model layer is testable without a window, and the GUI layer is replaceable without touching the data.

Storage is one binary file in AppData with a hundred item ceiling

The data storage section is short and it contains the constraint that matters most in practice. The application stores todos in a binary file at %APPDATA%\TodoApp\todos.dat, the format is a binary file containing the entire todo list, and the capacity is a maximum of 100 todos. That last line is a hard cap, not a soft one, and it is worth weighing before you adopt the application for anything resembling a real task list. The format itself is also worth knowing about, because a single binary file holding the whole list is a simple design with a simple consequence: there is no incremental write, so a crash during a save is a save you did not get, and there is no per-item file to inspect when something goes wrong. The write path is part of the todo module rather than the GUI, so the persistence behaviour is the one to read first in todo.c if you want to know how the file is structured. The application also offers an auto-start with Windows option, which is registered somewhere in the Win32 startup mechanism and is one of those features worth checking on a machine where you do not want it.

The feature set is the ordinary todo list plus a tray icon

The features are the ones you would expect and the readme lists them without embellishment. You can create, edit and delete todo items, mark tasks as complete, and set priority levels for each todo. Storage is persistent in AppData, system tray integration lets you minimize to the tray, the interface has a native Windows look and feel, there is an auto-start with Windows option, and there is real-time search with case-insensitive matching. The usage section spells out the interface in terms of buttons, with an Add button for new todos, an Edit button for existing ones selected in the list, a Delete button, and a Complete button for marking tasks done, all of which works on bin/todo.exe once built. The search function is the one piece with its own module, and a case-insensitive match over a hundred items is cheap, so the interesting question is not performance but how the search interacts with the priority and completion state.

Win32, Common Controls and UXTheme are the three moving parts

The development section names the key components, and they are the three things you need to know to read the GUI code. Win32 API is used for window management and the GUI itself, Common Controls provides the modern UI elements, and UXTheme provides the Windows visual styles. File I/O covers the data persistence. That is the whole stack, with no third party library in the path, which is the point of the project and also the reason the code is legible in one pass. A designer with a C compiler and the SDK can read every line that draws the window, every message the window procedure handles, and every byte written to the todo file, with no abstraction to look up. The price is that none of the conveniences of a modern toolkit are there, no layout manager, no data binding, no event system, so the ergonomics of building something larger on top of it would be poor even though the reading experience is good.

Editorial conclusion

simple-todo-c fits a developer who wants to read a complete native Windows GUI program in one sitting, since the whole application is a handful of C files split into entry point, todo logic, GUI and search, and it fits a user who wants a todo list that does not need a runtime. It does not fit anyone with more than 100 items, since that is the stated capacity of the binary file, and it does not fit a non-Windows user, since the whole thing is Win32 and the build requirements are MinGW-w64 and the Windows SDK. Before you build it, install MinGW-w64 or MSYS2 and put its bin directory on your PATH, run the build.bat script, and check the DEBUGGING.md guide if you want to step through the code in Visual Studio or VS Code.

Frequently asked questions

Official sources

1. Efeckc17/simple-todo-c on GitHub
2. Issues
3. License: MIT
4. README
5. Releases