Membuat Aplikasi Todo Windows Native dengan C Murni (278 KB, tanpa framework)

• Proyek open source ini adalah aplikasi Todo Windows native ringan yang dibuat hanya dengan C dan Win32 API
• Berjalan dengan ukuran minimum tanpa bergantung pada framework (maksimum 26.5KB), sambil mengimplementasikan GUI Windows tingkat lanjut dan integrasi sistem secara langsung
• Menyediakan bukan hanya fitur dasar seperti menambah, mengedit, menghapus, dan menandai selesai item Todo, tetapi juga fitur produktivitas nyata seperti integrasi system tray dan opsi auto-start
• Penyimpanan bersifat persisten dalam file biner, dan menyimpan hingga 100 daftar tugas di folder AppData
• Kelebihannya adalah pendekatan pemrograman klasik yang sangat dekat dengan OS tanpa framework besar serta lingkungan eksekusi yang ringan

---

🌟 Simple Todo (C / WinAPI)

Gambaran proyek

• Proyek ini membuat aplikasi Todo Windows native modern hanya dengan C dan Win32 API
• Menunjukkan kemampuan pemrograman GUI Windows tingkat lanjut dan integrasi sistem
• Ukuran proyek sangat kecil (maksimum 26.5KB), sambil tetap mempertahankan tampilan khas Windows

✨ Fitur utama

• Bisa membuat, mengedit, dan menghapus item tugas
• Tugas dapat ditandai selesai
• Disimpan secara permanen di AppData sehingga data selalu terjaga
• Terintegrasi dengan system tray dan berpindah ke tray saat diminimalkan
• Memiliki tampilan gaya Windows native
• Menyediakan opsi jalankan otomatis saat Windows dimulai

🛠️ Detail teknis

• Seluruhnya dikodekan dengan C murni
• Hanya menggunakan Win32 API untuk implementasi GUI
• Ukuran executable sangat kecil (26.5KB saat dikompresi dengan UPX)
• Fitur integrasi system tray
• Menerapkan modern visual style melalui manifest

💾 Penyimpanan data

• Semua tugas disimpan dalam satu file biner
• Lokasi penyimpanan: %APPDATA%\\TodoApp\\todos.dat
• Formatnya biner dan dapat menyimpan hingga 100 item

📋 Persyaratan

• Memerlukan lingkungan sistem operasi Windows
• Memerlukan MinGW-w64 (kompiler GCC) dan Windows SDK

🎮 Cara penggunaan

• Jalankan bin/todo.exe, lalu gunakan antarmuka untuk melakukan tindakan berikut
• Tambahkan tugas baru dengan tombol "Add"
• Pilih item lalu klik "Edit" untuk mengubahnya
• Hapus item dengan "Delete"
• Tandai selesai dengan "Complete"
• Prioritas dapat ditetapkan untuk setiap item

🏗️ Struktur proyek

• Folder src/ berisi titik masuk utama (main.c), logika pengelolaan tugas (todo.c), deklarasi struktur (todo.h), dan implementasi GUI (gui.c)
• Executable hasil kompilasi ditempatkan di bin/
• Menyertakan skrip build (build.bat) dan dokumentasi proyek

🔧 Elemen pengembangan

• Win32 API: implementasi manajemen jendela dan keseluruhan GUI
• Common Controls: penggunaan elemen UI modern
• UXTheme: dukungan penerapan Windows visual style
• File I/O: mewujudkan penyimpanan data persisten

📝 Lisensi

• Dapat digunakan dan dimodifikasi secara bebas dengan lisensi MIT

🤝 Panduan kontribusi

• Pull Request disambut
• Siapa pun dapat berpartisipasi dalam proyek ini

📫 Kontak dan tautan

• Toxi360 (@Efeckc17)
• Tautan GitHub proyek

[aer0700]

Ada nuansa romantisnya.

[GN⁺]

Komentar Hacker News

