Duże projekty, a biblioteki?

Przeniosłem tu dyskusję z tego listu:
https://4programmers.net/Forum/1578599

Odpowiadając na ostatnie pytanie:

1. Tak. W 95 roku zacząłem pisać Kombi w OWL-u. I tak było przez kilka lat, dopóki OWL nie umarł. Wtedy stanąłem przed dylematem - pisać od nowa, zarzucić projekt zupełnie, czy ciągnąć tego OWL-a na własną rękę. Na szczęście były kody źródłowe.
   Po zapoznaniu się ze źródłami, zacząłem podmieniać coraz większe kawałki własnym kodem.
   Wtedy stwierdziłem, że mogłem to zrobić od początku samemu, byłoby lepiej i miałbym pełną kontrolę, bo większość klas w tej bibliotece nie wnosi żadnego wkładu własnego.
   To są po prostu funkcje systemowe zapakowane w klasę i udostępnione w obiektowym interfejsie. Być może w innych bibliotekach jest inaczej, ale cudów bym się nie spodziewał.
   Teraz nadal jądro tego OWL-a w programie siedzi, ale mam to opanowane i w niczym mi już teraz to nie przeszkadza.

2. Program, poza interfejsem i kontrolkami musi jeszcze coś robić. Szacuję, że interfejs, to maks. jakieś 30% kodu.
   A reszta? Reszta jest związana z konkretną dziedziną. Ja zajmuję się DTP i nie bardzo widzę wsparcie tej dziedziny w gotowych bibliotekach (może w innych dziedzinach jest inaczej).

3. Żeby była jasność - nie twierdzę, że nie należy sobie życia ułatwiać i nie stosować klas i obiektów.
   Chodzi mi tylko o fakt wiązania (i uzależniania) dużego projektu od obcego kodu.
   Jakbyś zaczął pisać bez zewnętrznych bibliotek, to szybko byś stworzył własny system klas. I dalej pisałbyś tak samo szybko (albo nawet zdecydowanie szybciej).
   Ale jednak - byłbyś niezależny.

4. Ciekaw jestem jak na to spojrzysz za kilka (kilkanaście) lat.

5. Jedyne co do mnie przemawia - to wieloplatformowość. To jest jakiś atut.

Zależy, jest parę rzeczy, które trzeba uwzględnić przy decyzji:

• Jak dużo zależy od tego kodu?
• Jak dużo kodu muszę zmienić by móc używać tego?
• Jak duże jest API z którego będziemy korzystać?

A to o czym mówisz ma nawet swoją stronę na Wikipedii: Not Invented Here

Więc tak, nie zawsze warto pchać się w zależności, ale nie należy też popadać w paranoję i w imię "kontroli" pisać wszystko samemu od zera.

hauleth napisał(a):

Zależy, jest parę rzeczy, które trzeba uwzględnić przy decyzji:

• Jak dużo zależy od tego kodu?
• Jak dużo kodu muszę zmienić by móc używać tego?
• Jak duże jest API z którego będziemy korzystać?

A to o czym mówisz ma nawet swoją stronę na Wikipedii: Not Invented Here

To chyba sytuacja odwrotna - był program korzystający z zewnętrznej biblioteki (OWL) którą producent (Borland) porzucił zastępując nową (VCL).
Co nam pozostaje? a) trwać przy martwym starociu, b) przepisywać całość na nowe API, c) przepisywać stopniowo kod na własny.

"Not invented here" rozumiem jako taką trochę irracjonalną niechęć do zewnętrznych bibliotek - ale często chęć pozbycia się jakiejś libki z projektu jest zupełnie uzasadniona.

