शुद्ध C में native Windows Todo ऐप बनाना (278 KB, framework के बिना)

 (github.com/Efeckc17)
10 पॉइंट द्वारा GN⁺ 2025-05-12 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • यह open source project केवल C और Win32 API से बना एक हल्का native Windows Todo application है
  • किसी framework पर निर्भर हुए बिना यह न्यूनतम आकार (अधिकतम 26.5KB) में चलता है, और advanced Windows GUI व system integration को सीधे implement करता है
  • Todo items जोड़ना, संपादित करना, हटाना, complete mark करना जैसी बुनियादी सुविधाओं के साथ system tray integration और auto-start option जैसी वास्तविक productivity features भी देता है
  • storage binary file के रूप में persistent है, और AppData folder में अधिकतम 100 todo items सहेजता है
  • बड़े frameworks के बिना OS के बेहद करीब classic programming style और हल्का runtime environment इसकी खास ताकत हैं

🌟 Simple Todo (C / WinAPI)

प्रोजेक्ट अवलोकन

  • यह project केवल C और Win32 API का उपयोग करके एक आधुनिक native Windows Todo app बनाता है
  • यह advanced Windows GUI programming और system integration capabilities दिखाता है
  • project का आकार बहुत छोटा है (अधिकतम 26.5KB), और यह Windows का native look and feel बनाए रखता है

✨ मुख्य फीचर्स

  • Todo items बनाना, edit करना, delete करना संभव है
  • tasks को complete mark किया जा सकता है
  • AppData में persistent storage होने से data हमेशा सुरक्षित रहता है
  • system tray के साथ integration है, इसलिए minimize करने पर app tray में चला जाता है
  • इसका look native Windows style में है
  • Windows startup पर auto-run option दिया गया है

🛠️ तकनीकी विवरण

  • पूरा code शुद्ध C में लिखा गया है
  • GUI implementation के लिए केवल Win32 API का उपयोग किया गया है
  • tiny executable size (UPX compression के साथ 26.5KB)
  • system tray integration feature
  • manifest के जरिए modern visual style लागू किया गया है

💾 डेटा स्टोरेज

  • सभी todo items एक ही binary file में store किए जाते हैं
  • storage path: %APPDATA%\\TodoApp\\todos.dat
  • यह binary format है और इसमें अधिकतम 100 items store किए जा सकते हैं

📋 आवश्यकताएँ

  • Windows operating system environment आवश्यक है
  • MinGW-w64 (GCC compiler) और Windows SDK आवश्यक हैं

🎮 उपयोग का तरीका

  • bin/todo.exe चलाने के बाद interface के जरिए ये काम किए जा सकते हैं
  • "Add" button से नया todo जोड़ें
  • item चुनकर "Edit" क्लिक करके उसे बदलें
  • "Delete" से item हटाएँ
  • "Complete" से complete mark करें
  • हर item की priority set की जा सकती है

🏗️ प्रोजेक्ट संरचना

  • src/ folder में main entry point (main.c), todo management logic (todo.c), struct declarations (todo.h), GUI implementation (gui.c) मौजूद हैं
  • bin/ में compiled executable रखा गया है
  • build script (build.bat) और project documentation शामिल हैं

🔧 विकास तत्व

  • Win32 API: window management और पूरे GUI implementation के लिए
  • Common Controls: modern UI elements के उपयोग के लिए
  • UXTheme: Windows visual style लागू करने के समर्थन के लिए
  • File I/O: persistent data storage के लिए

📝 लाइसेंस

  • MIT License के तहत इसे स्वतंत्र रूप से उपयोग और modify किया जा सकता है

🤝 योगदान गाइड

  • Pull Request का स्वागत है
  • कोई भी project में योगदान कर सकता है

📫 संपर्क और लिंक

संबंधित पढ़ाई

3 टिप्पणियां

 
aer0700 2025-05-13

इसमें एक अलग ही रोमांस है।
 