• Ada hal yang saya sukai dari pemrograman GUI win32, meski memang agak unik, tetapi kalau membaca blog Raymond Chen Anda akan mengerti alasannya. API win32 berawal dari era prosesor 8088, dan ada gaya tertentu yang bisa menghemat 40 byte kode atau mengurangi penggunaan satu register. Dulu saya pernah menulis banyak aplikasi GUI sederhana sendiri sambil memakai mingw dan membaca buku Petzold. Sangat menyenangkan melakukan semuanya sendiri, seperti kontrol kustom, menggambar grafis/teks, menangani scroll, hit testing, dan sebagainya. Saya melihat aplikasi Anda memakai strcpy dan sprintf; kalau pemrogramannya dilakukan dengan serius, sebaiknya wajib memakai varian yang memeriksa panjang. Agak mengejutkan kompiler tidak langsung memberi peringatan. Di win32 API ada banyak fungsi yang bisa menggantikan fungsi pustaka standar C. Kalau ingin ukuran executable lebih kecil lagi, saya sarankan coba menulis hanya dengan <Windows.h> tanpa cstdlib. Anda bisa memakai ZeroMemory alih-alih memset, dan CopyMemory alih-alih memcpy. Tentu saja menulis C mentah pada titik tertentu akan terasa sangat menyakitkan, tetapi beberapa kali pertama melakukannya langsung dengan C murni memang paling membantu untuk belajar. Anda jadi membangun kepekaan terhadap detail-detail kecil seperti ini. Jika ingin lebih banyak bereksperimen dengan pemrograman GUI win32, saya juga ingin merekomendasikan WTL (Windows Template Library), karena ia membungkus win32 API dengan C++ sehingga jauh lebih mudah memahami cara kerjanya.
  • Zaman sekarang setidaknya pakailah strncpy daripada strcpy, kalau tidak semua orang akan terus mengomentarinya. Salah satu alasan besar memakai zig adalah karena kesalahan umum seperti ini jadi lebih jarang terjadi. Tentu saja C juga tidak masalah.
  • Soal memakai ZeroMemory alih-alih memset, dan CopyMemory alih-alih memcpy, intrinsic MSVC menggunakan instruksi rep stos/movs sehingga hasil kodenya lebih kecil daripada pemanggilan fungsi, dan ukuran import table juga berkurang.
  • Saya juga dulu sering melakukan ini, dan sejujurnya saya merindukan kemampuan membangun UI native dengan kode native.
  • Ini pertanyaan tentang alasan adanya ZeroMemory dan CopyMemory sebagai pengganti memset dan memcpy: kenapa repot-repot membuat ini alih-alih memakai pustaka standar C yang sudah ada?
• Dulu, daripada susah payah memanggil CreateWindow setiap kali, orang biasanya menulis resource dialog dalam file .rc (Visual Studio juga menyediakan editor dialog) lalu memakai CreateDialog. Dengan begitu semua kontrol dibuat sekaligus. Tinggal tambahkan manifest aplikasi, maka gaya UI modern dan DPI resolusi tinggi juga bisa didukung.
  • Dengan cara ini, dukungan shortcut keyboard seperti perpindahan tab antar kontrol juga otomatis tersedia. Hanya saja hal seperti resize tetap harus ditangani sendiri, tetapi kode untuk itu cepat bertambah dan tidak terlalu sulit.
  • Ini juga muncul di buku Petzold, jadi saya sarankan mencarinya.
• Dulu saya juga pernah membuat hal serupa untuk Linux dalam assembly di bawah 2KiB. Kalau ditulis dalam C dan linked secara dinamis, di Linux cukup mudah membuatnya tetap di bawah 20KiB. Saya kira di Windows malah lebih mudah karena banyak fungsinya sudah tersedia bawaan. Karena itu saya ingin mendukung percobaan seperti ini. Opsi linking di akhir tulisan juga akan membantu mengecilkan ukuran lebih jauh.
• Jika dibuat tanpa framework, hasilnya ada font buram saat DPI scaling, tidak ada dukungan Tab, tidak ada banyak fitur dasar yang sudah lazim sejak sebelum era framework modern seperti Ctrl-A untuk memilih semua di field teks, ada error saat menambah baris, dan seterusnya. Jadi saya penasaran, dari sisi mana ini disebut "modern"?
  • Saya lampirkan contoh pengaturan DPI awareness. Kodenya mencoba mengatur DPI awareness dengan berbagai fungsi Windows tergantung versinya (user32:SetProcessDpiAwarenessContext, shcore:SetProcessDpiAwareness, user32:SetProcessDPIAware), dan jika versinya benar-benar sangat lama maka tidak memanggil apa pun.
  • Kata modern memang kurang cocok; ukurannya terlalu besar tetapi fiturnya kurang (meski perpindahan tab antar kontrol mudah diimplementasikan sendiri).