Biblioteka zewnetrzna ma sens gdy chcesz coś osiągnąć szybko i planujesz używać standardowych rozwiązań. W innym przypadku gdy piszesz projekt innowacyjny i planujesz rozwijanie niestandardowych rozwiązań pisz własną bibliotekę.
Podobnie działa rynek gier, mniejsi gracze zwykle korzystają z bibliotek jak unity/udk chyba że planują jakieś niestandardowe rozwiązania wtedy piszą własne silniki.
Generalnie tworzenie wszystkiego od zera stanowi duży koszt wejściowy, który zwraca się z czasem i ma sens gdy będziemy nad tym pracować długo np tworzysz silnik 3d który wykorzystasz w wielu grach i jeszcze np sprzedażą do niego licencję.
Kiedy jesteśmy nastawieni na szybki efekt i krótki czas życia biblioteki to lepiej korzystać już z gotowych rozwiązań

Biblioteka zewnetrzna ma sens gdy chcesz coś osiągnąć szybko i planujesz używać standardowych rozwiązań. W innym przypadku gdy piszesz projekt innowacyjny i planujesz rozwijanie niestandardowych rozwiązań pisz własną bibliotekę.

Nie zgodzę się. Nawet jak robisz coś innowacyjnego, to jest to raczej "kreatywne" składanie rzeczy, które już istnieją. A jeśli opracowujesz swój algorytm/rozwiązanie, to z reguły to jest właśnie twoja aplikacja, więc ciężko nazwać to "własną biblioteką".

hauleth napisał(a):

A jeśli opracowujesz swój algorytm/rozwiązanie, to z reguły to jest właśnie twoja aplikacja, więc ciężko nazwać to "własną biblioteką".

Całkowita nieprawda... przykład, pisze grę, tworze do niej własny silnik, używam go wielokrotnie dla różnych projektów więc już mam bibliotekę + wiele aplikacji.
Zakładam że nie korzystam z gotowców ponieważ tworze nieszablonową grę i gotowce na to nie pozwalają ze względu na wymuszoną budowę.

Zwyczajnie uprościłeś że zawsze aplikacja to prosty twór, bez komponentów do ponownego użycia.

Poza tym korzystanie z OpenGL to też używanie "biblioteki", ale można korzystać z nakładek(bibliotek), które upraszczają prace. Jeżeli korzystamy z nakładek to znowu możesz używać kilkudziesięciu małych bibliotek np jedna do odczytu modeli 3d inna do przetwarzania grafiki lub wziąć jedną wielką bibliotekę typu unit / UE4 / CryEngine.
Praktycznie zawsze korzystamy z bibliotek, kwestia tego jak nisko chcemy operować.

Jeżeli korzystamy z wielu małych to możemy zamknąć to w jednej własnej bibliotece i ją rozwijać raze z innymi projektami.

Korzystamy z zewnętrznych bibliotek jeśli są spełnione wszystkie poniższe wymagania jednocześnie:

• jeśli dobrze realizują oczekiwane funkcje i są przyzwoitej jakości
• jeśli mają dobre wsparcie, czy to społeczności czy jakiejś firmy
• jeśli oferowana przez nie funkcjonalność nie jest elementem naszej przewagi konkurencyjnej

Lub:

• jeśli zależy nam na czasie a nie jakości (tak prawie nigdy nie jest)

Niestety eliminuje to pewnie dobre 90% oprogramowania otwartego.

W pozostałych przypadkach piszemy własne i na ogół znacznie lepiej na tym wychodzimy.
Im dłużej projekt istnieje tym jest silniejsza tendencja do wyrzucania z niego otwarto-źródłowych kobył na rzecz własnych, specjalizowanych rozwiązań, bo na dłuższą metę poprawianie błędów w cudzym kodzie jest trudniejsze niż poprawianie we własnym. W przypadku polegania na bibliotekach otwartych, de facto i tak musimy serwisować je sami, bo czekanie aż społeczność naprawi krytyczny błąd nie wchodzi w grę, gdy klienci płacą grube $$$ za wsparcie. Dlatego lepiej napisać specjalizowaną bibliotekę, która będzie 10x mniejsza od kobyły ogólnego przeznaczenia - to zawsze 10x mniej kodu do utrzymania.

Całkowita nieprawda... przykład, pisze grę, tworze do niej własny silnik, używam go wielokrotnie dla różnych projektów

Wyróżnienie moje.

