Linux prebacio 4%

To sve nisu nikakvi problemi. Nego, kojoj ovci runo smeta, tu nema ni ovce ni runa.

Pritom, Ivan nije dev biblioteka, nego neko ko 10+ godina ne programira ozbiljno, što je vrlo vidljivo i iz drugih njegovih postova na temu programiranja.

---

Kome od prisutnih u diskusiji mislis da ovo nije bilo poznato, meni ili Dimketu? :)

---

Nikola:"Kome od prisutnih u diskusiji mislis da ovo nije bilo poznato, meni ili Dimketu? :) "

Ma dobro to, al kako spakovati file name duzi od 8 karaktera u 8 karaktera ;)?

Ne pricamo mi o istim stvarima. Ja nisam imao nikakvih problema sa Win32, cak nisam nikad presao na neki od njegovih neuspesnih naslednika. Verovatno bih i dan danas, da me neko natera, koristio Win32 API ako moram da napisem Windows aplikaciju.

Ali to ne znaci da Win32 API, objektivno, nije djubre. Jeste, i to neopevano.

Znas, kada bilo koji proces bez admin privilegija moze da poveca broj interapta 15x kako bi neki sampion ubedio OS tajmere da mu daju 1ms rezoluciju (koja mu ne treba da je malo vise citao knjige)... to ne mozes a ne da nazoves cistom 3.14zdarijom.

Cak i Chrome je to radio do skora... sta qr, ono sto nije zabranjeno je dozvoljeno.

Konacno, problem su primetili kada su ljudi krenuli da se zalle na mizerno trajanje baterije sa onim sminkerskim laptopovima. Dok su gospodarili desktopi jedina steta su bile bebe foke, gleceri i... naravno, racuni talaca ovih budalastina. Sta te boli patka sto CPU ne moze posteno u Cx mod stednje energije?

Tako da, Win32 API ne samo da je krs, vec ubija poarne medvede i bebe foke. Genocidni API!



Sto u ovom slucaju moze biti i prednost - Win32 je balzamovan jos pre vremena kad sam ja prestao komercijalno da koodiram. U tom momentu je Win32 API vec imao 3 naslednika: .NET, WPF i WinRT :-)

Prakticno jos od vremena .NET-a Microsoft u Win32 API dodaje samo sta mora, sve ostalo je islo u pokusaje zamene (koji su propali)

WPF... WinRT... UWP... Na kraju ce Win32 da ih sve nadzivi, bas kao B-52 koji je nadziveo B-1 a verovatno ce i B-2.

Sa razlikoom da je B-52 solidan avion, dok je Win32 nesto drugo.

Srecom, pa danas mozes da radis vecinu stvari a da Win32 API ne vidis u zivotu.

---

Win32 API nikoga nije sprečio da napravi vrhunski softver, praktično kakav god je hteo. Teško da je đubre.

Win32 API nikoga nije sprečio da obavi posao izuzetne složenosti.

Teško da je đubre.

---

Ivan:"WPF... WinRT... UWP... Na kraju ce Win32 da ih sve nadzivi, bas kao B-52 koji je nadziveo B-1 a verovatno ce i B-2.

Sa razlikoom da je B-52 solidan avion, dok je Win32 nesto drugo.

Srecom, pa danas mozes da radis vecinu stvari a da Win32 API ne vidis u zivotu."

Pazi kad radis iz .NET ne vidis winapi iako moras da ga znas :P
Projekt na kom radim ima delove GUI koji se rade u WinApi, tako da su moja znanja iz ovoga dobrodosla :P
Nema sanse da omasis WinApi ako radis C++ za Windows ili koristis neke od biblioteka za koje ne postoji
.NET wrapper (a ima ih).

Što sve ne znači da je winapi đubre.

---

Da je sprecavao, bio bi neupotrebljivo djubre. Ali da je otezavao, jeste...

Posto vidim da nemas iskustva sa Win32, evo ti malo zanimljivosti - pocecemo od lakih stvari, pa polako doci do totalno katastrofalnih.

API je los, kad ti trazi da drzis pointere na funkciju u nekakvoj LONG promenljivoj koju dobacujes OS-u API pozivom iz 1990-te budzenom vise nego karton-cikl. Cisto da ne razocaraju, za Win64 je samo LONG presao u LONG_PTR (!!!)

API je vrlo los kada mozes da urnises potrosnju sistema cak i ako nisi admin.