• Dari sudut pandang orang yang pernah memrogram 6502, kenyataan bahwa 278KB sekarang dianggap ringan itu terasa menyakitkan.
  • Saat saya menganalisis ukuran biner, hambatan pertama adalah build.bat tidak berjalan benar saat pengaturan core.autocrlf=false. Setelah saya ubah menjadi core.autocrlf=true dan clone ulang, build berhasil. Toolchain mingw tertentu menghasilkan .exe berukuran 102KB, jadi jauh lebih efisien daripada 278KB. Kalau ingin lebih kecil lagi, Anda bisa menambahkan flag ekstra ke GCC. Dengan gcc -s -Oz -flto, ukurannya bahkan bisa turun sampai 47KB. Kalau yang Anda pedulikan hanya ukuran biner, masih banyak ruang perbaikan.
  • Ukuran sebesar ini terjadi karena platform dan format executable-nya. Informasi stack trace, infrastruktur dynamic linking, tabel exception handling, dan berbagai hal lain memakan ruang.
  • Saya ingin mengusulkan kategori baru "aplikasi TODO 64KB" di kompetisi demo scene.
  • Sejujurnya saya kaget ukurannya sebesar ini; dulu rasanya, bahkan setelah dikurangi ukuran ikon, hasilnya lebih kecil. Saya penasaran apakah ini karena MinGw.
  • 6502? Itu masih kemewahan. Pada zaman saya, sering kali bahkan tidak ada CPU sama sekali.
  • Ini mengingatkan saya pada masa ketika pemrograman assembly win32 tiba-tiba populer, terutama saat ukuran unduhan shareware mulai membesar. Saya juga jadi teringat pemrograman Palm Pilot 68k awal; seperti nyala terakhir assembly non-retro.
  • Ada juga orang yang membuat quickrun.exe berukuran 15KB, hanya dengan C dan pure Win32 API. Tidak ada trik khusus untuk mengecilkan biner, memakai kompiler Mingw32, dan aplikasinya adalah GUI untuk menjalankan aplikasi dengan cepat lewat alias.
  • Malam ini saya sedang men-debug emulator saya yang mengemulasikan sistem Z80 dengan RAM 64KB. Kadang saya jadi benar-benar merasakan betapa zaman dan lingkungan sudah banyak berubah. Meski begitu, bukankah seiring membesarnya ukuran juga ada kemajuan luar biasa yang sudah dicapai?
  • Dari arsitektur 8-bit ke 64-bit, ukuran pointer alamat saja sudah membesar 8 kali lipat. Jangan mengeluh; cobalah menikmati perubahan ini sebagai sesuatu yang artistik.
  • 278KB itu cuma cukup-cukup saja untuk muat ke floppy disk 5 1/4 inci.
• Aplikasi ini memang cuma dibuat untuk bersenang-senang dan dicoba sendiri. Seperti yang ditunjukkan komentar-komentar, tentu ada cara yang lebih masuk akal seperti memakai C++ atau bahasa lain, tetapi bagi saya yang menyenangkan adalah sekadar mencobanya.
  • Sekitar 30 tahun lalu saya juga membuat program Windows pertama saya dengan cara yang nyaris sama. Bedanya, saya memakai kompiler C++. Pada masa itu, menulis kode bergaya C dengan kompiler C++ memang merupakan cara yang dipandu di dokumentasi resmi. Karena C++ adalah superset dari C, Microsoft juga cenderung mendorong pendekatan seperti itu.
  • Saya benar-benar jauh lebih ingin memakai aplikasi Anda daripada aplikasi to-do bawaan Windows 11.
  • Saat memakai win32 API, bahasa apa pun yang dipakai tidak banyak mengubah esensinya. Malah mengganti bahasa bisa membuatnya lebih membingungkan. Kalau terlalu terobsesi pada gaya C++, itu justru bisa menambah kebingungan bagi orang yang baru belajar win32 API. Menurut saya, membiasakan diri dengan win32 API lewat proyek pribadi sederhana/lucu seperti ini adalah bagian dari fondasi dasar sebagai developer.
  • Saya juga punya aplikasi lain bernama YoutubeGO, jadi saya akan senang kalau Anda sempat melihatnya.
  • Proyek UI native yang rapi seperti ini juga yang dulu memotivasi saya untuk belajar pemrograman, jadi saya paham dan memujinya.