GN⁺ 2025-05-12
Hacker News टिप्पणियाँ
  • win32 GUI प्रोग्रामिंग में मुझे कुछ चीज़ें पसंद हैं, भले ही यह थोड़ी अजीब हो, लेकिन Raymond Chen का ब्लॉग पढ़ें तो वजह समझ आती है। win32 API की शुरुआत 8088 प्रोसेसर के दौर से हुई थी, और इसमें चीज़ें इस तरह की जाती थीं कि 40 bytes कोड बच जाएँ या एक register कम इस्तेमाल हो। पहले मैंने mingw और Petzold की किताब के साथ कई साधारण GUI ऐप्स खुद लिखे थे। custom controls, graphics/text drawing, scrolling handling, hit testing वगैरह सब कुछ हाथ से करना वास्तव में मज़ेदार था। मैंने देखा कि तुम्हारे ऐप में strcpy, sprintf का उपयोग है; अगर प्रोग्रामिंग को गंभीरता से कर रहे हो तो length-checked variants ज़रूर इस्तेमाल करने चाहिए। हैरानी है कि compiler ने तुरंत warning नहीं दी। win32 API में standard C library functions को replace करने वाले कई functions हैं। अगर executable size और कम करना हो, तो <Windows.h> तक सीमित रहकर cstdlib के बिना लिखने की सलाह दूँगा। memset की जगह ZeroMemory, memcpy की जगह CopyMemory इस्तेमाल कर सकते हो। बेशक raw C coding एक बिंदु पर बहुत पीड़ादायक हो जाती है, लेकिन शुरुआत की कुछ बार pure C में खुद करना सीखने के लिए सबसे ज़्यादा मददगार होता है। इससे इन छोटी-छोटी चीज़ों को संभालने का sense बनता है। अगर win32 GUI programming और करना चाहते हो तो WTL (Windows Template Library) भी recommend करना चाहूँगा, क्योंकि यह win32 API को C++ में wrap करके उसके काम करने का तरीका काफ़ी आसान बना देती है
    • आजकल कम से कम strcpy की जगह strncpy तो इस्तेमाल करना ही चाहिए, नहीं तो हर कोई बार-बार टोकता रहेगा। Zig इस्तेमाल करने की एक बड़ी वजह यह भी है कि ऐसी आम गलतियाँ कम हो जाती हैं। वैसे C भी ठीक है
    • memset की जगह ZeroMemory, memcpy की जगह CopyMemory वाली बात पर, MSVC intrinsics rep stos/movs instructions इस्तेमाल करते हैं, इसलिए function call से भी छोटा code बनता है और import table size भी घटती है
    • मैं भी पहले यह बहुत करता था, और सच कहूँ तो native code से native UI बनाने की क्षमता की याद आती है
    • यह सवाल है कि memset और memcpy की जगह ZeroMemory, CopyMemory देने की ज़रूरत क्यों पड़ी; आखिर मौजूदा C standard library के बजाय ऐसा अलग क्यों बनाया गया
  • पहले हर बार मुश्किल से CreateWindow कॉल करने के बजाय .rc files में dialog resources लिखकर (Visual Studio में dialog editor भी मिलता है) CreateDialog इस्तेमाल किया जाता था। तब सारे controls एक साथ बन जाते थे। application manifest जोड़ने पर modern UI style और high-DPI support भी मिल सकता है
    • इस तरीके से controls के बीच tab navigation जैसे keyboard shortcuts अपने-आप मिल जाते हैं। हाँ, resizing जैसी चीज़ें फिर भी खुद करनी पड़ती हैं, लेकिन code को जल्दी बढ़ाया जा सकता है और यह मुश्किल नहीं है
    • यह Petzold की किताब में भी आता है, इसलिए एक बार देखना चाहिए
  • मैंने भी पहले Linux के लिए कुछ ऐसा 2KiB से कम assembly में बनाया था। C में लिखकर dynamic linking करें तो Linux पर 20KiB के भीतर आसानी से बनाया जा सकता है। मुझे लगता है Windows में तो built-in features ज़्यादा होने की वजह से यह और आसान होगा। इसलिए ऐसे प्रयास का समर्थन करना चाहता हूँ। लेख के अंत में दिए गए linking options देखें तो size और कम करना आसान होगा
  • framework के बिना बनाओ तो DPI scaling पर fonts धुँधले हो जाते हैं, Tab support नहीं होता, text field में Ctrl-A select जैसी pre-modern framework की default सुविधाएँ भी ज़्यादातर गायब रहती हैं, row add करते समय error भी है। तो फिर किस मायने में यह "modern" है, यही समझ नहीं आता
    • DPI awareness setting का एक उदाहरण जोड़ रहा हूँ। यह code version के हिसाब से अलग-अलग Windows functions (user32:SetProcessDpiAwarenessContext, shcore:SetProcessDpiAwareness, user32:SetProcessDPIAware) से DPI awareness सेट करने की कोशिश करता है। अगर version बहुत पुराना हो तो कुछ भी कॉल नहीं करता
    • "modern" कहना ठीक नहीं बैठता; यह सिर्फ size में बड़ा है और features कम हैं (हालाँकि controls के बीच tab navigation खुद implement करना आसान है)
  • 6502 पर programming करने के अनुभव से देखें तो अब 278KB को lightweight माना जाना ही तकलीफ़देह है
    • मैं binary size analysis कर रहा था, तो पहली रुकावट यह थी कि build.bat core.autocrlf=false setting पर ठीक से काम नहीं करता। इसे core.autocrlf=true करने और दोबारा clone करने पर build सफल हुआ। mingw का एक खास toolchain 102KB का .exe निकालता है, यानी 278KB से कहीं अधिक efficient। और कम करना हो तो GCC में extra flags दे सकते हैं। gcc -s -Oz -flto से 47KB तक भी संभव है। अगर सिर्फ binary size में रुचि है तो सुधार की बहुत गुंजाइश है
    • यह size platform और executable format की वजह से भी होता है। stack trace info, dynamic linking infrastructure, exception handling tables जैसी कई चीज़ें जगह लेती हैं
    • demoscene प्रतियोगिताओं में '64KB TODO app' category शुरू करने का अनुरोध करना चाहिए
    • सच कहूँ तो इतनी बड़ी size देखकर हैरानी हुई। याद है पहले icon size हटाकर इससे छोटे binaries बनते थे। शायद MinGW की वजह से है?
    • 6502? वह तो ऐश थी। हमारे ज़माने में तो कई बार CPU ही नहीं होता था
    • यह उस दौर की याद दिलाता है जब win32 assembly programming अचानक लोकप्रिय हो गई थी, खासकर जब shareware downloads बड़े होने लगे थे। शुरुआती Palm Pilot 68k programming भी याद आती है। non-retro assembly की आख़िरी चमक जैसी थी
    • किसी ने 15KB का quickrun.exe भी बनाया था। सिर्फ C और pure Win32 API का उपयोग किया गया था। binary size घटाने के लिए कोई trick नहीं, Mingw32 compiler इस्तेमाल किया गया, और यह aliases से ऐप्स जल्दी लॉन्च करने वाला GUI ऐप था
    • आज शाम मैं अपने emulator को debug कर रहा हूँ जो Z80, 64KB RAM system को emulate करता है। कभी-कभी महसूस होता है कि समय और environment कितना बदल गया है। फिर भी size बढ़ने के साथ हमने असाधारण प्रगति भी तो की है
    • 8-bit से 64-bit architecture तक आते-आते सिर्फ address pointer ही 8 गुना बड़ा हो गया। शिकायत मत करो, इस बदलाव को अपने-आप में कला की तरह देखो
    • 278KB तो बस 5 1/4-inch floppy disk में किसी तरह समाने लायक size है
  • यह ऐप बस मज़े के लिए खुद बना लिया गया था। जैसा comments में कहा गया, शायद ज़्यादा व्यावहारिक रूप से इसे C++ या किसी और भाषा में किया जा सकता था, लेकिन मेरे लिए इसे आज़माना ही मज़ेदार था
    • लगभग 30 साल पहले मैंने भी लगभग इसी तरह अपना पहला Windows प्रोग्राम बनाया था। फर्क बस इतना था कि मैंने C++ compiler इस्तेमाल किया था। उस समय C-style code को C++ compiler से लिखना आधिकारिक documentation में guided approach हुआ करता था। C++, C का superset था, इसलिए Microsoft भी अक्सर उसी दिशा में जाता था
    • सच में, मैं तुम्हारा ऐप Windows 11 के default to-do app से कहीं ज़्यादा इस्तेमाल करना चाहूँगा
    • win32 API इस्तेमाल करते समय कौन-सी भाषा है, इससे मूल चीज़ें ज़्यादा नहीं बदलतीं। बल्कि भाषा बदलने से और confusion हो सकता है। अगर C++ style पर ज़रूरत से ज़्यादा ज़ोर दिया जाए तो win32 API पहली बार सीखने वालों के लिए उल्टा चीज़ें और confusing हो सकती हैं। ऐसे simple/cute personal projects के ज़रिए win32 API से परिचित होना एक developer के लिए बुनियादी अभ्यास है
    • मेरा एक और ऐप YoutubeGO भी है, चाहो तो उसे भी देखना
    • इस तरह के साफ़-सुथरे native UI projects ही मुझे programming सीखने के लिए प्रेरित करते थे, इसलिए इससे सहानुभूति भी है और तारीफ़ भी
  • आजकल web या software में 278KB telemetry भेजने के लिए megabytes के JS या C# लोड करने की संस्कृति बहुत है; उसके मुकाबले यह प्रयास ताज़गीभरा है
    • C# + WinForms से बना ऐसा ही एक ऐप disk पर 10KB से कम है और सिर्फ 6MB RAM लेता है। यह ऐप 1.5MB RAM इस्तेमाल करता है। दोनों तुरंत launch हो जाते हैं
  • अभी देखने पर लगता है कि static libraries link की गई हैं; DLL से link करें तो app size नाटकीय रूप से घट सकती है
    • बात कुछ उलटी है। अगर DLLs को साथ ship करना पड़े (और वे OS में शामिल न हों), तो हर DLL में अपना C runtime शामिल हो सकता है, जिससे कुल size और बढ़ती है। अगर सब कुछ static रूप से एक EXE में डाल दो, तो C runtime सिर्फ एक बार शामिल होता है और unused functions को आसानी से हटाया जा सकता है। DLLs तभी size बचाती हैं जब कई programs वही DLL साझा करें
    • CRT (runtime library) को static link करना अनावश्यक code घटाने में फ़ायदेमंद हो सकता है। DLL को dynamic link करने पर कभी-कभी MS का VCRUNTIME DLL अलग से install कराना पड़ता है। Visual Studio में MSVCRT को dynamic link करना हमेशा आसान भी नहीं होता, हालाँकि LGPL compliance की स्थिति में यह अपवाद हो सकता है
  • हाल ही में रिलीज़ हुआ तेज़ file explorer File Pilot याद आ गया, जो C में बना है और सिर्फ 1.8MB का है
  • इसे 'modern', 'native' Windows Todo app कहा जा रहा है, लेकिन सच में इसमें आधुनिक क्या है, यह संदिग्ध है। और अगर C++ में लिखा जाए तो कई समस्याएँ रोकी जा सकती हैं और global variables भी हटाए जा सकते हैं। std::string, std::array, std::list, anonymous namespaces इस्तेमाल करें और malloc हटा दें, तो शायद code आधा रह जाए और bugs भी कम हों
    • global variables का 500 lines के आसपास के ऐप में ज़्यादा असर नहीं पड़ता, और उनका उपयोग भी साफ़ है। std::string, std::list में बदल देने से assembly output वैसा ही नहीं रह जाएगा। इससे लगता है कि अंदरूनी कामकाज की समझ नहीं है
    • Petzold की किताब के नए editions में भी C++ mode में Visual C++ से build किया जाता है और C/C++ common syntax की सिफारिश की जाती है। Windows 95 के ज़माने में भी लगभग सिर्फ C में लिखने वाले लोग कम थे; तब तक VB, Delphi, C++ जैसे mainstream languages आ चुके थे
    • standard string या array/list इस्तेमाल करने वाली राय पर, अगर आप सीधे winapi इस्तेमाल कर रहे हैं तो std::string की जगह LPWSTR (wide string) API के साथ ज़्यादा naturally फिट बैठता है और वही recommend किया जाएगा। char[] जैसे पुराने तरीके से बेहतर LPWSTR है। std::array या list से code शायद बेहतर नहीं होगा
    • यह modern नहीं है, लेकिन fundamentals के करीब वाली programming असली काम करने के तरीक़े को ठीक से समझने में मदद करती है। समस्याएँ भी सरल होती हैं, इसलिए समझना आसान है। सीखने के लिए यह एक अच्छा project लगता है। assembly version में ऐसा ऐप देखना भी रोचक होगा
 
roxie 2025-05-16

लगता है बड़े भैया की साँस की गर्मी यहाँ तक पहुँच रही है...