Jos je losiji kad imas desetine izvedenih kripticnih tipova poput LPCTSTR od kojih neki jesu a neki nisu fiksni za odredjenu sirinu karaktera. Ko jos uopste brine o tome?

API je uzasan kad dovodi do samo dve reci: DLL HELL, ako si programirao 90-tih i 2000-tih, ovaj termin je izazivao momentalan skok krvnog pritiska. Onda je jednog dana Microsoft uveo workaround gde bukvalno kopiraju citave nizove fajlova (WinSxS) i rade transparentnu redirekciju. Sto je super, samo sto je moralo da ceka da diskovi postanu dovoljno veliki da mogu da nose N kopija svega zivog.

Onda nekonzistentnost izmedju nacina kodiranja gresaka, razliciti nacini za signaliranje beskonacnosti (INFINITY? NMPWAIT_WAIT_FOREVER? MAILSLOT_WAIT_FOREVER?)

Ili menjanje ponasanja istog API-ja u iz jedne u drugu verziju Windows-a? Sta ako je taj API jedan od mozda 50 kljucnih API-ja?

https://docs.microsoft.com/en-...ynchapi-waitformultipleobjects

Enter WaitForMultipleObjects()



A? :-) OK ti je da isti API ima >vrlo< razlicito ponasanje na Windows-ima do 2012 i na Windows-ima od 2012? Bez brige, MP kod je obicno takvo djubre da vrlo verovatno i ne radi kako treba i ima gomilu ponavljanja gde ni sam autor verovatno ne zna sta radi i zasto to radi ali ce 100 puta proveriti i ponoviti operaciju, tako da... no biggie :-)

Ali sve ovo je bila samo losa praksa, los dizajn... Mozes da kazes da je sve i dalje tehnicki "ispravno", samo programer mora biti Petzold-ov rodjak.

Avaj, za zalost Win32 API ima i stvari koje su, jednostavno i nedvosmisleno: pogresne. Nema "ali".

Enter PulseEvent() - https://docs.microsoft.com/en-.../winbase/nf-winbase-pulseevent



Ovde nema vrdanja, ovaj API ne radi korektno. Znas sta je najbolje? Sto je u ranijim verzijama (mislim od NT4) Microsoft imao "primer" kako se koristi PulseEvent, koji je izazivao deadlock. Ovo upozorenje gore je tek dodato vise godina kasnije, pa cak ni tad nisu zabranili upotrebu za nove aplikacije, vec samo ubacili nemust savet u MSDN dokumentaciju. U tom momentu, net je vec bio pun raznih code-snippeta koji su srecno koristili PulseEvent kako bog zapoveda :-)

Raymond Chen nije birao reci: https://devblogs.microsoft.com/oldnewthing/20050105-00/?p=36803



Imamo jos bisera, recimo - WndProc (tvoja procedura u kojoj obradjujes poruke koje ti Windows salje, vezane za prozor)

Pazi sad, unutar obrade poruka ako pozoves odredjene Win32 API-je odatle, to ce biti put u jednom pravcu (lock). Primer? Recimo SendMessage(). Cela stvar je minsko polje koje je verovatno samo odgovorno za bog te pita koliko miliona $ bacenih sati na debug.

Ali postaje jos ludje sa dijalozima, koji su prozori kao i svi drugi ali sa nevidljivim slojem hack-o-rame koju je MSFT napravio za tebe i koji imaju svoja specijalna pravila...

Pazi ovo: https://docs.microsoft.com/en-...api/winuser/nc-winuser-dlgproc



Koliko POGRESNOG i LOSEG u 2 paragrafa!!! Za pocetak, nacin na koji se signalizira povratna vrednost (ne kao POVRATNA VREDNOST, vec kao nekakav hakovani "stos" gde ces da setujes fleg u internoj strukturi prozora, btw. to je isti API iz 1990-te od pocetka poruke) to nije nista jos...

WTF momenat nastaje kad procitas da ti savetuju da povratnu vrednost setujes "neposredno pre povratka" inace moze da se desi da je prebrise neka ugnjezdena poruka!!!!

Pazi: MOZE DA SE DESI!!! Ovo neka za*bancija? Ne! Znaci garancija nema osim sto mozes da se molis Manitu-u da se kernel umorio malo i nece da se seti da ti za*ere rezultat pre nego sto zavrsis.

Volovi, sta ako izmedju procesor ode na spavanje, pa kad se vrati izvrsi kod druge niti? A, da, mozemo to da sprecimo, sto ne bi smo ukinuli mogucnost spavanja, kada bi samo postojao API za to... :-)))