• Di web maupun software, ada budaya memuat JS atau C# berukuran beberapa megabyte hanya untuk mengirim telemetri 278KB; dibanding itu, percobaan seperti ini terasa menyegarkan.
  • Aplikasi serupa yang dibuat dengan C# + WinForms bisa berukuran kurang dari 10KB di disk dan hanya memakai RAM 6MB. Aplikasi ini memakai RAM 1.5MB. Keduanya sama-sama muncul seketika saat dijalankan.
• Sekilas terlihat seperti melakukan static linking pada library; kalau linked dengan DLL, ukuran aplikasi bisa berkurang drastis.
  • Itu agak terbalik. Jika Anda harus mendistribusikan DLL bersama program (artinya DLL itu tidak termasuk dalam OS), setiap DLL membawa runtime C-nya sendiri sehingga justru makin besar. Kalau semuanya ditanam statis ke dalam satu EXE, runtime C hanya ada satu set, dan fungsi yang tidak dipakai mudah dibuang. DLL hanya menghemat ukuran jika beberapa program berbagi DLL yang sama.
  • Melakukan static link terhadap CRT (runtime library) justru menguntungkan untuk mengurangi kode yang tidak perlu. Jika dynamic link ke DLL, terkadang pengguna juga harus mengunduh dan memasang VCRUNTIME DLL dari Microsoft. Di Visual Studio, dynamic linking ke MSVCRT juga tidak selalu mudah, meski tentu ada pengecualian jika Anda harus mematuhi LGPL.
• Ini mengingatkan saya pada File Pilot, file explorer cepat yang baru dirilis belakangan ini, dibuat dengan C dan ukurannya cuma 1.8MB.
• Disebut sebagai aplikasi Todo Windows yang "modern" dan "native", tetapi saya benar-benar ragu apa yang modern di sini. Dan kalau ditulis dengan C++, banyak masalah juga bisa dicegah, global variable bisa dihilangkan, dan dengan std::string, std::array, std::list, anonymous namespace, serta menghapus malloc, Anda mungkin akan melihat panjang kode terpotong setengah dan bug berkurang.
  • Global variable hampir tidak berpengaruh untuk aplikasi sekitar 500 baris seperti ini, dan tujuannya juga jelas. Mengganti ke std::string atau std::list tidak berarti hasil assembly akhirnya akan sama. Komentar itu benar-benar menunjukkan tidak paham bagaimana bagian dalamnya bekerja.
  • Bahkan edisi terbaru buku Petzold dibangun dengan Visual C++ dalam mode C++, dan merekomendasikan sintaks bersama C/C++. Pada era Windows 95, sebenarnya sudah tidak banyak orang yang menulis hampir semuanya murni dalam C; bahasa arus utama saat itu sudah bergeser ke VB, Delphi, dan C++.
  • Terkait saran memakai standard string atau array/list, kalau memang sampai memakai WinAPI langsung, menggunakan LPWSTR (wide string) lebih cocok dengan API dibanding std::string, jadi itu yang saya rekomendasikan. Daripada metode lama seperti char[], LPWSTR lebih disarankan. Saya juga tidak merasa std::array atau std::list akan membuat kodenya lebih baik.
  • Memang tidak modern, tetapi pemrograman yang dekat dengan dasar seperti ini membantu memahami benar-benar bagaimana semuanya bekerja. Masalahnya juga sederhana sehingga mudah dipahami. Saya rasa ini proyek pembelajaran yang bagus. Saya juga penasaran melihat contoh implementasi aplikasi seperti ini dalam versi assembly.

[roxie]

Bro, rasanya seperti embusan napas kalian sampai terasa di sini...