Sens nauki WinAPI.

Witam wszystkich.

Chciałem zadać parę pytań. Na początek może, czy warto się uczyć WinApi w aktualnych czasach, czy lepiej dać sobie spokój i od razu się zabrać za jakiś framework? Dla sprecyzowania chodzi mi o język c++. Kolejne moje pytanie, to czy znając WinApi można śmiało pisać aplikacje okienkowe w powiedzmy CodeBlocksie, bez dodatkowej instalacji wyżej wspomnianych frameworków? Tylko jak już wspomniałem..... czy to jest sensowne w aktualnych czasach, ponieważ znalazłem parę artykułów, w których WinApi jest traktowana jako prehistoria ;)

Pozdrawiam.

Cześc.

Odpowiem z perspektywy własnej. Obsoby znającej najlepiej tylko Delphi i Pascala, ale nie pracującej w ogóle w branży IT. Piszącej amatorsko i dla siebie. W WinAPI piszącej od kilku lat. Według mnie to jest sens się uczyć. Wiedzy nigdy za mało, lepiej coś potrafić więcej niż grać tylko w majnkrafty i do tego całe dnie przeglądać filmiki z kotkami itp. Chociaż koty są spoko, sam mam kotkę, to tak btw :)

W WinAPI fajnie się mi pisze pod Delphi. Masz większą kontrolę nad tym co robisz, kod jest mniejszy, wszystko jest zgrabniejsze. Jest oczywiście więcej pisania, jest problem by wygodnie wyklikać sobie jakiś dialog albo okno z użyciem na przykład ResEd'a. Ale idzie to ogarnąć. Poza tym z każdym, nawet małym kodem poszerzasz sobie bazę gotowców własnych. Póżniej to poscalasz w osobne pliki nagłowkowe czy moduły i ogołnie pisząc coś nawet innego, to część poprzednich rozwiązain zaplikujesz przez kopiuj/wklej. Ponieważ wiadomo, nie ma sensu się męczyć i wynajdować koło na nowo ;)

Wiadomo też, że ofert pracy za wiele nie ma, ale zależy jak do tego podchodzić, przy ktorejś rozmowie o pracę, pokazesz część amatorskiego portoflio i gościu z rekturacji, o ile będzie kumaty, popatrzy że coś fajnego stworzyłeś i jest maulyteńkie, dosłownie kilkanaście kilkadziesiąt kilobajtów exeka bez upxowania. Wiadomo, że dzisiaj dyski i łącza ogarną wiele, ale nieraz potrzeba zgrabnego kodu. Załóżmy, że chcesz zrobić prosty instalator, który coś dociągnie z sieci i poinstaluje.

Na przykład taki NSIS, jakby to miałó wyglądac jakby instalka dożucała ponad 2 MB do exeka, jak pusta formatka w Lazarusie. Ludzie by później chcieli pisać w tym komertcyjnie instalkę jakiejś swojej gry, a tutaj dupa, bo potrzeba zamówić jeszcze extra jedną płytę DVD w tłoczni do każdego pudełka, bo się nie mieści już nic przez wielką instalkę ;) A oni wolą ciąć koszty itp. Oczywiście ironizuje nieco, ale przypadek całkiem realny i może mieć miejsce.

Podsumowując polecam WinAPI, jeśłi masz wiele samozaparcia i jesteś ambitny, nie zrazisz się po dwóch dniach, a do tego dobrze znasz C++ to znajdziesz na pewno więcej kursów online czy ksiązek i to po polsku, niż przykładów dla Delphi. Co do pytania o frameworki nie pomogę, bo nie pisze w nich pod C++. Tutaj pewnie ktoś inny coś jeszcze Tobie doradzi. Także powodzenia życzę i sorry za rozpisanie się ;P

daj sobie spokoj z WinApi i zapoznaj sie z Qt jezeli myslisz powaznie o karierze programisty.

To nie jest tak ze sie nie uzywa WinApi, ale duzo wiecej ofert pracy znajdziesz w Qt. Do tego jest wygodniejsze i przyjemniejsze niz WinApi

Ostatnia rzecza, uczac sie WinApi bedziesz tylko skazany na windowsa, uczac sie Qt nie ma znaczenia jaka platforma docelowa

argumentow za i przeciw oczywiscie jest masa (ja widze wiecej minusow uczenia sie winapi jako pierwsza rzecza). Jezeli chcesz je znac polecam poszukac tutaj na forum ;) Temat byl dosc dobrze poruszany jakis czas temu

To ja może coś dopowiem, ponad to co podał @olesio; Również odniosę się do Delphi/Lazarusa, jednak WinAPI jest jedno, uniwersalne i niezależne od języków programowania (chyba że od tych, które nie oferują importów);

morti napisał(a)

Na początek może, czy warto się uczyć WinApi w aktualnych czasach, czy lepiej dać sobie spokój i od razu się zabrać za jakiś framework?