Ili sta ako BAS u nezgodnom momentu interapt kontroler odluci da dostavi malo mreznih paketa, a posle toga procesor odluci da malo deli pravdu i dozvoli drugoj niti da te s*ebe? APC?

Komentar? Ne treba.

BUT WAIT! THERE'S MORE! Nastavljas da citas uputstvo za isti API...



Dobro si procitao, posle idiotskog saveta za pisanje nepouzdanog koda, taman kad si krenuo da se oporavljas od ludila koje si procitao, Microsoft kaze: IMAMO I IZUZETKE SA SOPSTVENOM POVRATNOM SEMANTIKOM!!!!

"EXPLAIN!!!" :-)

Jos nije dovoljno? Sta kazes za OPRECAN nacin procesiranja stvari iako se radi o istom zadatku? Da ne bi posumnjao u doslednost MSFT-a nedoslednom programiranju, ovo nije savet, vec obaveza ako neces da ti krahira program...



MSFT: Da da, jeste, Dialog je prozor, ima svoju proceduru (DialogProc) koja je u sustini isti qr kao procedura drugih prozora (WndProc). ALI ako uradite nesto sto se radi u svim drugim slucajevima i pozovete DefWindowProc()... Windows ce vam otkinuti glavu.

WHYYYY? Zato sto su dijalozi jos jedan u beskrajnom nizu hakova koje danas verovatno niko u Microsoftu ne razume :-)

Ovako mozemo do sledece nedelje.

---

Da je loš, napravio bi neko OS sa boljim API-jem na kome bi bilo lakše programirati, pa bi vremenom softverska ponuda na tom OS-u bila bolja i Windows ne bi imao dominantnu poziciju kakvu je imao.

Windows SDK za Win16 je bio đubre i softverska ponuda za njega nije bila tako dobra kao za Windows 95.

To ne znači da je loš.

Na Win32 je sizeof(LONG)==sizeof(void*). Na Win64 je sizeof(LONG_PTR)==sizeof(void*). Pokazivače koje vraća sistem ima smisla maskirati kao nešto drugo iste veličine, da neko ne bi vršio neke besmislene operacije nad tim.

Imaš string koji odgovara znakovnovom tipu char, string koji odgovara znakovnom tipu wchar_t, a za jednoobrazno programiranje imaš string koji odgovara znakovnom tipu TCHAR, koji je char ili wchar_t u zavisnosti od podešavanja. Tako imaš tri funkcije. FunA (char), FunW (wchar_t) i Fun (TCHAR). Dakle, sve imaš na način koji se lako pamti.

Dobro jutro Kolumbo! DLL hell, a? Da li sada shvataš čemu služe upravljači paketima na Linux-u? Jednostavno, o zavisnostima mora neko da vodi računa. Ovde je to distributer.

Na Windows-u, ako aplikacija ima lokalno instalirane dll-ove u njen instalacioni folder, onda je sve u redu, ali prednosti dinamičkog povezivanja ne dolaze do izražaja (primena dll-ova spada samo na plugin-ove).

Ako aplikacija instalira dll-ove u neki zajednički folder, onda deli dll-ove sa drugim palikacijama, pa ažuriranje jedne može narušiti ispravnost rada druge, ako jedna aplikacija ažurira zajednički dll na noviju verziju, koja nije unazad kompatibilna sa starom.

To se zove dll pakao. Rešenje je u tome da neko mora da vodi računa o kompatibilnostima komponenti unazad, što je u linux svetu distributer i to se rešava kroz upravljač paketima. Na Windows-u je jedino ispravno rešenje ovo prvo, kojim se poništavaju prednosti dinamičkog povezivanja.

Međutim, to nije do API-ja. Na drugim sistemima je API sličan. Ne postoji rešenje na nivou API-ja.

Za svaku funkciju ti piše u MSDN-u kakve greške javlja i kako. Drž' se toga i uživaj.

Pominješ dijaloge. Zašto bi GUI radio u više od jedne niti? Nemam nikakvu predstavu zašto bi to ikome trebalo. Koliko god da se niti ispali, GUI radi u samo jednoj od niih, dok ostale niti nemaju ništa sa dijalozima.

U dokumentaciji ti piše da su dijalozi posebni u odnosu na druge vrste prozora.