Wtedy racja, ale to oznacza, że Twoja biblioteka nie jest już tak wyspecjalizowana, tylko jesteś z nią zaznajomiony. Więc wracamy do problemu NIH.

By nie było, sam uważam, że mnożenie bytów nas potrzebę jest bezsensowne, ale to dotyczy się wszystkiego:

• jeśli coś jest duże i zostało już zrobione, to często warto tego użyć, bo będzie łatwiej (przykład z własnego podwórka, byłbym w stanie napisać serwer HTTP w Erlangu/Elixirze, ale nie ma sensu się w to bawić, skoro mamy już gotowe i bardzo dobre rozwiązania, nawet jeśli miałbym jakieś pomysły na to jak to rozwiązać lepiej, to w większości nie ma to najmniejszego sensu)
• jeśli coś jest małe, to często łatwiej to napisać samemu, zwłaszcza jeśli to jest tylko parę linijek; w ten sposób unikniemy bezsensownych zależności (ex. left-pad) i mamy mniejszą szansę, że coś przestanie działać

jeśli coś jest duże i zostało już zrobione...

Jeśli coś jest duże, to niestety również ma:

• wysoki koszt wejścia w projekt dla nowych programistów
• wysoki koszt poprawiania błędów
• wysoki koszt aktualizacji

Piszę z perspektywy osoby, która nie raz poprawiała krytyczne błędy w dużych bibliotekach lub frameworkach takich jak Netty, Spring, Apache HttpClient czy Apache Spark.
Utrzymywanie takiej kobyły bywa problematyczne, im większa ona jest i im bardziej krytycznych rzeczy w projekcie dotyczy. Konieczność aktualizacji, gdy nagle kończy się wsparcie i musisz przejść z takiego Sparka 2.0 na 2.2 a potem na 2.4 itp. albo z Netty 4.x na 5.x boli mocno. Niestety nie zawsze kompatybilność jest zachowana.
W pewnym momencie okazuje się, że zamiast rozwijać nowe funkcje, to przez ponad połowę czasu zajmujesz się aktualizacjami i pielęgnowaniem bibliotek i frameworków zewnętrznych.

Warto używać rzeczy dużych tylko jeśli masz gwarancję wsparcia od firmy trzeciej z odpowiednim SLA, która to za Ciebie będzie utrzymywać swój kod i daje gwarancje kompatybilności, albo masz na tyle mocnych programistów, że potrafią wejść w projekt na milion linii i odszukać tę spartoloną linijkę w szybkim czasie i to pod presją klientów nad głową... Ponadto, klientów nie obchodzi, czy wysypał się Twój kod, czy biblioteka zewnętrzna. Ma działać. Opierając swój kod o cudzy kod, bierzesz odpowiedzialność za błędy w cudzym kodzie.

Tak czy inaczej, używanie darmowej biblioteki nie jest wcale darmowe i ostatecznie to decyzja biznesowa - czy opłaca się płacić X za utrzymanie rozwiązania zewnętrznego, czy opłaca się zapłacić Y za zbudowanie i utrzymanie rozwiązania wewnętrznego.

A, i obowiązkowa lektura w temacie, aż dziw, że nikt nie podlinkował wcześniej:
https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/

W sumie to większość problemów wymienionych dotyczy frameworków.
Jest (niestety obecnie dość płynna) granica między bilbliotekami, a frameworkiem.
https://www.quora.com/Whats-the-difference-between-a-library-and-a-framework

