Haha, doslo poslednje vreme - Nedeljko brani Win32 API od mene... fck.
Citat:
Nedeljko
Za svaku funkciju ti piše u MSDN-u kakve greške javlja i kako. Drž' se toga i uživaj.
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!
Citat:
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.
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:
Citat:
A thread that calls the SendMessage function to send a message to another thread cannot continue executing until the window procedure that receives the message returns. If the receiving thread yields control while processing the message, the sending thread cannot continue executing, because it is waiting for SendMessage to return. If the receiving thread is attached to the same queue as the sender, it can cause an application deadlock to occur. (Note that journal hooks attach threads to the same queue.)
:-)
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?
Citat:
U dokumentaciji ti piše da su dijalozi posebni u odnosu na druge vrste prozora.
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?".
Citat:
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.
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 :-)
Citat:
Međutim, to nije do API-ja. Na drugim sistemima je API sličan. Ne postoji rešenje na nivou API-ja.
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.
Citat:
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.
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.
DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos:
http://www.digicortex.net/node/17 Gallery:
http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! -
https://github.com/psyq321/PowerMonkey