Inače, imaš toliko klasnih omotača za Win32 API, da ne znam šta te boli qr za sve to. Moraćeš ponekad da opališ nešto neki Win32 API poziv, da mi nije jasno kako to otežava programiranje.

---

Haha, doslo poslednje vreme - Nedeljko brani Win32 API od mene... fck.



Ma da, zasto bi imali kozistentne kodove greski, konzistentno ponasanje f-ja, kad lepo mogu da kazu "citaj uputstvo i uzivaj".

Zato i kazem, Win32 nije neupotrebljivo djubre (za to bi trebalo da stvarno ne bude upotrebljiv), vec samo: djubre.

Znas, ovaj tvoj komentar me podseca na komentar lika pre nekoliko godina na zalbu kolege koji je s*ebao auto na rupcagi na mostu (koja nije bila obelezena) da idiotski grad ne radi posao.

Odgovor? "Pa sto nisi gledao bre"... e to je to. Savrseno tacno. Ali pametniji ljudi su odavno ukapirali da je bolje rupcagu obezbediti ogradom sa signalizacijom ("jos i lampe da ti svetle? bezi bre").

Bas kao sto je i ta neobelezena rupa uspela da urnise gomilu automobila, tako i Win32 nekonzistentne budalastine su sigurno kostale milione u bagovima... ali brate, sto nisu gledali, bre!



Hahaha evo ga jos jedan "a sto nisi gledao" :-) Sto bi GUI imao vise niti? Zato sto mozes da imas GUI u vise niti :-) Kada ti OS pokrece skoro sve desktop racunare sveta, to znaci da ces imati bezbroj aplikacija koje to rade.

Ali uopste nije potrebno da imas GUI u vise niti. Ako nisi znao, "prozori" u Windows-u su cesto korisceni i za zadatke koji nemaju veze sa GUI-jem. Ucitaj Spy++ i pogledaj koliko "nevidljivih" prozora imas trenutno. Odgovor: jako mnogo. Zasto? Zato sto su nekada davno ljudi koristili nevidljive prozore kao message-passing mehanizam. Zasto? Zato sto idiot koji je dizajnirao Win32 to nije pruzio na odgovarajuci nacin. Ne... idiot koji je dizajnirao Win32 API je i sam ohrabrivao ovakvu praksu.

Ali sta qr... sto nisi gledao bre!!!

Sto se dijaloga tice, imas 3 razlicita problema koji ukljucuju dijaloge, od kojih prvi kaci i druge prozore:

1. Problem sa vise niti koje razmenjuju poruke sa SendMessage() - sasvim validan scenario, koji deadlock-uje ako pozvana nit prestaje da se izvrsava (zato sto pozivna nit mora da ceka na povratak SendMessage()). Ako obe niti dele isti queue, deadlock je garantovan bez tvoje intervencije. OK, nikakav problem reci ces - nemoj da delis queue? Jel da? :-) Ali neki elementi Win32 (journal hooks) kreiraju tu situaciju protiv tvoje volje:



:-)

2. Dijalozi imaju svoj poseban niz problema. Neki od njih cak ne moraju ni da ukljucuju vise niti. Recimo, problem koji sam naveo moze da se desi i unutar jedne niti: ako se izmedju tebe i povratka procesira neka ugnjezdena poruka. AHA! Ako poslusas Microsoft i uradis promenu tik pred return(TRUE/FALSE) nemas problem? Pa ne bas, zato sto je Win32 ohrabrivao "subclassing" gde si imao gomilu ugnjezdenih "dorada" WndProc-a gde ces vrlo brzo izgubiti ideju sta se desava i ko sve menja / ne menja DWL_MSGRESULT. Cela stvar je bukvalno poziv za bagove.

Ne verujes? Hahaha, evo ti klasicna situacija velike Windows aplikacije: svako odeljenje ima neki svoj tim, cesto "na brzaka" dodaju svoj WndProc kojim svoje poruke procesiraju. Zivote :-) Sve ono sto normalni ljudi sprecavaju (hello pimpl) Microsoft ne da nije sprecavao nego ohrabrivao... sto da juris tamo neki tim u Bangaloru, SetWindowLong(Ptr :-)(GWL_WNDPROC) bato, zapamtis poslednji WndProc koji ces pozvati kad zavrsis svoje. What could possibly go wrong? :-)