(moja prywatna definicja jest taka, że bliblioteki możesz mieć dwie (lub więcej) do tego samego (np. do obsługi plików),
a framework trudno jest mieć więcej niż jeden dla danego zastosowania (np. framework do GUI).

Zasadniczo wymienianie bibliotek i zależność od bibliotek tak nie boli, ale framework prawie zawsze oznacza jakieś kłopoty, i dokładnie, być może zyski przewyższają kłopoty... a być może nie. Zależy od horyzontu czasowego i specyfiki projektu.

@hauleth Chciałbym tu uściślić temat. Otóż w pierwszym liście wątku w zasadzie nie pytam, a wypowiadam swoje zdanie na ten temat. Ponieważ w innym wątku, przy okazji zupełnie innego pytania rozwinęła się dyskusja na ten temat, a w komentarzach nie ma miejsca na długie odpowiedzi - postanowiłem swoje zdanie wypowiedzieć właśnie w nowym wątku.
I podtrzymuję to zdanie, mianowicie - to zależy jak ta "otoczka" ma się do całości. Jeśli całość jest duża, to siłą rzeczy ta otoczka (interfejs) stanowi małą część całości i wtedy nie ma sensu oszczędzanie na tej małej części. Wtedy, wg mnie, lepiej to zrobić samemu tak, żeby całość była "samodzielna'.
Ponadto duży projekt ma długi czas życia, to też wskazuje na to, że warto rozważyć odcięcie się od kodu obcego (bo nie wiadomo, co komu przyjdzie do głowy po iluś tam latach).
Przy małych projektach - może być odwrotnie. Czas potrzebny na zrobienie "otoczki" może być porównywalny z czasem oprogramowania głównej funkcjonalności, a na dodatek mały projekt szybko umrze więc problemu nie będzie :-).

Zastanawia mnie jednak inna sprawa, otóż na forum jest bardzo mało pytań (wątków) dotyczących czystego API Windows. Czasem ktoś o coś pyta i jest to pytanie dotyczące jakiejś konkretnej biblioteki (frameworka). Ja wiem jak to zrobić w API i to jest czasem dosłownie kilka linijek kodu. Ale moje odpowiedzi mogą być bezużyteczne. I zastanawiam się skąd taka niechęć do czystego API. Nawet dla małego projektu (np. aplikacji w postaci arkusza właściwości czy kreatora) - napisanie tego w API - to jest plik z zasobami i wypełnienie kilku struktur. To samo z użyciem bibliotek - to masa niepotrzebnego kodu i uwiązania.
Oczywiście sam arkusz właściwości, czy kreator niczego nie robi, tak czy siak tę główną funkcjonalność trzeba dodać.
Tu np. jest prosta aplikacja https://vg.3n.com.pl/topic/vg/version w postaci kreatora. To jest napisane w czystym API Windows. Nie potrzebuje żadnych zewnętrznych dll-i, nie wymaga instalowania w systemie żadnych dodatkowych komponentów. I tak naprawdę - 90% czasu pracy nad tym to było układanie tych kontrolek w edytorze zasobów. Więc po co miałbym do tego używać ciężkich armat?

Nie piszę nic na Windowsa, więc teraz będę trochę strzelał, jeśli strzelę w ciemno, to proszę nie bić:

skąd taka niechęć do czystego API

Może nie niechęć, ale mam wrażenie, że MS również stara się "zniechęcić" ludzi do czystego WinAPI, a zamiast tego proponuje używanie API poprzez .NETowy wrapper. Ma to sens z ich punktu widzenia, bo wyższy poziom pozwala im na więcej rzeczy, oraz daje "łatwiejsze API" dla większości zastosowań.

nie wymaga instalowania w systemie żadnych dodatkowych komponentów

IIRC to nowe wersje Windowsa przychodzą z preinstalowanym .NETem (wydaje mi się, że kiedyś gdzieś słyszałem, że część runtime wylądowała w kernelu, ale nie jestem pewien), więc też nie trzeba już nic instalować. A tak jak powiedziałem wcześniej, C# jest "łatwiejszy" w obyciu od C++ (praktycznie wszystko jest łatwiejsze w obyciu od C++ swoją drogą).

90% czasu pracy nad tym to było układanie tych kontrolek w edytorze zasobów

A pozostałe 10% zajęło by zdecydowanie więcej czasu osbom niezaznajomionym z C++. MS stawia teraz na technologie kontrolowane przez nich. Zobacz, że taki jest ogólny trend w całości natywnego developmentu:

