» »

[win32] cevi, WaitForSingleObject...?

[win32] cevi, WaitForSingleObject...?

64202 ::

Imam cev narejeno s CreatePipe, tezava pa je, da ne vem kako se caka na input nek omejen cas (kot unix select). Btw.: WaitForSingleObject pa recimo vedno vrne "signalled", ne glede na stanje bufferja.
I am NaN, I am a free man!

BlueRunner ::

Z CreatePipe ustvariš anonimno cev, ki pa je dejansko implementirana kot navadna imenovana cev. V MSDN tako izrecno piše: "Anonymous pipes are implemented using a named pipe with a unique name. Therefore, you can often pass a handle to an anonymous pipe to a function that requires a handle to a named pipe." Zraven pa je dodano, da to ne velja za okna 9x in Me. Praktično to pomeni, da je uporaba anonimnih in imenovanih cevi za sistem popolnoma enakovredna, če pač uporabljaš nekaj, kar si lahko zasluži naziv operacijskega sistema.

To pa je dober podatek, ker to pomeni, da lahko brez kakršnih koli posledic (če ne razvijaš za stare kvazi 32-bitne grafične vmesnike znane pod imenom Windows 95/98/Me) uporabiš imenovane cevi, ki ti, za razilko od anonimnih, omogočajo uporabo overlapped IO. Z overlapped IO pa dobiš prave sinhornizacijske objekte na katerih bodo Wait* funkcije delale v skladu s tvojimi pričakovanji. Sicer je res, da bo procesiranje potem asinhrono, kar kodo rahlo zakomplicira, po drugi strani pa je asinhrono procesiranje IO dogodkov "Dobra Stvar". Res pa je, da na oknih 9x tako aplikacija pač ne bo delovala. IMHO pa je to tako ali tako sistem, ki ga bi bilo najbolje čim prej pozabiti. Družina, ki se vleče že od NT 3.51 je pač veliko boljša osnova, kot pa neko vmesno smetje, ki je bilo dano na trg l. 95. Če pa so tvoje zahteve drugačne, pa veliko sreče...

64202 ::

Ja, overlapped ioju sem se hotel izogniti, ker je bil namen ravno neumno blocking branje iz cevi z "dedicated" nitjo, pa še na win9x bi moralo teči tako ali drugače. Sem potem naredil workaround tako, da sem odprl še eno nit, v kateri se požene ReadFile, originalna nit pa čaka na event objekt z WaitForSingleObject. ReadFile pa ob timeoutu fentaš tako, da zapreš handle cevi... Ugly, ampak jebat ja. Glede na to, kako en folk opeva win32, ima hudičevo veliko hakeljcev :|
I am NaN, I am a free man!

BlueRunner ::

Hmnja... to kar si naredil, pa je tudi edin smiselen način kako težavo rešiti na Windows 9x. Kadarkoli pride kdo naokoli z težavo, ki mu jo povzročajo nepopolne emulacije originalnega Win32 API-ja, se spomnim zakaj točno programiranje več ni moj kruh. Je že tako, da je človek lahko brezkompromisen, če ima drugačno osnovo iz katere nekaj zagovarja, ali pa odsvetuje.

Kar se pa tiče Win32 API-ja, pa ne obstajajo dve verziji (Win32 in Win32s), teveč obstajajo 4 verzije (dodatno sta tukaj še Win32 Deluxe Turbo 95 in Win32 Millenium Bloodsucker Pro). Če pa bi želel videti še bolj bizarna "dogajanja" v oknih, pa bi si lahko pogledal Application compatibility layer: Okna na podlagi podatkov o izvršljivih datotekah sklepajo na aplikacijo, nato pa API-ji, ko se jih kliče iz takšnih aplikacij, nenadoma začnejo emulirati neke hrošče iz leta 1 in 2 po Kristusu. Potem se pa vsi čudimo, da Visto mečkajo že več kot pet let.

Pa še malo off-topic: Longhorn (Vista) je bil spočet tako, kot je bil spočet Chicago: brezmadežen sistem, kjer bo vse delovalo pravilno. Na žalost pa so potem začeli reševati vsako glupo napako, vsakega glupega programerja, ki je po svoji kodi posejal napake (free(NULL), dangling pointers, in še in še) tako, da so vse hrošče iz 3.11 in WfW emulirali v novih oknih. Ko smo prišli do XP-jev, smo tako uspešno naredili sistem na NT platformi, ki je implementiral skoraj vse napake iz 3.11, WfW, 95, OSR2 in 98. Začuda pa ne napak iz Me, ki so itak bili najslabša IT šala tisočletja. Komur so prodali Okna Me bi moral na sodišču zahtevati odškodnino za prestane duševne muke.

No, Longhorn se je začel enako: vse bomo napisali na novo, tako da bo API znova čist in popoln. Potem pa se priključi marketing, pa se znova začne... na deviško čisto svežo kodo se zažne metati drek, ki emulira deset (10!) let stare hrošče iz Oken 95. In to samo zato, ker je nek programer nekega davnega leta zaj. eno funkcijo v Excelu '97. MS pa se najbolj boji pokvariti kompatibilnost, čeprav bi morali po več kot 10 letih narediti dejanski prelom s slabo in nepotrebno zgodovino. Kaj takšno zgodovinsko smetje v sistemu dejansko pomeni, si lahko vsak predstavlja sam. Edina sreča, ki jo imamo, je ta, da so diski dovolj poceni, da lahko Vista naokoli tovori 8 različnih verzij MSVCRT.DLL datoteke, nato pa ustrezni aplikaciji podtakne ustrezno hroščato verzijo. V Windows XP so pač dokončno usposobili "tehnologijo", ki so jo poimenovali side-by-side execution. Sedaj pa cela Vista visi na temu, da jo bodo usposobili do te mere, da bodo lahko emulirali delovanje API-ja za neko igrico, katere založnik je propadel 1999, na tem planetu pa jo še vedno igra pet ljudi.

Če se MS iz zgodovine ne bo naučil ničesar, potem je prihodnost načeloma že znana. Iz projekta Chicago so nastala okna 95, šele 7 let kasneje, pa smo dočakali nekaj, kar je izpolnilo obljube, ki jih je dal Chicago. Iz projekta Longhorn bomo dobili Visto (nov GUI nategnjen preko slabega pireja iz stare in nove kode), morda pa bomo okoli 2013 (če bo MS takrat še obstajal) dočakali tisto, kar se je pri Longhornu objlubljalo.


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Komunikacija med thread-i

Oddelek: Programiranje
133681 (3487) zlatko
»

C++

Oddelek: Programiranje
71390 (1152) zdravcc
»

Funkcija za zapret program

Oddelek: Programiranje
151292 (1048) StratOS
»

C++ in komunikacija preko LPT pod NT/W2k

Oddelek: Programiranje
101124 (937) Turbina
»

Odpiranje dat.exe v VB

Oddelek: Programiranje
122960 (2753) webblod

Več podobnih tem