3. Dijalozi imaju svoju kategoriju problema osim navedenih: vidis, kod Win32 dijaloga neke poruke procesira "framework" ("framework" je jos jedan subclass-ovani WndProc, samo ovog puta nevdljiv za tebe). Tako da neke stvari koje radis, ne smes da radis u dijalozima zato sto ce Windows da ima problem ako si im drmao kavez.

Ne samo to, nego to uopste nije garantovano da bude stabilno izmedju verzija. Kako ces znati? Aaaaa.. "sto nisi gledao, bre", zasto bi bilo logicno ili konzistentno?



E dobro ako pise :-) Samo treba da gledas. Je li bre, a sto uopste takav idiotski dizajn?

Mislim kapiram, mozes da napravis i mikrotalasnu rernu koja nema zastitu od korisnika koji ce da je otvori dok radi... sta qr, napises u upustvo "nemoj otvaras".

Onda ti na ER ode gomila imbecila sa opekotinama i doktori u cudu pitaju "sta bi majmunima da ne ugrade sigurnosni prekidac?".



Ocigledno nisi radio u Windows industriji. Da jesi, krstio bi se i levom i desnom rukom sta su sve ljudi ubudzivali preko WndProc-a, nevidljivih prozora, "dosetki" za "unapredjenje" dijaloga, zlostavljanja registry-ja i sl.

Ako imas slobodnog vremena i nemas problem da malo krsis zakon :-) mozes da nadjes NT4 / Win2k izvorni kod, pa kreni da cesljas "User32"/"Comdlg32"/"Comctl32" komponente. Kreativni komentari koji oslikavaju zgrazavanje sa hakovima koji slede kako bi se odrzala kompatibilnost sa svim mogucim i nemogucim idiotizmima je neverovatna. Najveci prestupnik? MS Office ;-) Cak ni oni nisu citali bre! :-)

Kad ti je kod pun ovoga, to znaci da si se negde za*ebao... u API definicijama :-)



Ne postoji resenje na nivou API-ja, ali API koji nema nikakvu drugu mogucnost verzionisanja vec ima identicne fajlove sa identicnim C eksportima moze samo da pogorsa situaciju.

Svaki fajl ti se zove MOJAPI.DLL - f-ja ti se stalno zove MYFOO, od verzije 1 do 150... razlika? Aaaa... velicina strukture koju prenosis kao parametar!!!! (hahahahaha).

Znas sta je najgore, najveci broj Win32 API kompromisa je nastao >pre< Win32 API-ja - u Win16 API-ju. Tada si im i mogao oprostiti neke zlocine. 2000-tih? Pa bas i ne.



Ahaaaa :-) A zamisli sad ovo, deo koda (TCHAR-ovi) radi kako god. OK!

Deo koda puca u kompajliranju ako makefile prepevas na "UNICODE" (TCHAR=wchar_t) - majq mu! Onda ti neki bizgov popravi greske.

Sutra, drugi deo puca u kompajliranju ako makefile prepevas nazad na "ANSI" (TCHAR=char)... ?

Sto nisu gledali? Da i ja se pitam... kad ti kod pise tim od 500 ljudi, deo koda pisao zaljubljenik u TCHAR-ove (taj deo ce uvek da radi), deo koda pisao anglosaksonac koji nije cuo za UNICODE pa podrazumeva da je sve char/LPSTR&co... onda jednog dana dodje zahtev da zbog Japanaca sve mora u "UNICODE" i onda krece belaj :-) Poprave oni to, javi se Amer koji zahteva ANSI build (iz milion razloga, nekih validnih) - krece sve ponovo, zato sto su idioti promenili svoj LPSTR u LPWSTR... error-fest. Pa tako im i treba, STO NISU GLEDALI!

Ili mozda da imbecil koji je dizajnirao API nije uopste dao mogucnost ovakvih budalastina... ali nije moglo, kako bi onda Win16 kod radio... :-)

Ne, nije djubre uopste.
...

Nego, @Nedeljko, reci ti meni sta kazes na PulseEvent()? Ovo sve kozmetika - ali sta kazes kada ti OS vendor daje API koji ne funkcionise? I drze ga i dan danas kao maskotu.

"Sto nisi citao" ne pije vodu - upozorenje su dodali tek kad je Vista izasla, do tad su ti i savetovali da pulsiras :-)

Nemoj samo da mi kazes da je odjednom i nekorektan API OK.