• Apple stawia na stworzonego przez nich Swifta
• Google stawia na Kotlina, dzięki czemu będą mieli duży wpływ na to jak język będzie się rozwijał (z pozostałych technologii to stawiają na Go i starają się jeszcze raz przepchać Darta poprzez Fluttera, wszystko kontrolowane przez nich)
• Mozilla stawia na Rusta (który jak nie jest w całości kontrolowany przez nich, tak powstał w ich stajni oraz dużo jest podporządkowane rozwojowi Servo)
• MS stawia na C# oraz TypeScripta, oba z ich podwórka

Więc skoro "producent" niespecjalnie promuje "surowe" WinAPI, to automatycznie jest mniej developerów, którym się chce i wolą postawić na łatwiejszą technologię, która ma więcej materiałów.

Stefan_3N napisał(a):

Tu np. jest prosta aplikacja https://vg.3n.com.pl/topic/vg/version w postaci kreatora. To jest napisane w czystym API Windows. Nie potrzebuje żadnych zewnętrznych dll-i, nie wymaga instalowania w systemie żadnych dodatkowych komponentów. I tak naprawdę - 90% czasu pracy nad tym to było układanie tych kontrolek w edytorze zasobów. Więc po co miałbym do tego używać ciężkich armat?

Przepraszam, ale musiałem: coś chyba nie poszło w układaniu tych kontrolek, bo ta aplikacja po uruchomieniu na moim komputerze daje coś takiego:

Windows 10, rozmiar tekstu 150%

Tudzież:

Czemu WinAPI nie jest popularne? Wg mnie, w znamienitej części wynika to z czasu. Dziś produkt ma wyjść na rynek szybko, już, wczoraj. Co będzie za kilka lat z daną bilioteką/frameworkiem? No jak co, jak trzeba będzie, to się poprawi klientowi, za dodatkowe pieniądze. Produkt działa zgodnie z wymaganiami? I dobrze. Jedziemy dalej.
Tak wg mnie to dziś niestety działa. A do WinAPI trzeba trochę czasu i zrozumienia. No i to generalnie czyste C.

Wszystko można samemu zrobić, mieć na wszystkim kontrolę, wiedzieć co gdzie jest.. ale czy zawsze ma to sens i jest ekonomicznie uzasadnione? Na pewno nie zawsze. Zawsze jest jakiś if ;)

Nowsze wersje Windows pozwalają na ustawienie różnego DPI na różnych ekranach. Żeby to super działało wymaga supportu ze strony aplikacji (odpowiedni manifest i reagowanie okna na WM_DPICHANGED).
https://docs.microsoft.com/en-us/windows/desktop/hidpi/high-dpi-desktop-application-development-on-windows
– link do jednej z podstron wyrzuca 404, oto ta podstrona:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt846517(v=vs.85).aspx

Ostatni screen z brakiem polskich liter sugeruje że program używa nieunikodowych wersji funkcji WinAPI, a w systemie ustawiona jest niepolska strona kodowa.
Żeby to naprawić trzeba by było sporo w programie przerobić na Unicode (zwłaszcza w tym niby OWL).

Już pomijam że użyta czcionka to jakiś MS Sans Serif z czasów Windows 95. Aktualnie zalecanym krojem jest Segoe UI rozmiar 9.

1. No właśnie ten program jest napisany w czystym API, więc nie jest to problem tego niby OWL-a.

2. Nie jest to też raczej problem dpi (wcześniej to też sprawdzałem), a wczoraj tym bardziej sprawdziłem na kilku komputerach, z podłączonymi kilkoma monitorami i ze zmianą dpi na różnych monitorach. Zawsze jest dobrze :-) (przynajmniej u mnie - i na dostępnych dla mnie komputerach).
   Ale tak to jest z testowaniem - u siebie zawsze działa ;-)

3. Jeśli chodzi o czcionkę, to nie jest ona nigdzie jawnie ustalana (ani w programie, ani w zasobach). Ma przyjąć taką jaka jest ustawiona w systemie (przynajmniej takie jest założenie).

4. Niestety nie sprawdzałem programu na systemach z ustawioną inna wersją językową i prawdopodobnie tu jest przyczyna.
   Rzeczywiście program nie jest skompilowany jako Unicode.