Ręczne rzeźbienie w WinAPI całych projektów dziś nie ma większego sensu (w kontekście aplikacji okienkowych/gier); Zysk jest nieznaczny (rozmiar pliku wykonywalnego czy biblioteki DLL to akurat najmniejszy plus), natomiast czasu i wiedzy potrzeba krocie więcej; Korzystanie ze znanych od lat dobrodziejstw (dla Lazarusa i Delphi to odpowiednio LCL i VCL) to standard, zapewniający o wiele mniejszy próg wejścia, a także większą wygodę pracy (mnóstwo gotowych klas, komponentów, a także designer formularzy) i poważną oszczędność czasu;

Jednak tego typu wynalazki jak potężne biblioteki komponentów to tylko połowa sukcesu; Często istnieje konieczność komunikacji aplikacji z systemem i do tego celu właśnie nadaje się API systemu; Potrzeba użyć konkretnej funkcji z systemowej biblioteki, której wrapper nie istnieje w bibliotece standardowej/komponentów to sobie importujemy funkcję i używamy; Taki import często związany jest z wykorzystaniem konkretnych typów (np. specjalnych struktur danych, dedykowanych dla danej funkcji lub ich zbioru);

WinAPI przydaje się także do różnych modyfikacji okien; Sam korzystam z kilkunastu (a może i więcej) takich funkcji, np. do tworzenia i sprawdzania istnienia muteksów, pobierania ścieżek do systemowych katalogów, blokowania i odblokowywania przycisków na belkach tytułowych okien; Ich znajomość jest konieczna, aby móc idealnie dostosować okna i ich zawartość, czego nie można zrobić w inny sposób (bo wrapperów brak);

Natomiast aplikacje desktopowe to tylko jedna gałąź całego drzewa projektów, w których systemowe API jest przydatne/konieczne;

Kolejne moje pytanie, to czy znając WinApi można śmiało pisać aplikacje okienkowe w powiedzmy CodeBlocksie, bez dodatkowej instalacji wyżej wspomnianych frameworków?

Oczywiście że można - trzeba tylko sporo rzeczy najpierw się dowiedzieć; No i sporo kodu naklepać na początku pracy nad danym projektem, aby wyświetlić sam goły formularz; Minusem jest niska czytelność takiego kodu, co elegancko poprawiają nazwijmy to frameworki, opakowując wszystkie wywołania systemowych funkcji w wygodne klasy;

Tylko jak już wspomniałem..... czy to jest sensowne w aktualnych czasach, ponieważ znalazłem parę artykułów, w których WinApi jest traktowana jako prehistoria ;)

Z tym się niezgodzę - to bzdura;

Tworzenie całych projektów tylko i wyłącznie z użyciem podstawowych konstrukcji języka oraz funkcji WinAPI i równocześnie bez używania bibliotek komponentów to faktycznie prehistoria; Po to właśnie stworzone zostały te biblioteki, aby zwiększyć komfort pracy, poprawić czytelność kodu i zlikwidować konieczność topornego rzeźbienia kodu;

Fałszem jest jednak stwierdzenie, że znajomość WinAPI jest dziś kompletnie niepotrzebna i nieprzydatna; Druga rzecz to fakt, iż nadmiar wiedzy nie boli, a często ten nadmiar wiedzy potrafi uratować dupsko przed długotrwałym wertowaniem dokumentacji na MSDN lub szukaniem informacji lub zakładaniem wątków na forach.

WinAPI warto znać. Jeśli masz wybór WinAPI albo nic - zdecydowanie się ucz. Jeśli jednak zaczynasz, to zacznij od czegoś co pozwoli osiądnąć sensowne efekty w sensownym czasie.

znalazłem parę artykułów, w których WinApi jest traktowana jako prehistoria

Z tą prehistorią to jakaś pomyłka, bo Win32 API jest po prostu systemowym API Windowsa, i ciężko cokolwiek napisać nie używając go, bezpośrednio lub pośrednio.
Wszystkie te „frameworki” jak Qt, wxWidgets, VCL, MFC to obiektowe opakowania na winapi.
Niektóre z nich używają bezpośrednio windowsowych kontrolek GUI, inne renderują własne, ale winapi jest w użyciu tak czy siak.

Pisanie GUI bezpośrednio w winapi (bez pomocy biblioteki wyższego poziomu) jest jednak czasochłonne. Pytanie więc, czy jest sens uczyć się rzeźbienia GUI w winapi.
Moim zdaniem tak; nawet jeżeli nie planujemy w ten sposób pisać „poważnych” programów, to ta wiedza się przydaje, dzięki niej „frameworki” przestają być magiczne i wiemy więcej jak są pod Windows rysowane okna, jak obsługiwane komunikaty np. myszy i klawiatury.

Dwa dni temu zacząłem pisanie pewnego programu właśnie w czystym winapi. Główna forma zajęła kilka godzin, i to dopiero połowa pracy nad GUI.
To samo w czymś do wizualnego „trzaskania formatek” zajęłoby pewnie pół godziny (mówię o samym GUI - bo wewnętrznej logiki i tak będzie sporo) ale minimalizm jest tu założeniem projektowym: całość ma zajmować ze 100 kilo a nie 10 mega.

Dziękuję za szybkie oraz profesjonalne odpowiedzi :)