Sta kazes za WaitForMultipleObjects(), da nije mozda OK da ti istoimeni API odjednom promeni ponasanje? Sto nisi gl... cek bre, sta ako firma koja je pisala kod vise ne postoji? HMMM... nista, pravicemo se da se nista nije desilo, program ce ucitati WaitForMultipleObject korektno i izvrsiti isti sa razlicitim rezultatom. Deluje bolje nego da program krahira, ili da, ne daj boze, potrose vreme u obezbedjivanju kompatibilnog ponasanja.

Znas sta je najgore, sto su greske koje slede od ovoga verovatno u domenu "oporavljivih" - ono nece nista puci, vec ce mozda samo doci do nekih cudnih ponasanja programa ili neobjasnjivih ne-fatalnih gresaka.

Korisnici ce se verovatno zaliti na aplikaciju, a ne na idiotski OS API.

---

Ivan:"Pazi sad, unutar obrade poruka ako pozoves odredjene Win32 API-je odatle, to ce biti put u jednom pravcu (lock). Primer? Recimo SendMessage(). Cela stvar je minsko polje koje je verovatno samo odgovorno za bog te pita koliko miliona $ bacenih sati na debug."

Pa da tamo gde rekurzivna obrada event-a nece da izadje na dobro postavis flag da si vec usao u fju isamo izadjes ako jesi :P
Inace iz threadova nikada sendmessage nego postmessage ;)

Nisi naveo use case gde ti treba GUI u više niti. Za poruke valjda ima drugih metoda. Između procesa može preko tcp-a (bez obzira da li su na istoj ili različitim mašinama) ili preko deljene memorije ako su na istoj mašini, a što se tiče komunikacije između niti, to je barem lakše preko nekog message pool-a.

Zašto da razmenjujem poruke između niti preko SendMessage()?

GUI treba da služi samo za to, a ne da se funkcionalnost trpa u njega, što je početnička greška u dizajnu.

To što si naveo za subclassing prozora i dijaloga isto važi i za OOP paradigmu. Šta s tim? Ne raditi nasleđivanje, jer ako ansleđujem šta je neko nasleđivao, onda...

Ne znam šta da ti kažem, sem da je razvoj softvera dobro plaćen posao i da nema leba bez motike. Mora ta plata nekako da se zaradi. Da je sve spidi end izi, bilo bi plaćeno koliko i čišćenje ulice.

Šta bi ti hteo i na koji način je ostvarivo to što bi ti hteo, u vezi sa subclassingom? Sećam se priča o tome kako je "tipičan američki programer" zapravo "point and click" programer, koji nešto stavi na nešto i onda to poveže. Kako li onda ti amerikanci imaju sve ove napredne tehnologije, majku mu?

Što se dll pakla tiče, ubacivanje oznaka verzija ne rešava problem nekvalitetnog pravljenja dll-ova. Evo, recimo da ima verzionisanje. Šta onda? Da li različite verzije dll-a treba da se zovu isto ili različito? Zamisli da ti dizajniraš OS kako ti je volja. Ako Đoka programer pravi dll i naruši kompatibilnost unazad bez da je to označio nekako, nikakav OS neće rešiti taj problem.

Dakle, pitanje za dll-ove je isto kao za subclassing. Šta bi ti hteo i kako je ostvarivo to što bi ti hteo? A, pa da. Postoji rešenje, ali ne na nivou API-ja. Rešenje je da neko (canonical) brine o tome kroz upravljač paketima.

To za TCHAR-ove znači samo da treba da paziš koga zapošljavaš. Znam ja da neki teže tome da rade kod ko nogama, tako da na kraju to nekako radi, umesto da razmišljaju o značenju toga što kucaju i onda nastaju problemi sa održavanjem.

To sa neispravnim ponašanjem naravno da ne treba pravdati. Gore od toga je tretiranje neispravnog kao ispravnog.

Narušavanje kompatibilnosti unazad pravi problem, ali i održavanje kompatibilnosti unazad predstavlja kočnicu razvoju. Zato postoji pokretanje programa u raznim režimima kompatibilnosti.

---

Nedeljko:"Nisi naveo use case gde ti treba GUI u više niti."

Na trenutnom projektu obrada komadni koje stignu sa neta, i iscrtavanje grafika u vise prozora gde svaki thread iscrtava u svom prozoru.

edit:
u svakom slucaju kada imas komunikaciju sa netom treba ili posevan thread ili async pristup soketima, posto blocking soketi
ima da zaglupe prozor :P

Za to ti ne treba GUI u više thread-ova. Thread-ovi treba da obrađuju podatke i da šalju GUI-ju šta treba. GUI treba da trči u svom thread-u.