5. Nie wgryzałem się w temat, ale czy aby nie jest tak, że w systemach z inną (niż polska) wersją językową, trzeba doładować (uaktywnić) odpowiedni zestaw znaków? (będę miał wolną chwilę, to zbadam temat, na razie absolutnie się temu nie przeglądałem więc nie wiem jak jest - może ktoś wie?) Prawdopodobnie w wersji unicode problemu by nie było, ale tu nie chodzi o ten program, który jest w sumie mało istotny i mógłbym go w jedno popołudnie przerobić na uniode. Martwię się już o Kombi, bo tam - to nie jest jedno popołudnie :-). Co prawda nikt z dotychczasowych użytkowników takiego problemu nie zgłaszał, program jest przeznaczony do składu tekstu w języku polskim, więc prawdopodobnie wszyscy mają wersje polskojęzyczne systemu, ale kto wie. Przydałoby się inne rozwiązanie (poza zmianą wszystkich zasobów i programu na unicode).

6. Ale jest to też ciekawe właśnie w temacie bibliotek i API. Czy użycie jakiejś biblioteki rozwiązałyby ten problem z automatu? Jeśli nie (a sądzę, że nie), to szukaj wiatru w polu. W tej sytuacji przynajmniej mam uproszczone zadanie :-). Wystarczy że zrobię jeden prosty (testowy) dialog w API i doprowadzę do sytuacji, w której będzie poprawnie wyświetlał się na różnych systemach. Jeśli to zrobię, to temat mam rozwiązany.
   W przypadku użycia bibliotek, temat mógłby być poważniejszy (np. konieczna zmiana/aktualizacja biblioteki z niepewnością co przy okazji). Jak dla mnie - ta sytuacja jeszcze bardziej przekonuje mnie o dużym ryzyku korzystania z bibliotek.
   Tu mam czystą sytuację - dialog w zasobach i procedura dialogu w programie. Żadnych pośredników.
   Chociaż z drugiej strony - być może użycie biblioteki (i napisanie tego nie w czystym API) spowodowałoby, że problem by w ogóle nie wystąpił? Tego niestety nie wiem.

7. Pomijając wszystko - dziękuję za potestowanie :-). Mam nadzieję, że mimo wszystko, są komputery (poza moim), na którym program odpala się prawidłowo :-).
   I przy okazji zadam jeszcze pytanie - program przed odpaleniem musiał być rozpakowany (najpierw uruchamia się taki mini instalator). Czy interfejs tego programu rozpakowującego też był wadliwy?

Stefan_3N napisał(a):

2. Nie jest to też raczej problem dpi (wcześniej to też sprawdzałem), a wczoraj tym bardziej sprawdziłem na kilku komputerach, z podłączonymi kilkoma monitorami i ze zmianą dpi na różnych monitorach. Zawsze jest dobrze :-) (przynajmniej u mnie - i na dostępnych dla mnie komputerach).

Jak widać nie zawsze...

3. Jeśli chodzi o czcionkę, to nie jest ona nigdzie jawnie ustalana (ani w programie, ani w zasobach). Ma przyjąć taką jaka jest ustawiona w systemie (przynajmniej takie jest założenie).

Domyślna w systemie dla kontrolki z tekstem to nie znaczy że jest zalecana jako podstawowa czcionka GUI.
Dla aplikacji w stylu Windows 2000 i XP zalecana była Tahoma o rozmiarze 8. Począwszy od Visty, jest to Segoe UI o rozmiarze 9.
Tych fontów używa też sam Windows w różnych oknach.

https://docs.microsoft.com/en-us/windows/desktop/uxguide/text-ui

5. Nie wgryzałem się w temat, ale czy aby nie jest tak, że w systemach z inną (niż polska) wersją językową, trzeba doładować (uaktywnić) odpowiedni zestaw znaków? (będę miał wolną chwilę, to zbadam temat, na razie absolutnie się temu nie przeglądałem więc nie wiem jak jest - może ktoś wie?)

Właściwym rozwiązaniem byłoby przerobienie aplikacji na Unicode. Raczej nie brnij w strony kodowe.