---

Use case? Ono sto sam ja video je kad firma hoce da spoji projekte / proizvode ili kupe nesto, i onda brze bolje neko transformise kod u N niti umesto N procesa, zato sto je deljenje podataka "lakse" bez procesnih granica. Ili je neko odlucio da tako dodaje prozore. Zasto? Mislim da nema odgovora.

Deljenje naravno preko Windows message-pumpe :-)

TCP? Tacno se vidi da si propustio jako uzbudljiv deo PC istorije - Windows je imao svoje tehnike, svoja pravila... mozda mozes da nadjes tragove toga na CodeProjectu i sl. Ljudi su jednostavno koristili konstrukte koji su im bili najlaksi za napraviti... svako znao da procesira WM_xxx poruke u WndProc proceduri, sto ne bi radili to isto za razmenu podataka, sve sto treba je... da sakriju prozor.

I, eto, imas dziberski IPC :-)

Ludo? Slazem se, ali tako su ljudi pisali kod... TCP je bio vrlo stran koncept.

Inace Windows je imao jako fin API za IPC - zvao se LPC (http://www.zezula.net/en/prog/lpc.html), ali su odlucili da ga ne dokumentuju i zadrze samo za sebe. Onda su u Visti doradili isti i promenili mu ime u ALPC (A = asinhroni)... ali je API i dalje ostao privatan.

Bez brige!!! Jos jedna od tipicnih stvari u Windows svetu je koriscenje Microsoft-ovih privatnih API-ja kad postanes "napredan" :-) Uprkos Microsoft-ovim upozorenjima da nece odrzavati kompatibilnost, ovo ono... NTAPI koristi i mlado i staro. I, naravno, mukice u Microsoftu moraju i to da odrzavaju kako neki CEO MegaCorp-a ne bi nazvao MSFT CEO-a i pominjao familiju ako su mu ubili proizvod.

A pazi tek ovo ludilo, MSDN ima clanke o tome kako je kul:

https://docs.microsoft.com/en-...dure-calls-part-1-architecture

Bez brige, covek je stavio upozorenje!



OK, objasnicu vam kako radi ovaj kul API, ali ne smete da ga koristite!



Zato sto si lenj i ne znas za bolje?

A, da, i zato sto te je OS vendor pustio da to radis. Probaj danas na iOS-u da dr*as GUI iz druge niti, dobices:



Znas zasto je Apple investirao vreme za proveru da li radis ovu budalastinu? Zato sto takav kod bukvalno priziva bagove. Apple ne zeli da im reputaciju krnje lose pisane aplikacije, pa ce pomoci da se takve situacije smanje ili potpuno izbegnu.



Verovao ili ne, ta "pocetnicka greska" je bila bukvalno dominantni nacin razmene podataka u Windows aplikacijama 90-tih i pocetkom 2000-tih.

Ovo je nestalo iz upotrebe tek kada je direktan Win32 API nestao iz vidokruga vecine programera.



Postoji vrlo velika razlika: Win32 API je ovo omogucavao i ohrabrivao bez ikakve mogucnosti za kontrolu odgovornog za prozor i njegov WndProc.

Ako pises nesto u C++-u, ako ne zelis ovakve idiotizme, sve sto ne zelis da drugi vide ces staviti u "pimpl" koji je "crna kutija" na nivou interfejsa. Ako neki sampion nije sputan ovim i hoce direkt da doda nesto, to ne moze da uradi bez da promeni fajlove sa tvojim izvornim kodom.

Moderni C++ ima i druge nacine.



Mislim da totalno masis poentu. Ovo sto si rekao je tacno, ali los API sa losim anti-patternima koji nisu penalizovani moze samo da rezultuje u djubretu.

Win32 je los API. Toliko los da su cak i u unutrasnjim MS timovima pravili svoje imitacije, recimo MS Office koji je bukvalno kopirao ponasanje UI elemenata, ali su ih sami crtali od nule. Naravno to nikad nije moglo da bude isto. Dosta govori o svemu kad ti sopstveni programeri ne koriste zvanicne API-je.



Ne kontam sta znaci to "americki programer".

Sto se subclassinga tice, resenje je jednostavno: nemas ti sta da radis sa prozorom ako nisi odgovoran za kod. Znaci ko god je pisao WndProc je odgovoran za WndProc - ako hoces da ga prosiris, ili ti on prosiri WndProc sa cim god hoces, ili se dogovorite za neki callback koji ce on pozvati. Ali on ostaje pod kontrolom.