Skoro już dyskutujemy o tym czy używać bibliotek, czy nie, w czym programować, a w czym nie i w ogóle jakie decyzje strategiczne podejmować, to pochwalcie się proszę swoimi produkcjami.
Ja nie ukrywałem (i chyba już o tym pisałem), że należę do tzw. "leśnych dziadków" :-). W 95 zacząłem programować na PC, a wcześniej kilka lat na Atari (http://atariki.krap.pl/index.php/Inkaust).
W 2008 miałem trochę dość programowania i przestałem. Trochę podróżowałem :-), więc wypadłem z tematu. Pod koniec 2017 wróciłem na ziemię i zacząłem od reanimowania Kombi. To się udało, ale mam świadomość, że ten niby OWL - to nie jest rozwiązanie.
Postawiłem na API. No ale nie jestem zamknięty na nowinki i jeszcze kilka lat do emerytury mi zostało :-).
Chętnie zobaczyłbym Wasze produkcje z krótką informacją w czym zrobione, jakie były problemy (o ile były), czy jesteście zadowoleni z przyjętego rozwiązania.

Stefan_3N napisał(a):

Zastanawia mnie jednak inna sprawa, otóż na forum jest bardzo mało pytań (wątków) dotyczących czystego API Windows. Czasem ktoś o coś pyta i jest to pytanie dotyczące jakiejś konkretnej biblioteki (frameworka). Ja wiem jak to zrobić w API i to jest czasem dosłownie kilka linijek kodu. Ale moje odpowiedzi mogą być bezużyteczne. I zastanawiam się skąd taka niechęć do czystego API.

Też jestem leśny dziadkiem i programowałem w latach 90tych (końcówka, po windows 95) na gołym api Win32. (C++, ale nawet przez chwilę starałem sie podejść do tego przez ASM).
I moim zdaniem to API to po prostu beznadzieja. Funkcjonalność szeroka, ale nie ma nic z elegancji ani porządku.

Wcześniej miałem do czynienia z Amigą i jej amiga OS, w pełni 32 bitowy system, oparty o przesyłanie wiadomości: (https://wiki.amigaos.net/wiki/Intuition_Library ). Tam też nie wszystko było piękne, ale tak bryndzowato jak Win api nie wyglądało. (A API amigi było z lat 80tych, a faktycznie nawet wcześniejsze).

Fakt, że największy żart to było Win16, i zarąbiste zarządanie pamięcią :-), ale to udało mi się ominąć.

A ja tam uważam, że z porządkiem w WinAPI wcale nie jest źle. W czasach z modemowym dostępem do netu, szukaniem błędów z pomocą zainstalowanego SDK, a nie na Stacku - dawało radę.
Jako, że dużo używałem BitBlt i innych, to szczególnie zapamiętałem sobie, że generowała ona kod w locie i go uruchamiała:

The second version of Bit­Blt generated code on the fly. Specifically, the Bit­Blt function generated code onto the stack which performed the block transfer with the appropriate operation, and then called the code as a subroutine.
// https://devblogs.microsoft.com/oldnewthing/20180209-00/?p=97995

Odnośnie pochwalenia się swoimi rzeczami: założę się, że może na palcach jednej ręki znalazłoby się tu osób, które napisały coś swojego, co rozmiarem funkcjonalności przypominałoby Kombi i spółkę ;) A to co jest napisane dla pracodawcy...
Moje największe apki, dla jednego pracodawcy, do obsługi jego urządzeń, komunikacji z nimi, generowania animacji, wgrywania nowego firmware'u miały po kilkanaście tysięcy linii kodu. Max ok. 20 k. Było ich tam coś pod 10 sztuk. Aczkolwiek była to zawsze radocha, jak się szło przez jakieś miasto i się widziało (w sumie widzę nadal) efekty działania swojego kodu na żywo :) W Builderze, VCL'u i promilem WinAPI ;)
A teraz to kwestia projektu, głównie C++11/14/17, Qt, refaktoring obcego kodu, portowanie Win->Lin i inne..