Ovaj idiotizam sa subclassingom bukvalno daje slobodu bilo kome ko je u tvom procesu (cuti, u Win 3.1 / 9x je moglo i van procesa, to je tek komedija bila) da se nakaci na prozor, doda neku svoju stvar bez da odgovorna strana ima pojma o tome.

Sta moze poci q*cu? Puno toga. I, ne, "zaposli Alana Turinga i John von Neumann-a" nije odgovor.



Problem nije nalazenje magicnog unicorn OS-a koji resava sve, vec sprecavanje idiotizama ako je to vec moguce dizajnom koji nije mozdano mrtav.

Win32 je na zalost jedan od tih, hack-o-rama Win16 API-ja gde je glavni cilj bio da se smanji trosak portovanja. To bi im nekako i oprostio, ali su isti "stil" zadrzali i sa API-jima koji nikad nisu ni postojali u Win16 svetu.



API nije tu da daje resenje za problem pakovanja i instalacije softvera, ali moze svakako da pomogne tako sto ne povecava problem.



Da. Imam ja jos bolji predlog: da pazis i sa kim imas sex, ima da se opameti cela planeta.



Neki teze? Vecina tezi.

Mozda ne kod tebe gde su programeri mozda pametni, obrazovani i motivisani ljudi. Na zalost, ovo nije aproksimacija tipicne firme. Kada bi to bilo tako, ne bi ni bilo potrebe za gomilom jezika kojima je jedan od glavnih aduta sto su "bezbedniji od C-a".



Microsoft je to upravo radio sa PulseEvent-om i to je samo jos jedan pokazatelj ko je dizajnirao API. Uzgred, znas da si mator ako se secas ere gde je PulseEvent bio deo saveta.

Na gresku u PulseEvent-u je ukazala treca strana. Uprkos tome je bilo potrebno puno vremena da bar to potvrde. do tada si imao veseo primer



Ovo je sve trivijalno resivo modernim paradigmama gde uopste ne bi bilo dvojbe oko toga koju verziju WaitForMultipleObjects() API-ja aplikacija zahteva. Onda bi mogao da odlucis da li imas staru implementaciju ili ces da vratis gresku.

Ali ne, posto je osnova za Win32 nastala u vreme 16-bitnih segmenata i prefiksa (i dan danas ces naci fleke iz 16-bitne ere u deklaracijama tu i tamo), sta ce ljudi - moraju da se drze C-a kakav ga je bog zamislio 1989-te.

To je bsh*t. Nije im bio nikakav problem da migriraju sta im treba. I, gle cuda, danas kad linkujes Kernel32.dll, ne ucitava se Kernel32.dll, vec neki KERNEL32_QR_PAL_VERZIJA_KRIMINAL_123 transparentno. Za to im je trebalo 1000 godina.

---

Otkud ti to?

Kako otkud? Pa, otud što znam da radim te stvari.

---

@Ivan Dimkovic,

Znaš li kako na Linux-u radi to sa TCHAR?

Nema TCHAR. Ceo API je UTF-8 bez BOM-a. Dakle, jedini tip stringova u API-ju je char*. Radi odmah i kao ASCII i kao UNICODE, sa istim build-om, bez ikakvih podešavanja, nemaš dvostruke API funkcije zbog toga, ali...

i to ima svoju cenu. Nemaš direktan pristup znaku sa zadatim indeksom (kao str[ i ]), nego prvo transformiši UTF-8 char* bez BOM-a u wchar_t* da bi mogao normalno da rukuješ stringovima. Dakle, za argument argv main funkcije važi da je argv[ i ] tipa char* i da pije UNICODE, ali posle treba da se transformiše u wchar_t* za normalan rad.

---

Ne znas. GUI thread handluje evente, kada renderujes/iscrtavas to ne radis u GUI threadu....
Pre svega zato sto ne mozes da procesiras evente i da radis nesto drugo...

edit:
jedino moras da pazis da ne rokas po istom kontekstu iz vise threadova bez singronizacije...


_{[Ovu poruku je menjao Branimir Maksimovic dana 04.11.2020. u 02:51 GMT+1]}

Renderovanje u drugom thread-u može po nekoj bitmapi, koja se onda prikazuje u GUI thread-u.

Takođe, može i GUI thread da renderuje i čim završi, pređe na druge događaje.

---