Fraza care mi-a atras cel mai mult atentia a aparut cand se discuta despre prima litera, cea care indica preferinta pentru o anumita atitudine: extrovertit sau introvertit. Trainer-ul a tinut sa sublinieze importanta alegerii job-ului in functie de felul tau de a fi: "De exemplu, daca esti extrovertit nu o sa-ti iei un job de programator, deoarece te vei chinui si te vei urca pe pereti: pentru ca tu ai nevoie sa interactionezi cu oamenii, sa iesi, sa comunici." Cand mi-am vazut rezultatul testului, deja ma intrebam daca nu cumva mi-am gresit cariera. Mi-am revenit dupa ce am realizat ca e pur si simplu un stereotip.

Cu totii il cunoastem: stereotipul programatorului. O idee preconceputa si simplificata la extrem a caracteristicilor unei persoane: "tipul cu calculatoarele" sau "geek-ul". Cel pe care l-ai chema sa-ti repare calculatorul, sa-ti reinstaleze Windows-ul sau "sa-ti puna Office-ul". Este de obicei introvertit si sta ascuns intr-o camera întunecata sau intr-un cubicle. Gandeste in 0 si 1 si vorbeste o limba ciudata, plina de acronime.

Am intalnit multi oameni care atunci cand te cunosc pentru prima oara incearca sa faca glume adaptate la putinul pe care-l stiu despre tine. Sunt acei oameni care atunci cand nu merge interfonul la scara iti arunca o gluma de genul "Nu-i merge Windows-ul, cred ca-i trebuie un restart" si se asteapta ca tu sa razi cu ei tocmai pentru ca tu lucrezi "in domeniu" si ei "stiu" ce fel de glume sa faca cu tine, desi ei nu au legatura cu domeniul tau.

Problema cu stereotipurile e ca sunt adevarate. Sunt acele self-fulfilling prophecies, cum ar spune americanul. Aflandu-se intr-o aparenta imposibilitate de a dezvolta o alta identitate (fie datorita presiunii sociale, a timiditatii sau a unei atitudini introvertite) programatorul imprumuta identitatea oferita cu multa "generozitate" de catre stereotip. Psihologii il numesc efectul Pygmalion: programatorii preiau eticheta pe care lumea o lipeste pe ei si o internalizeaza. Ajung astfel sa isi inhibe alte laturi ale personalitatii lor, pentru ca lumea deja le-a dat o reputatie pe care sa o apere - cea a stereotipului. Stereotipul le da acea "cutiuta" in care sa se aseze comod, impacati cu gandul ca in mintea celorlalti sunt acum cineva: "Programatorul" sau "Geek-ul".

O parte dintre ei se mandresc cu noul statut si cauta sa-l accentueze mai mult cu fiecare ocazie aparuta, fie ca e vorba de acomodarea cu cea mai noua tehnologie sau de ultimul argument într-o confruntare tehnica (sau o discutie la bere). Recunoasterea oferita de noua lor identitate este reconfortanta.

Totusi, o parte dintre programatori cauta sa se distanteze de stereotip, pe care il vad lipsit de stralucire si pe care il considera o piedica in calea dezvoltarii unor relatii sociale satisfacatoare. De obicei ii auzi spunand: "Doar nu o sa programez toata viata, e doar un pas intermediar pentru a deveni manager". In urma presiunii sociale, ii auzim pe tot mai multi spunand: "eu nu sunt programator, sunt antreprenor". Suna mai bine, nu? De obicei auzi asta de la cei care au absolvit o facultate tehnica, nu una "de antreprenori". Nu le-a fost greu sa-si schimbe orientarea pentru ca ei stiu ca lumea ii admira mai mult pe cei care "fac business" decat pe cei care "stau in cutiuta lor si dau la taste".

Atitudinea este explicata de ceea ce Alain de Botton numeste anxietatea statutului: raspunsul pe care-l dai la intrebarea "cu ce te ocupi?" (sau in cazul studentilor: "la ce facultate esti?") decide eticheta pe care interlocuitorul ti-o va atribui în mintea lui. Anxietatea se amplifica si mai mult in cazul in care "programatorul" nu discuta cu un interlocutor, ci cu o interlocutoare.

Stereotipurile sunt partial justificate de felul in care functioneaza mintea umana. Creierul are o predispozitie pentru ordine si control. Este rezultatul experientei acumulate de-a lungul timpului, vreme in care creierul si-a exersat prinicipala sa preocupare: cea de a mentine organismul in viata. Desi asemanat de multe ori cu un computer foarte performant, creierul are in continuare de procesat o cantitate imensa de date, acumulate prin toate simturile noastre. Pentru a nu fi coplesit, e nevoit sa faca "optimizari", ceea ce inseamna de multe ori simplificarea lucrurilor, reducerea la o forma mai usor de inteles. Nu ai timp de intrat în detalii cu fiecare om pe care-l cunosti, deci esti nevoit uneori sa le pui etichete.

Nu e de mirare ca reductionismul a adus atat de mult progres omenirii, fiind o abordare populara in multe stiinte exacte. Totusi, reductionismul e o unealta foarte buna, dar care are limitarile sale. Aplicata in sisteme complexe poate duce la concluzii gresite. Oamenii sunt fiinte complexe. Stereotipurile sunt instrumentul perfect pentru a cadea in capcana reductionismului atunci cand vine vorba de oameni. Evolutia creierului ne da o scuza buna pentru superficialitatea cu care punem etichete, dar a aprecia oamenii pentru ceea ce sunt ei cu adevarat necesita o abordare holistica. Pana la eticheta de programatori, ei sunt mai întai oameni.

Cunosc pe cineva care s-a apucat de programare dupa ce a studiat dreptul si care este un programator excelent. Am cunoscut programatori care au explorat laturi nebanuite ale  personalitatii lor prin teatru sau muzica. Ei sunt oameni care au refuzat sa creada ca un stereotip le poate dicta personalitatea, insa fara a se jena de titlul de programator si fara a se revolta impotriva lui. Mai mult, refuza sa se complaca in imaginea tipului retras cu relatii sociale precare.

Pe de alta parte, stereotipul programatorului poate fi o confortabila sursa de autocompatimire. Dincolo de stereotip, responsabilitatea pentru imaginea sa ii apartine in totalitate omului tehnic. Dezvoltarea abilitatilor de programator si interesul foarte redus pentru cele sociale sunt alegeri a caror responsabilitate nu poate fi delegata. Kafka era un angajat al unei companii de asigurari, avand un job despre care deseori spunea ca il dispresuieste, dar in care era foarte bun, fiind chiar apreciat pentru rezultatele sale. Probabil raspunsul sau la intrebarea "cu ce te ocupi?" nu starnea admiratia celor din jur, dar Kafka era, in paralel cu jobul sau, foarte preocupat de opera sa literara. Putea la fel de bine sa fie pasionat de plante. Nu spun ca toti programatorii pot deveni acum niste mici Kafka, ci ca sunt ceea ce vor ei sa fie.

Poate o intrebare buna pentru a ne descoperi diverse valente care zac ascunse in noi ar fi: "Daca ai fi trait acum o suta de ani, ce ai fi fost?". Daca Eminescu ar fi trait in zilele noastre poate nu ne-ar mai fi oferit acelasi lucru. Poate parintii l-ar fi impins spre o politehnica sau un ASE tocmai din dorinta ca baiatul lor "sa se realizeze si sa faca multi bani intr-un domeniu care se cauta acum".

Recent vorbeam cu un prieten (absolvent de facultate tehnica) care incearca sa puna pe picioare un start-up si care imi spunea: "Imi trebuie un om care sa stie sa discute cu oamenii si care sa ma ajute sa vand ideea". Prima intrebare care mi-a venit in minte a fost: de ce nu ar putea fi chiar el omul respectiv? Cine sa fie mai entuziasmat decat el? Ok, sunt de acord ca nu trebuie sa crezi despre tine ca ai fi bun la toate, dar pana cand o sa atragi super-vanzatorul care sa vina alaturi de tine si sa vanda ideea, tu trebuie sa dai jos costumul de "programator" si sa te lupti pana in panzele albe sa-ti vinzi ideea. Asta doar daca tu crezi in ea cu adevarat.

Daca tu te crezi doar un programator, atunci asta vei fi.

P.S. Cei care nu sunt programatori, dar se regasesc in articol, pot inlocui "programator" cu orice alt job predispus la stereotipuri.

Acesta poate fi folositor in cazul unui hard-disk ce are permisiile NTFS date peste cap sau in cazul in care vreti sa accesati fisiere de pe o alta partitie pe care ati instalat Windows-ul, diferita de cea de pe care ati boot-at.

Apasati aici pentru a descarca utilitarul.

Sugestiile si comentariile sunt binevenite.

Nu doream sa renunt la Vista deoarece Windows 7 este totusi doar un beta, asa ca m-am gandit ca voi avea nevoie de inca o partitie curata pe care sa-l instalez. Cum aveam doar o singura partitie pe laptop, am zis sa o redimensionez pentru a face inca una. Aveam destul spatiul liber pe singura partitie existenta, cam 70 GB. Problema a a aparut cand am incercat sa redimensionez partitia existenta.

Mi-am adus aminte ca in Vista a fost introdusa o noua facilitate pentru NTFS, si anume Volume Shrink. Teoretic facilitatea ar trebui sa ma ajute sa micsorez o partitie NTFS pentru a face loc pentru inca una. Am dat click dreapta pe My Computer -> Manage iar apoi din fereastra aparuta m-am dus la Storage -> Disk Management. Am dat click dreapta pe partitie si apoi Shrink Volume.

Ar fi fost bine daca ar fi mers, dar din pacate nu a fost asa. Am primit un mesaj de eroare. De fiecare data cand am incercat sa folosesc facilitatea respectiva am avut probleme cu ea. Poate sunt eu ghinionist dar mi se pare ca facilitatea respectiva mai mult sta decat merge. Da, am incercat sa defragmentez discul, dar nici defragmentarea nu a ajutat. Se parea ca nu am cum sa instalez Windows 7, chiar daca aveam 70 GB liberi pe disc.

Solutia a venit de la o facilitate noua din Windows 7 si anume suportul nativ pentru fisiere VHD. Cei care au folosit Virtual PC sau Hyper-V stiu ca un fisier VHD (virtual hard disk) este folosit pentru a stoca discul unei masini virtuale. Windows 7 stie sa boot-eze si de pe un fisier VHD, nu numai de pe o partitie.

Mai exact, asta inseamna ca poti folosi un fisier VHD in loc de o partitie separata pentru a instala Windows. Intrebarea urmatoare ar fi cum instalezi Windows 7 pe un VHD?  La instalarea Windows-ului trebuie sa alegi o partitie, nu? Ei bine am cautat si am gasit un blog care spune cum sa faci asta.

Practic nu ai nevoie decat de DVD-ul de Windows 7 cu care pornesti sistemul (se pare ca de la Vista incoace DVD-urile de Windows s-au desteptat) si selectezi Windows Repair, pentru a intra in linia de comanda si a porni managerul de partitii diskpart. Apoi trebuie sa creezi un fisier VHD:

Create vdisk file=c:\<nume_fisier>.vhd maximum=<marime>

In loc de <nume_fisier> trebuie specificat numele fisierului si in loc de <marime> trebuie precizata marimea in MB a fisierului. De exemplu:

Create vdisk file=c:\win7.vhd maximum=40000

pentru a crea fisierul win7.vhd care poate avea maxim 40000 MB.

De ce maxim? In momentul in care fisierul VHD va fi creat el nu va folosi pe disc 40000 MB ci isi va mari dimensiunea pe masura ce se scrie in el. In cazul unei instalarii de Windows 7, spatiul folosit dupa instalare este undeva intre 7 si 8 GB. Asadar fisierul win7.vhd va ocupa doar 7-8 GB pe disc dupa instalare si nu aproape 40 GB cat s-ar putea crede initial.

Dupa ce fisierul a fost creat, acesta trebuie selectat si atasat. Faptul ca este atasat inseamna ca la instalarea Windows-ului se va vedea si el in lista discurilor pe care puteti instala Windows. Comenzile ce trebuiesc introduse in diskpart in cazul de fata sunt:

select vdisk file=c:\win7.vhd

si

attach vdisk.

In cazul in care v-ati incurcat putin in comenzi, am atasat un slideshow care arata desfasurarea procesului de instalare a lui Windows 7 pe un fisier VHD.

Practic, un singur fisier contine toata instalarea mea de Windows 7 si daca vreau sa ma mut pe alt calculator pot muta fisierul vhd cu mine si pot rula Windows 7 pe acel calculator.

Ce e important e ca si pe acel calculator sa fie instalat boot manager-ul care suporta pornirea de pe un vhd. In cazul de fata, avand Windows Vista initial si apoi instaland Windows 7 in paralel, boot manager-ul a fost actualizat la ultima versiune si anume cea din Windows 7.

Bineinteles, fisierul VHD poate fi folosit si intr-o masina virtuala cu Hyper-V sau orice alta solutie de virtualizare care stie sa interpreteze fisierele VHD. Formatul VHD e unul deschis (oricine ii poate vedea specificatiile si scrie un interpretor pt el). Ca urmare, chiar VirtualBox (solutia de virtualizare cumparata acum ceva timp de Sun) are mai nou suport pentru fisierele VHD.

In concluzie, daca vreti sa instalati Windows 7 si nu aveti cum sa faceti o partite separata pentru el, nu va ingrijorati. Atata timp cat aveti spatiu pentru un fisier, acel fisier poate fi folosit pentru a instala Windows 7.

Solutia a venit de la o metoda (pe care am descoperit-o acum ceva timp) de pacalire a securitatii din NTFS. Ideea de baza a aparut citind MSDN-ul, mai specific aceasta precizare referitoare la parametrul dwDesiredAccess al functiei CreateFile:

"If this parameter is zero, the application can query certain metadata such as file, directory, or device attributes without accessing that file or device, even if GENERIC_READ access would have been denied."

Ceea ce a iesit in final este un driver-filtru peste sistemul de fisiere care intermediaza deschiderea fisierului printr-o discutie de genul:

Aplicatie: Vreau drepturi de scriere pentru fisierul restrictionat.doc. Ce spui?

Driver-ul nostru catre sistemul de fisiere: Aplicatia vrea drepturi de scriere pentru fisierul restrictionat.doc

Sistemul de fisiere catre driver-ul nostru: Permisiile de securitate setate pe fisierul respectiv nu-mi permit sa fac acest lucru. Raspunsul este NU.

Driver-ul nostru catre sistemul de fisiere: Aplicatia vrea zero drepturi (dwDesiredAccess = 0) pentru fisierul restrictionat.doc

Sistemul de fisiere catre driver-ul nostru: Ok. Pot permite acest lucru. Raspunsul este DA.

Driver-ul nostru catre aplicatie: Sistemul de fisiere a spus DA.

Astfel pacalim sistemul de fisiere sa ne dea ok-ul pentru o anumita cerere, punand intrebarea la care stim ca sistemul de fisiere va raspunde intotdeauna DA. Deoarece sistemul de fisiere raspunde cu DA, sistemul de operare permite deschiderea handle-ului catre fisierul restrictionat.

In mod intuitiv ati putea crede ca handle-ul deschis are zero drepturi de acces, deci este inutil. Totusi sistemul de operare va crea un handle cu drepturile cerute initial de aplicatie. Folosind aceasta metoda puteti accesa orice fisier, indiferent de permisiile de securitate setate pentru el. Partea si mai frumoasa este ca tot codul din driver care implementeaza aceasta metoda are doar 3 linii. Nu este vorba de hook-uri complicate sau functii nedocumentate. Totul se realizeaza cu API-uri documentate.

Pentru a vedea o demonstratie despre cum lucreaza driver-ul respectiv si mai multe detalii tehnice, puteti accesa post-ul in limba engleza ce contine un video si un document PDF:

http://www.hobeanu.com/blog/bypassing-file-system-security-in-windows/

Aceasta metoda nu este considerata o gaura de securitate deoarece necesita incarcarea unui driver. In momentul in care un atacator are drepturi de a executa cod in kernel mode, sistemul este considerat compromis.

Testand driver-ul pe Windows Home Server cu Driver Verifier activat, sistemul s-a blocat dupa formatarea discului, afisand un binecunoscut ecran albastru.

Pentru a identifica sursa erorii, am recreat conditiile aparitiei bug-ului cu debugger-ul (WinDbg) atasat la sistemul de operare.

Analizand crash-ul cu ajutorul lui WinDbg, am observat urmatorul mesaj:

kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 0000000c, Invalid IOSB in IRP at APC IopCompleteRequest (appears to be on
 stack that was unwound)
Arg2: b9b02810, IOSB address
Arg3: 00000000, IRP address
Arg4: 00000000, 0

Mai mult, analiza spunea ca driver-ul care a cauzat eroarea este chiar driver-ul nostru (MYDRIVER).

BUGCHECK_STR:  0xc9_c

DRIVER_VERIFIER_IO_VIOLATION_TYPE:  c

IOSB_ADDRESS: ffffffffb9b02810

IRP_ADDRESS:  82f5af20

DEFAULT_BUCKET_ID:  DRIVER_FAULT

PROCESS_NAME:  explorer.exe

CURRENT_IRQL:  1

DEVICE_OBJECT: 8186f030

DRIVER_OBJECT: 8179a158

IMAGE_NAME:  MYDRIVER.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  48693683

MODULE_NAME: MYDRIVER

FAULTING_MODULE: b9878000 MYDRIVER

Aveam toate motivele sa credem ca avem un bug in driver, deci am pornit la vanatoare.

Putina teorie

In Windows, cererile adresate unui dispozitiv sunt impachetate sub forma de IRP-uri (I/O Request Packet). In cazul de fata, dispozitivul este discul virtual creat de driver-ul nostru. Astfel, discul virtual primeste cereri de citire/scriere de la aplicatii. Pentru a comunica cu discul virtual aplicatia de formatare foloseste API-ul pus la dispozitie de Windows. Aceste apeluri se traduc in apeluri catre kernel.

Kernel-ul traduce apelurile respective in cereri (IRP-uri) catre dispozitivul virtual, acestea fiind preluate de catre driver-ul nostru si procesate. Dupa ce procesarea s-a incheiat, driver-ul trebuie sa indice initiatorului cererii rezultatul procesarii acesteia. Pentru acest lucru, in structura IRP se gaseste un camp numit Iosb (I/O Status Block), care contine un pointer catre o variabila de tipul IO_STATUS_BLOCK in care vor fi copiate informatii despre rezultatul procesarii.

typedef struct _IO_STATUS_BLOCK {
    union {
        NTSTATUS Status;
        PVOID Pointer;
    };
    ULONG_PTR Information;
} IO_STATUS_BLOCK, *PIO_STATUS_BLOCK;

Variabila de tip IO_STATUS_BLOCK este de obicei definita local (spatiul pentru variabila este alocat pe stiva firului de executie). Daca informatiile necesare pentru procesarea cererii nu sunt disponibile in momentul in care driver-ul primeste cererea, aceasta este introdusa intr-o coada de asteptare si initiatorul cererii (o aplicatie sau un alt driver) este notificat de acest lucru prin intoarcerea valorii STATUS_PENDING (0x103).

Daca o functie din kernel intoarce valoarea STATUS_PENDING, inseamna ca cererea va fi procesata asincron si este nevoie ca apelantul sa astepte pana cand cererea va fi procesata complet. Fiind procesata asincron, completarea procesarii se va realiza in alt fir de executie decat cel in care s-a initiat cererea. In acel fir de executie driver-ul apeleaza functia IoCompleteRequest pentru a indica terminarea procesarii cererii (IRP). Aceasta functie copiaza informatiile despre rezultatul procesarii in variabila indicata de campul Iosb.

Totusi, apelul lui IoCompleteRequest este realizat in alt fir de executie decat cel pe a carui stiva a fost declarata variabila indicata de pointer-ul Iosb din structura IRP. Asadar, copierea nu se poate realiza direct deoarece un fir de executie nu poate accesa direct stiva altuia. Pentru a rezolva aceasta problema, Windows se foloseste de mecanismul numit APC (Asynchronous Procedure Call). Un APC este o functie care se executa in contextul unui anumit fir de executie. In cazul nostru, avem nevoie ca functia IoCompleteRequest sa se execute in contextul firului de executie care contine pe stiva sa variabila indicata de campul Iosb.

De ce trebuie sa stiu toate astea?

In cazul nostru, mesajul de eroare (“Invalid IOSB in IRP at APC IopCompleteRequest”) ne spune ca in IRP se gaseste un pointer invalid catre o variabila de tip IO_STATUS_BLOCK. Pentru a afla sursa erorii, trebuie sa aflam originea acestei cereri. Analizam stiva pentru a vedea in cadrul carei functii a fost definita variabila indicata de campul Iosb (b9b02810).

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 0000000c, Invalid IOSB in IRP at APC IopCompleteRequest (appears to be on
 stack that was unwound)
Arg2: b9b02810, IOSB address
Arg3: 00000000, IRP address
Arg4: 00000000, 0

Pentru a examina stiva, apelam comanda k.

kd> k
ChildEBP RetAddr
b9b02668 80825b3b nt!RtlpBreakWithStatusInstruction
b9b026b4 80826a2f nt!KiBugCheckDebugBreak+0x19
b9b02a4c 80826dc7 nt!KeBugCheck2+0x5d1
b9b02a6c 809ad6da nt!KeBugCheckEx+0x1b
b9b02a88 80820b52 nt!IovpCompleteRequest+0x4e
b9b02ae0 8082c34e nt!IopCompleteRequest+0x3a
b9b02b30 8082eceb nt!KiDeliverApc+0xb8
b9b02b4c 80827bbe nt!KiExitDispatcher+0xb1
b9b02b5c 80828950 nt!KiAdjustQuantumThread+0xca
b9b02ba4 bf89ab53 nt!KeWaitForSingleObject+0x47c
b9b02c00 bf8c4bd6 win32k!xxxSleepThread+0x1be
b9b02c9c bf8a13c0 win32k!xxxInterSendMsgEx+0x798
b9b02ce8 bf8a130f win32k!xxxSendMessageTimeout+0x1f3
b9b02d0c bf86d127 win32k!xxxSendMessage+0x1b
b9b02d30 bf83ba31 win32k!xxxEnableWindow+0x70
b9b02d50 80883908 win32k!NtUserCallHwndParamLock+0x6e
b9b02d50 7c8285ec nt!KiFastCallEntry+0xf8
023ef800 7738a8db ntdll!KiFastSystemCallRet
023ef828 7739f762 USER32!NtUserCallHwndParamLock+0xc
023efae8 7739f047 USER32!SoftModalMessageBox+0x94b
023efc38 7739eec9 USER32!MessageBoxWorker+0x2ba
023efc90 7739ee65 USER32!MessageBoxTimeoutW+0x7a
023efcb0 7739ee41 USER32!MessageBoxExW+0x1b
023efccc 77de2425 USER32!MessageBoxW+0x45
023efd98 7c9c5d37 SHLWAPI!ShellMessageBoxWrapW+0xd4
023efdc4 694721e3 SHELL32!FormatCallback+0x160
023eff78 7c9c6b62 FMIFS!FormatEx+0x2f0
023effb8 77e64829 SHELL32!BeginFormat+0x161
023effec 00000000 kernel32!BaseThreadStart+0x34

Prima coloana din tabel reprezinta adresa de inceput a zonei de stiva folosite de functia respectiva pentru stocarea variabilelor locale. In Windows, alocarea de spatiu pe stiva pentru variabile locale se face la adrese descrescatoare. Astfel, se explica de ce valorile coloanei ChildEBP sunt descrescatoare tinand cont de ordinea apelarii functiilor (prima functie apelata este ultima functie listata in tabel – kernel32!BaseThreadStart). A doua coloana reprezinta adresa de unde se va continua executia dupa terminarea functiei. De exemplu, observam ca zona alocata pentru variabilele locale ale functiei FMIFS!FormatEx, incepe la adresa 023eff78.

Pentru a gasi functia in interiorul careia s-a definit variabila de tip IO_STATUS_BLOCK, cautam in tabel prima valoare a coloane ChildEBP care este mai mare decat adresa IOSB (b9b02810). Uitandu-ne in tabel, s-ar parea ca ea a fost definita de catre functia nt!KeBugCheck2.

Totusi, este putin probabil ca o functie responsabila cu afisarea ecranului albastru (nt!KeBugCheck2) sa fi fost cea care a initiat cererea. Acest lucru ne spune ca valoarea identificata in tabel nu este corecta si banuim ca functia pe care o cautam nu a mai asteptat procesarea completa a cererii, ea terminandu-se si dealocand spatiul de stiva folosit. In cazul nostru, acest spatiu a fost refolosit mai tarziu de catre functia nt!KeBugCheck2. Mesajul de eroare ne confirma acest lucru (“appears to be on stack that was unwound”). In cazul in care functia ar fi asteptat terminarea procesarii cererii, numele ei s-ar fi regasit in tabelul de mai sus.

Cum aflam totusi functia vinovata de aparitia ecranului albastru?

Prima data am vrut sa aflam la procesarea carei cereri apare aceasta problema. Pentru acest lucru am inspectat IRP-ul indicat de analiza WinDbg.

kd> !irp 82f5af20
Irp is active with 3 stacks 5 is current (= 00000000)
 No Mdl: System buffer=81801b90: Thread 81810dd8:  Irp is completed.  Pending has been returned
     cmd  flg cl Device   File     Completion-Context
 [  0, 0]   0  2 00000000 00000000 00000000-00000000

   Args: 00000000 00000000 00000000 c0000010
 [  e, 0]   0 10 8186f030 00000000 f814038e-00000000
        \Driver\MYDRIVER Ntfs!DeviceControlCompletionRoutine
   Args: 00000000 00000000 00000000 00000000
 [  e, 0]   0 10 81730020 00000000 00000000-00000000
        \FileSystem\Ntfs
   Args: 00000000 00000000 00000000 00000000

Observam in campul cmd prezenta valorii hexazecimale 0xe. Analizand fisierul wdm.h din Windows Driver Kit, observam ca aceasta valoare corespunde unui IRP de tip IRP_MJ_DEVICE_CONTROL:

#define IRP_MJ_DEVICE_CONTROL           0x0e

Driver-ul nostru proceseaza asincron acest tip de cereri, introducandu-le intr-o coada de procesare si intorcand valoarea STATUS_PENDING.

Am recreat conditiile aparitiei bug-ului si am definit un breakpoint in driver-ul nostru la momentul introducerii cererii in coada de procesare. In momentul in care breakpoint-ul este atins, afisam informatii despre thread-ul in care ne aflam.

kd> !thread
THREAD 8183e5f0  Cid 09ac.0f20  Teb: 7ffaa000 Win32Thread: e19fec30 RUNNING on processor 0
IRP List:
    82610f20: (0006,00dc) Flags: 40000070  Mdl: 00000000
    830b8f20: (0006,00dc) Flags: 40000884  Mdl: 00000000
Not impersonating
DeviceMap                 e15f34c0
Owning Process            818148a8       Image:         explorer.exe
Wait Start TickCount      18455          Ticks: 0
Context Switch Count      683                 LargeStack
UserTime                  00:00:00.000
KernelTime                00:00:00.046
Win32 Start Address SHELL32!BeginFormat (0x7c9c6a01)
Start Address kernel32!BaseThreadStartThunk (0x77e617ec)
Stack Init b9c5b000 Current b9c5a280 Base b9c5b000 Limit b9c57000 Call 0
Priority 10 BasePriority 8 PriorityDecrement 2
ChildEBP RetAddr  Args to Child
b9c5a368 b98537d6 817ca030 82610f20 817ca0e8 MYDRIVER!DispatchVolumeDeviceObject+0xcf
b9c5a37c 809ad50c 817ca030 82610f20 82610fd0 MYDRIVER!DispatchIrp+0x26
b9c5a3ac 8081d571 f816bef6 b9c5a420 f816bef6 nt!IovCallDriver+0x112
b9c5a3b8 f816bef6 82610f20 b9c5a43c 00000000 nt!IofCallDriver+0x13
b9c5a420 f8174ab9 b9c5a498 82610f20 80a51c86 Ntfs!NtfsCommonDeviceControl+0xef
b9c5a484 f818002f b9c5a498 82610f20 00000001 Ntfs!NtfsFsdDispatchSwitch+0xe4
b9c5a5a0 809ad50c 81849718 82610f20 817ace80 Ntfs!NtfsFsdDispatchWait+0x1c
b9c5a5d0 8081d571 f81fed28 b9c5a608 f81fed28 nt!IovCallDriver+0x112
b9c5a5dc f81fed28 00000000 817ace80 80a51c86 nt!IofCallDriver+0x13
b9c5a608 809ad50c 817ace80 82610f20 82610f20 fltMgr!FltpDispatch+0x152
b9c5a638 8081d571 808ed3e1 b9c5a658 808ed3e1 nt!IovCallDriver+0x112
b9c5a644 808ed3e1 82610fd8 81888f90 82610f20 nt!IofCallDriver+0x13
b9c5a658 808ee169 817ace80 82610f20 81888f90 nt!IopSynchronousServiceTail+0x10b
b9c5a6f4 808e6cca 80000b64 00000000 00000000 nt!IopXxxControlFile+0x5e5
b9c5a728 80883908 80000b64 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
b9c5a728 8082cc25 80000b64 00000000 00000000 nt!KiFastCallEntry+0xf8
b9c5a7c8 f84abfff 80000b64 00000000 00000000 nt!ZwDeviceIoControlFile+0x11
WARNING: Stack unwind information not available. Following frames may be wrong.
b9c5a818 f84af34c 81751008 80877b86 817a2798 DEfilter+0x4fff
b9c5a844 f820d72d 0000004a 00000005 00000008 DEfilter+0x834c
b9c5a878 f820dcb4 8180a218 00000005 8088cb2e fltMgr!FltpDoInstanceSetupNotification+0x4b
b9c5a8d8 f820e03f 8222a3e8 817a2798 00000005 fltMgr!FltpInitInstance+0x272
b9c5a948 f820e14a 8222a3e8 817a2798 00000005 fltMgr!FltpCreateInstanceFromName+0x295
[...]

Dorim sa aflam adresa IOSB-ului, deci analizam IRP-ul (evidentiat cu rosu mai sus).

kd> !irp 82610f20 1
Irp is active with 3 stacks 2 is current (= 0x82610fb4)
 No Mdl: System buffer=817ceaa8: Thread 8183e5f0:  Irp stack trace.
Flags = 40000070
ThreadListEntry.Flink = 830b8f30
ThreadListEntry.Blink = 8183e7f8
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000000
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = b9c5a810
UserEvent = 00000000
[...]

Dupa ce am obtinut adresa IOSB-ului, folosim acelasi algoritm ca si mai sus pentru a afla functia in care este declarata variabila. Astfel, identificam o functie din driver-ul DEfilter:

[...]
b9c5a7c8 f84abfff 80000b64 00000000 00000000 nt!ZwDeviceIoControlFile+0x11
WARNING: Stack unwind information not available. Following frames may be wrong.
b9c5a818 f84af34c 81751008 80877b86 817a2798 DEfilter+0x4fff
b9c5a844 f820d72d 0000004a 00000005 00000008 DEfilter+0x834c
[...]

Dupa cum se vede din stiva firului de executie, aceasta functie apeleaza functia ZwDeviceIoControlFile pentru a trimite o cerere catre discul virtual. Banuim ca aceasta este functia cautata. Pentru a confirma acest lucru, definim un nou breakpoint inaintea apelarii IoCompleteRequest de catre driver-ul nostru. Cand executia atinge acel punct analizam din nou stiva firului de executie care a initiat cererea.

kd> !thread 8183e5f0
THREAD 8183e5f0  Cid 09ac.0f20  Teb: 7ffaa000 Win32Thread: e19fec30 WAIT: (Unknown) UserMode Non-Alertable
    81850a80  SynchronizationEvent
IRP List:
    82610f20: (0006,00dc) Flags: 40000070  Mdl: 00000000
Not impersonating
DeviceMap                 e15f34c0
Owning Process            818148a8       Image:         explorer.exe
Wait Start TickCount      18468          Ticks: 0
Context Switch Count      771                 LargeStack
UserTime                  00:00:00.000
KernelTime                00:00:00.156
Win32 Start Address SHELL32!BeginFormat (0x7c9c6a01)
Start Address kernel32!BaseThreadStartThunk (0x77e617ec)
Stack Init b9c5b000 Current b9c5ac68 Base b9c5b000 Limit b9c56000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0
ChildEBP RetAddr  Args to Child
b9c5ac80 8082ffb7 8183e5f0 8183e698 00000181 nt!KiSwapContext+0x25
b9c5ac98 808287b4 00000000 e19fec30 00000000 nt!KiSwapThread+0x83
b9c5acdc bf89ab53 81850a80 0000000d 00000001 nt!KeWaitForSingleObject+0x2e0
b9c5ad38 bf89d9c3 000024ff 00000000 00000001 win32k!xxxSleepThread+0x1be
b9c5ad4c bf89e381 000024ff 00000000 023ef7d4 win32k!xxxRealWaitMessageEx+0x12
b9c5ad5c 80883908 023ef800 7c8285ec badb0d00 win32k!NtUserWaitMessage+0x14
b9c5ad5c 7c8285ec 023ef800 7c8285ec badb0d00 nt!KiFastCallEntry+0xf8
023ef800 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet

Banuiala ne este confirmata analizand stiva (driver-ul DEfilter nu apare pe stiva). Pentru a ne convinge ca functia din driver-ul DEfilter nu asteapta terminarea procesarii, dezasamblam codul de dupa apelul catre ZwDeviceIoControlFile (adresa indicata mai sus in stiva firului de executie).

kd> u DEfilter+0x4fff
DEfilter+0x4fff:
f84abfff 3bc6            cmp     eax,esi
f84ac001 5e              pop     esi
f84ac002 750c            jne     DEfilter+0x5010 (f84ac010)
f84ac004 8b4df0          mov     ecx,dword ptr [ebp-10h]
f84ac007 894f78          mov     dword ptr [edi+78h],ecx
f84ac00a 8b4df4          mov     ecx,dword ptr [ebp-0Ch]
f84ac00d 894f7c          mov     dword ptr [edi+7Ch],ecx
f84ac010 5f              pop     edi
f84ac011 c9              leave
f84ac012 c20400          ret     4

Observam ca nu se verifica daca valoarea intoarsa de ZwDeviceIoControlFile (prezenta in registrul eax) este STATUS_PENDING (0x103).

Cine este DEfilter?

DEfilter.sys este un driver prezent numai in Windows Home Server. Acesta implementeaza facilitatea Drive Extender. Aceasta facilitate reuneste toate dispozitivele de stocare pe care le atasati unui Windows Home Server, facandu-le sa apara ca un singur hard-disk mare. Asadar, are nevoie de un driver filtru peste sistemul de fisiere (DEfilter) pentru a vedea cand apare un disc nou. Deoarece driver-ul nostru creeaza un disc virtual, acesta este luat in considerare de catre DEfilter dupa formatare.

Concluzie

Prin urmare, sursa bug-ului este driver-ul DEfilter.sys din Windows Home Server care face presupunerea (eronata) ca cererea va fi intotdeauna procesata sincron. Asadar, daca unul din driver-ele care proceseaza cererea va decide sa o faca asincron (asa cum este driver-ul nostru), sistemul va crapa.

Am raportat acest bug la Microsoft si asteptam confirmarea sa.

Iata si dilema mea:

Varianta 1 de curs de Dezvoltare Software predat la Facultatea de Matematica si Informatica, Universitatea Bucuresti:

http://funinf.cs.unibuc.ro/~vec/flp.htm

Varianta 2 de curs de Dezvoltare Software predat la aceeasi facultate, de catre alt domn profesor:

http://www.cs.unibuc.ro/~radu/rg_MDS_I_II_prog.html

Observati vreo diferenta intre ele? Daca va intrebati, eu am avut (ne)placerea de a studia prima varianta. Desi titlul de pe pagina primului curs (Fundamentele limbajelor de programare) nu duce cu gandul la dezvoltare software, aceea este materia care a fost predata intr-un curs cu numele "Dezvoltare software". Pentru cei curiosi, in prima varianta este vorba despre un singur curs predat de catre acelasi profesor sub mai multe denumiri, pe parcursul anilor de facultate. Morala: mai multe denumiri, mai multe sanse de castig.

Din pacate, cel care are cel mai putin de castigat de aici este studentul. Trecand prin cursul mentionat in prima varianta un student se poate demotiva foarte usor, pierzandu-si astfel interesul pentru subiectele predate in facultate.

Mai trist este faptul ca am exemple de colegi foarte buni si pasionati de software, cu realizari importante, a caror foaie matricola contine nota 5 la subiectul Dezvoltare Software (studiat in varianta 1). Am inca un motiv in plus pentru a realiza ca nota si-a pierdut semnificatia in scoala romaneasca.

Scurt si cuprinzator?

Apoi il citeai si incercai sa intelegi ce ai scris acolo, sa-ti explici cum functioneaza algoritmul si, eventual, de ce ai scris asa si nu altfel. In momentul respectiv, creierul facea un pas in plus: descifrarea a ce inseamna n, ce inseamna i sau k. Poate nu pare mare lucru sa tii minte trei nume de variabile si sensul atasat fiecaruia, dar cand te apuci sa scrii o expresie care le foloseste pe toate trei in acelasi timp, lucrurile parca se complica putin.

M-am uitat de curiozitate pe arhiva educationala de pe infoarena, o initiativa de apreciat de altfel, ce pune la dispozitia vizitatorilor site-ului o serie de probleme pe care aproape orice elev/student le intalneste in scoala. Un lucru care mi-a placut mai putin si pe care il faceam si eu in liceu este economia de litere cand vine vorba de numele variabilelor. Este parca o obsesie generala aceea de a folosi o singura litera pentru numele unei variabile, eventual sa-i mai punem si o cifra in coada in cazurile in care alfabetul nu ne poate oferi mai multe litere.

As vrea ca atunci cand citesc un algoritm sa il citesc natural, sa nu stau la fiecare linie sa-mi spun: “a...este q, si q este notatia pentru... deci...”. Am cautat sa vad de unde vine “zgarcenia” cu care suntem invatati in scoala. Da, scoala ne ofera acest model si ne da impresia ca este "modul corect" de a face lucrurile. Cel putin asa a fost in cazul meu.

Originea zgarceniei

Banuiesc ca originea zgarceniei se gaseste in relatia cu matematica. In problemele de matematica notam cu x,y,z etc. toate variabilele de care avem nevoie si lucrurile chiar merg bine acolo. De ce acolo merg si aici nu? Cred ca in "implementarea" solutiilor problemelor de matematica avem in medie mai putine "instructiuni" si "variabile" pe foaie/caiet decat in cazul problemelor de informatica. Cate rezolvari de probleme de matematica de sute sau mii de “linii de cod” ati vazut? Eu niciuna. Tin minte ca in gimnaziu, cand aveam la matematica o problema a carei rezolvare depasea doua table, apareau dificultati in a intelege de fapt care era valoarea unei "variabile", ce reprezenta ea si unde a fost "modificata" ultima data.

De aici trag concluzia ca informatica nu se mananca in acelasi fel ca si matematica. Profesorii de informatica ar trebui sa tina cont si de lucruri ce tin de modul de scriere al codului. Aceste lucruri le-ar fi folositoare elevilor/studentilor in timpul concursurilor, cand isi recitesc algoritmul, si mai tarziu in cariera de dezvoltatori software. Si asta nu numai la clasa, ci si in toate rezolvarile pe care le propun pentru o culegere de probleme sau pentru un site gen infoarena.

In toti anii de scoala (atat in liceu cat si in facultate) nu am intalnit niciun profesor care sa scrie cod zilnic sau frecvent. Poate de aici rezulta si ignoranta pentru felul in care codul este scris.

Cum ne vindecam de zgarcenie

De ce e important sa scriem cod usor de citit? Jeff Atwood da un raspuns:

If you ask a software developer what they spend their time doing, they'll tell you that they spend most of their time writing code.

However, if you actually observe what software developers spend their time doing, you'll find that they spend most of their time trying to understand code.

Joel Spolsky spune concis:

It's harder to read code than to write it.

Cred ca este datoria fiecarui dezvoltator software sa-si imbunatateasca permanent modul in care scrie cod. Usureaza in primul rand munca sa si, in al doilea rand, pe cea a celor care vor fi nevoiti sa-I citeasca liniile de cod.

O resursa foarte buna pentru vindecarea “zgarceniei” o reprezinta cartea Code Complete, 2nd Edition a lui Steve McConnell, in principal capitolele 31 (Layout and Style), 32 (Self-Documenting Code) si 34 (Themes in Software Craftmanship).

"Write Programs for People First, Computers Second"

In cazul unui proiect cum este arhiva educationala a infoarena este cu atat mai important ca solutiile problemelor sa fie prezentate intr-o maniera cat mai usor de inteles. Principalul scop al unui cititor este sa inteleaga solutia/algoritmul, nu sa piarda timp descifrand codul “destept” sau “concis” al unei solutii.

Scriind cod mai concis, economisesc timp pretios pentru implementarea solutiei

Acest mit ia nastere mai ales in cazul concursurilor de programare, unde viteza de rezolvare a unei probleme este esentiala pentru reusita. Aceasta “economisire” de timp induce de fapt mai multe penalizari de timp in momentul citirii codului.

Steve McConnell:

Making code readable is not an optional part of the development process, and favoring write-time convenience over read-time convenience is a false economy. You should go to the effort of writing good code, which you can do once, rather than the effort of reading bad code, which you'd have to do again and again.

Dar daca scriu cod numai pentru mine? Nu conteaza cum il scriu, oricum nu-l citesc decat eu.

Steve McConnell avertizeaza si in privinta acestei capcane:

The idea of writing unreadable code because you're the only person working on a project sets a dangerous precedent. Your mother used to say, "What if your face froze in that expression?" And your dad used to say, "You play how you practice." Habits affect all your work; you can't turn them on and off at will, so be sure that what you're doing is something you want to become a habit. A professional programmer writes readable code, period.

Liceul si facultatea reprezinta perioada in care se formeaza primele obieciuri de programare. Recent am fost neplacut surprins sa vad o lucrare (dealtfel foarte buna) la un concurs de software pentru elevi si studenti, scrisa de un student in anul I, cu experienta declarata de 7 ani de progamare, care pentru citirea propriului format din fisier folosea numai variabile denumite in genul i1...in. Codul respectiv arata foarte “egoist”, scris parca doar pentru autorul lucrarii,  fara sa ia in calcul posibilitatea ca cineva sa foloseasca acel cod vreodata.

Chiar daca momentan mi se pare fantezista ideea de a vedea pe vreunul din fostii mei profesori (din liceu sau facultate) urmand sfaturile de mai sus, as fi fost mai mult decat incantat daca as fi invatat cum sa scriu cod de la ei. Probabil ca pentru a te lovi de aceste lucruri trebuie sa fi scris software mai intai.

Prima data am aflat de un concurs de acest gen cand eram in liceu, in clasa a 9-a, cu 3 zile inainte de organizarea unei "sesiuni de comunicari pentru elevi" asa cum se numea pe atunci. Am aflat mai apoi ca era vorba despre faza judeteana a unui concurs national de software - NoiInfo - ce urma sa se desfasoare la Timisoara. M-am apucat impreuna cu Razvan sa lucram la o aplicatie si n-am dormit noptile pana la concurs, de frica lipsei de timp. Ne-am dus cu programul pe o discheta, ne-am calificat mai departe. Am plecat la Timisoara cu mare entuziasm si ne-am intors cu o mare dezamagire. Am avut prezentarea programata pe la 8 seara, cand juriul ne-a incurajat inainte de a incepe: "daca ati putea sa terminati mai repede, v-am fi recunoscatori". Totul nu a durat mai mult de 5 minute, deoarece juriul probabil era cu gandul mai mult la cina decat la aplicatia noastra.

Ne-am intrebat daca nu cumva am avut asteptari prea mari de la juriu. Prezentasem o aplicatie client-server prin care un calculator se putea controla de la distanta de la un alt calculator. In juriu erau 2 studenti si 2-3 profesori. Daca de la profesori multi participanti nu se asteapta de obicei sa primeasca intrebari prea tehnice (desi cunoastem exceptii notabile), de la cei doi studenti ne asteptam la mai multe cunostinte si mai multe intrebari. Ne asteptam sa ne intrebe cum facem transferul capturilor de ecran, cum compresam fisierele transferate, cate resurse de calcul necesita.. Nu am primit nicio intrebare tehnica. Am primit numai doua intrebari din partea juriului, grabiti spre masa de seara, dupa care prezentarea s-a terminat. Mai mult, desi in formularul de inscriere indicasem nevoia a doua calculatoare legate in retea pentru o prezentare optima, am fost nevoiti sa prezentam aplicatia pe un singur calculator.

In clasamentul final am iesit pe ultimele locuri. Dezamagiti, dar dornici de a obtine sugestii de imbunatatire, i-am abordat pe cei doi studenti. Dupa ce i-am intrebat cum am putea sa ne imbunatatim proiectul a urmat o pauza de cateva secunde, dupa care ne-au raspuns: "mai cititi pe acolo prin MSDN cum se poate face mai bine".

Urmatorul concurs la care am participat a fost faza nationala a InfoEducatie, un concurs care va ajunge anul acesta la a 14-a editie. InfoEducatie este primul si cel mai longeviv concurs de acest gen din Romania. La prima participare am aflat de un nou concept: intrebarile din public. Daca la NoiInfo intrebarile veneau numai din partea juriului, la InfoEducatie intrebarile pot veni din partea tuturor celor prezenti la prezentare. In opinia noastra, acesta este unul din punctele forte ale concursului. Un alt concept de care am aflat la InfoEducatie, a fost acela de copiere a lucrarilor. Am asistat la prezentarea unui baiat de clasa a 7-a care genera executabile pentru self-extract de imagini. Curios fiind de modul de generare a executabilului, l-am rugat sa ne arate codul sursa, pentru a vedea ca nu era scris de el, desi sustinea contrariul.

Povestioara de mai sus ne-a lasat la momentul respectiv un gust amar, calitatea juriului si onestitatea participantilor fiind in opinia noastra cele mai sensibile aspecte ale concursurilor de software de pe la noi. Deoarece ca particpanti ne-am lovit de multe ori de aceste aspecte, am considerat mai tarziu necesara implicarea in astfel de concursuri pentru a incerca sa schimbam ceva.

Desi am participat in juriu la mai multe concursuri de acest gen, observam ca vechile practici ale concurentilor raman neschimbate. Exista printre anumiti participanti mentalitatea ca juriul nu are competenta tehnica pentru a evalua lucrarile si astfel se incearca exploatarea acestei ipoteze. La toate concursurile unde am fost membri ai juriului s-a intamplat sa gasim, din pacate, cel putin o lucrare copiata. Cel mai rau este atunci cand astfel de lucrari iau premii si medalii, asa cum am vazut ca a fost cazul la cateva concursuri.

Ca sa nu fim intelesi gresit, este absolut OK sa se foloseasca cod existent, pentru ca nu vrem mereu sa reinventam roata, atata timp cat acest lucru este specificat si se delimiteaza contributia personala a participantului.

Personal am privit concursurile de software ca pe un mod de dezvoltare personala si profesionala, incepand de la cunostintele de programare si terminand cu abilitatile de prezentare in fata unei audiente largi si intr-un timp limitat. Am dobandit multe cunostinte tehnice lucrand la proiecte pe care le-am prezentat la InfoEducatie, privind an de an concursul si competitia ca pe o sansa de a inova sau cel putin de a acumula noi cunostinte.

Este trist faptul ca singurul castig pe care il vad unii participanti este cel material. Din pacate, acesta este unul pe termen scurt.  Multe din proiectele realizate sunt "pentru a lua premiu" si nu pentru a rezolva o nevoie existenta sau pentru acumularea de cunostinte. De asemenea, multi dintre participanti doresc un castig rapid cu un efort minim, timpul alocat dezvoltarii proiectelor fiind tot mai mic. Fenomenul este similar cu cel din mediul online, unde multi viseaza sa faca peste noapte urmatorul YouTube sau Facebook fara prea mult efort.

Exista totusi si exceptii, asa cum este infoarena, un proiect prezentat pentru prima oara in 2003 la InfoEducatie si dezvoltat ulterior in cea mai puternica comunitate online romaneasca pentru cei interesati de algoritmica.

In momentul de fata, firmele se plang ca nu gasesc absolventi bine pregatiti, iar un raport recent spune ca elevii romani sunt tot mai slab pregatiti. Oare daca am incuraja si sprijini mai mult concursurile de creatie software precum InfoEducatie, CIA si InfoMatrix (la liceu) si ImagineCup (pentru facultate), situatia ar fi diferita?

Stim cu totii ca Windows este un sistem de operare closed-source si nu avem libertatea de a-i examina codul sursa pentru a ne rezolva problemele. Totusi, Microsoft a avut initiative menite sa rezolve intr-o anumita masura aceasta problema. Pentru studenti, o foarte buna resursa o reprezinta Windows Academic Program, mai ales prin WRK.

Cu toate acestea, accesul la codul sursa nu poate rezolva eficient problema interoperabilitatii. Pentru ca un client Linux sa partajeze fisiere intre el si un client Windows, a fost nevoie de reverse engineering pentru a "ghici" protocolul de comunicare folosit intre clientii Windows (SMB), rezultand astfel Samba.

In Vista a fost introdusa versiunea 2.0 a protocolului SMB. Detaliile noii versiuni a protocolului nu au fost facute publice. Singura solutie pentru membrii proiectului Samba era sa apeleze din nou la reverse engineering. Cu o structura a pachetelor total diferita de vechiul SMB, SMB2 anunta o munca asidua pentru asigurarea interoperabilitatii cu clientii Vista. Analizand implementarea SMB2 din versiuni beta ale Windows Vista, echipa din spatele Samba a reusit sa ofere suport experimental pentru SMB2 in versiunea 4.0.0TP3, lansata pe 13 Octombrie 2006.

O stire din 22 decembrie 2007 spunea ca Samba a semnat un acord cu Microsoft prin care dezvoltatorii Samba primeau acces la specificatiile protocolului SMB2. Pentru a putea accesa documentele Samba a platit 10,000€. Totusi, cu o floare (una costisitoare) nu se face primavara in problema interoperabilitatii. Cum ramane cu restul protocoalelor de comunicatie care sunt necesare pentru a asigura interoperabilitatea?

Un comunicat de presa din 21 februarie prezinta o impresionanta schimbare de strategie pentru Microsoft, prin Open Protocol Specifications care ofera access la specificatiile protocoalelor folosite in versiunile client si server ale sistemului de operare Windows. Specificatiile pot fi folosite pentru a dezvolta si distribui implementari non-comerciale ale protocoalelor documentate.

Dezvoltatorii proiectului Samba sunt cu siguranta bucurosi sa citeasca specificatia protocolui SMB2 in forma aceasta, decat sa piarda timpul analizand pachete.

Sfatul meu e sa te duci la o facultate mai lejera si sa inveti singur. Altfel risti sa-ti mananci timpul cu stresuri inutile, timp pe care altfel l-ai folosi pentru a invata. Personal, in Bucuresti, am gasit cea mai buna combinatie intre subiectele abordate si timpul liber la Facultatea de Matematica si Informatica de la Universitate. Bineinteles, acest lucru il poti gasi si in alta parte in functie de cat timp decizi tu sa aloci pentru facultate si cat de mult te intereseaza notele.

Facultatea e buna in sensul ca-ti ofera un context din care sa afli ca anumite lucruri/concepte exista. Ca sa-ti dau un exemplu concret, nu cred ca m-as fi apucat prea repede sa citesc despre limbaje formale si sa aflu cat de utile sunt daca nu as fi trecut prin facultate. Dar, de cele mai multe ori facultatea nu te ajuta cu mai mult deoarece am intalnit multe cursuri de tip dictare in care esti fortat sa-ti testezi viteza cu care te tii cu scrisul dupa profesor.

Oricum asta nu trebuie sa te opreasca pentru ca experienta din facultatile romanesti ne arata ca tot pe cont propriu se invata cel mai bine. Dictarea nu numai ca-ti omoara interesul si te face sa te intrebi de ce te mai duci la curs cand poti face altceva in timpul respectiv, dar nici nu-ti da vreo motivare legata de "de ce ar trebui sa fiu eu interesat de aceste lucruri? unde le pot aplica?". Personal nu-mi place sa invat doar de dragul teoriei. Vreau sa stiu ca pot aplica acele lucruri, ca pot construi ceva pe baza lor. Gasirea raspunsurilor la aceste intrebari depinde din nou de tine si e important ca ea sa existe la fiecare curs pe care il vei face in facultate.

O abordare intalnita in afara si care cred ca ar da roade si la noi este urmatoarea: profesorul sa ofere o bibliografie si la sfarsitul fiecarui curs sa mentioneze paginile care trebuiesc citite dintr-o anumita referinta pentru a pune studentul in tema cu subiectul predat la cursul urmator. In majoritatea cazurilor acest lucru nu se intampla la noi, asa ca la cursul urmator profesorul are tendinta de a trece rapid peste anumite lucruri pentru ca le-a tot predat de-a lungul anilor si i se par banale. Studentul pe de alta parte intalneste acele lucruri poate prima data si de cele mai multe ori se chinuie mai mult sa scrie repede de pe tabla dupa profesor, ajungand numai la intrebari de genul: "auzi, ce e ala pe tabla? e i sau j?"

Legat de ce trebuie sa inveti, te sfatuiesc sa incerci sa abordezi cat mai multe subiecte si tehnologii, pentru ca doar asa vei descoperi cu adevarat la ce fel de lucruri vrei sa lucrezi si pe ce ai vrea sa te axezi pe viitor. Dintre cursurile foarte importante, le-as mentiona pe cele de sisteme de operare, limbaje formale/compilatoare, programarea paralela si concurenta, programarea orientata pe obiect si arhitectura calculatoarelor. Acestea sunt primele care imi vin in minte, dar se poate sa fi scapat altele.

Nu spun ca vei scrie obligatoriu propriul tau compilator sau sistem de operare, ca iti vei construi propriul procesor, dar trecand prin aceste cursuri iti vei modela gandirea si modul de abordare a problemelor pe care le vei intalni pe viitor. Daca tehnologiile se tot schimba, conceptele care stau la baza lor raman aceleasi. Iar legat de limbaje, cum am spus-o si mai demult, consider ca limbajul este doar o unealta.

Nu-ti spun sa renunti la facultate. Dimpotriva, chiar te incurajez sa o urmezi. Chiar daca nu e evident la fiecare curs ce anume iti va folosi pentru viitor, nu renunta rapid cu un raspuns de genul: "asta e materie invechita", ci cauta mai intai sa te interesezi tu daca chiar asa e sau nu. Nu te baza pe profesor sa-ti spuna asta.

Nu vreau sa privesti aceste sfaturi ca pe un atac la adresa profesorilor. Am intalnit in facultate si profesori care au reusit sa-mi starneasca interesul pentru o anumita materie, dar numarul lor a fost mult prea mic daca stau sa privesc situatia per ansamblu. Asadar, nu pot sa-i privesc decat ca pe exceptii.

In concluzie, ia din facultate ce e bun (informarea despre existenta anumitor lucruri/concepte) si incearca sa ignori lucrurile mai putin bune (atitudinea multor profesori). Scopul final nu e sa-i faci profesorului pe plac, ci sa te dezvolti pe plan profesional.

Succes in alegerea viitorului!

Am observat de ceva timp o initiativa laudabila a celor de la Microsoft : actualizari lunare pentru documentatia din Windows Driver Kit. Pana acum ceva timp, trebuia sa astepti un nou release de DDK (sau WDK cum se numeste mai nou) pentru a putea obtine documentatia actualizata. Bineinteles ca actualizarile apareau prima oara pe MSDN online, dar prefer sa am acces rapid la documentatie chiar si cand Internet-ul nu merge cum trebuie.

Ultima actualizare e de acum cateva zile si aduce noutati legate de Windows Server 2008. Deja exista un nou WDK pentru Windows Server 2008, dar acesta este momentan doar in varianta beta si nu este recomandat pentru dezvoltarea driverelor folosite in productie.

Ca un exemplu de informatii noi, in ultima documentatie puteti gasi primele informatii legate de sistemul de fisiere tranzactional (TxF) din Vista si managerul de tranzactii din kernel (KTM - Kernel Transaction Manager).

Asadar, daca dezvoltati drivere sau alte aplicatii care au legatura cu programarea kernel-mode, puteti cauta lunar noi actualizari pentru documentatia din Windows Driver Kit aici.

Vara asta am fost intr-un internship de trei luni la Microsoft in Redmond, Washington. Ca intern la Microsoft, ai doua optiuni: SDE sau SDET.

SDE este prescurtarea pentru Software Design Engineer si este titlul job-ului ce implica lucrul intr-o echipa de produs. Practic, SDE-ul este cel care lucreaza la un produs si dezvolta facilitati noi sau le imbunatateste pe cele existente.

SDET inseamna Software Design Engineer in Test iar unii ii mai zic si tester. Multi au impresia ca asta implica dat click cu mouse-ul sa vezi ce merge si ce nu merge. De fapt, un SDET face ceea ce face si un SDE, si anume scrie software, insa destinatia acestuia este una interna. Aplicatiile dezvoltate de catre un SDET sunt folosite numai intern si in principal pentru procesele de testare a codului scris de SDE.

Pentru ca am vrut sa avem o imagine completa despre cum merg lucrurile si ce se face la Microsoft, am decis ca unul dintre noi va merge ca SDE, iar celalalt ca SDET. Astfel, Razvan a fost SDE in Storage Solutions Division iar eu am fost SDET in echipa File and Block Storage din cadrul Core Operating System Division.

Internii nu sunt lasati singuri, ci au indrumarea a doua persoane: un manager si un coach. Manager-ul este cel care tine evidenta progresului tau si se ocupa de evaluarile tale (una la mijlocul internship-ului si una la sfarsit), iar coach-ul este cel care iti face introducerea in echipa, te indruma si te ajuta atunci cand ai probleme cu proiectul sau cu acomodarea.

Internship-ul este de fapt un interviu de 12 saptamani, timp in care intern-ul face cunostinta cu Microsoft si invers. Intern-ul trebuie sa-si prezinte potentialul de success in eventualitatea angajarii la Microsoft, iar Microsoft trebuie sa se prezinte ca o companie atractiva pentru intern.

Daca cineva m-ar intreba: "Cum e la Microsoft?" nu as putea sa-i dau un raspuns general, pentru ca experienta fiecaruia depinde foarte mult de echipa in care lucreaza. Poti sa lucrezi intr-o echipa care sa-ti placa foarte mult, dar poti si sa lucrezi intr-o echipa in care sa-ti doresti sa ajungi cat mai repede acasa.

De cum am ajuns acolo si ne-am instalat, nu am avut timp sa ne simtim singuri sau departe de tara pentru ca Andrei si Alex au sarit repede sa ne arate mersul lucrurilor pe acolo. Primul lucru care mi-a placut cum am plecat de la aeroport si am intrat pe autostrada a fost traficul. Nimeni nu se grabea, nimeni nu te claxona.

Legat de experienta unui intern, nu stai degeaba. Sunt foarte multe evenimente. Unul dintre cele mai interesante a fost Intern Product Fair. Acolo am avut posibilitatea sa intram in contact cu multe tehnologii Microsoft si am putut testa pe viu Microsoft Surface. A urmat un dialog al lui Steve Ballmer cu internii in care unul dintre subiectele principale a fost: cand primim mancare gratis?

Pe langa altele, Microsoft este un loc foarte bun pentru invatare. In fiecare saptamana sunt multe prezentari sau "talk-uri" (cum le zice lumea pe acolo) de unde poti sa inveti o gramada de lucruri noi. Pe langa asta, sunt disponibile foarte multe training-uri interne (atat online cat si in persoana) . Partea proasta e ca, la majoritatea traniningurilor in persoana, locurile se ocupa cu 2-3 luni inainte, iar ca intern nu prea mai ai acces la niciun training pentru ca nu mai sunt locuri libere. Pe langa aceasta, ai nevoie de aprobarea manager-ului pentru a te inscrie la un training, iar asta nu se va intampla prea usor in cazul unui intern.

O alta experienta interesanta a reprezentat-o participarea la un eveniment din seria Behind the Code. Practic, am mers la studiourile Microsoft si am facut parte din audienta la inregistrarea unui episod. Nu va puteti imagina cata munca si cate duble se iau pentru a realiza un astfel de episod

Un alt lucru bun este MS Library, biblioteca interna (foarte bogata) a Microsoft de unde poti sa imprumuti carti, reviste sau diverse alte documente. Exista si posibilitatea de a comanda alte carti in cazul in care ceea ce cauti nu exista in biblioteca. In cazul acesta trebuie sa ai rabdare pentru ca poti astepta de la o saptamana pana la doua luni pana vei primi cartea dorita.

Au mai fost iesiri la Mount Rainier (e interesant sa te dai pe zapada vara) sau sailing pe Lake Washington plus un meci de baseball. La meciul respectiv am aflat pentru ce se duce lumea la baseball: socializare. Un fel de mici si bere americanesc. Lumea isi ia mancarea, se aseaza si incepe sa manance si sa bea. Din cand in cand mai arunca un ochi si pe teren, la cate o faza mai importanta.

In doua weekend-uri ne-am hotarat sa mergem in Los Angeles si in New York. Inainte de zborul spre Los Angeles, controlul a fost mai riguros decat la intrarea in SUA. Deoarece eram 5 prieteni care mergeam, ceva a parut suspect asa ca oamenii au vrut sa afle ceva mai mult despre bagajele noastre. In schimb, zborul spre New York a fost fara probleme, iar odata ajunsi acolo Vivi s-a dovedit a fi o gazda foarte primitoare (merci Vivi).

Revenind la Microsoft, era imposibil sa nu dai de cel putin un roman pe aproape fiecare etaj din fiecare cladire. Nu, nu este a doua limba vorbita la Microsoft asa cum se spunea intr-un spot care circula mai demult pe Internet, insa romanii sunt de ordinul sutelor. O vorba des intalnita este ca nu o sa reusesti sa-i strangi pe toti intr-o poza pentru ca nu incap Am avut posibilitatea sa cunoastem destui romani de acolo si sa-i intrebam despre experienta lor la Microsoft.

Per total, ce mai poti gasi la Microsoft? Oameni foarte valorosi si de la care poti invata foarte multe (daca reusesti sa prinzi cate un moment cand sunt liberi ) Vara aceasta am avut prilejul de a cunoaste oameni ca Mark Russinovich (unul dintre autorii site-ului Sysinternals si ai binecunoscutei carti Windows Internals) sau Rajeev Nagar (autorul singurei carti despre implementarea sistemelor de fisiere pe Windows: Windows NT File System Internals). Ca o paranteza, cartea respectiva a avut un succes fenomenal si a fost retiparita in 2006 deoarece se gasea foarte greu iar copiile existente ajunsesera la preturi de sute de dolari pe site-uri ca amazon sau e-bay.

Spre deosebire de alte veri, anul acesta am fost 11 (cat o echipa de fotbal) interni romani in Redmond (ordinea este alfabetica): Ioana Bratie, Omar Chouydary, Tibi Florea, Bogdan Grigore, Silviu Niculita, Victor Paraschiv, Mircea Pasoi, Cristi Pop, Vlad Riscutia si noi doi.

In final, pot spune ca experienta internship-ului depinde de fiecare intern. Pentru a beneficia cat mai mult de aceasta experienta este esential sa comunici si sa faci cunostinta cu oamenii care te pot ajuta sa-ti duci proiectul la bun sfarsit. Ai o foarte mare libertate in exprimarea ideilor, dar nu sunt incurajati "lupii singuratici" care iau totul pe cont propriu si nu discuta deciziile cu echipa.

Pentru exemplu, am luat o aplicatie simpla MFC ce simuleaza comportamentul descris mai sus. Codul relevant arata cam asa si va executa anumite instructiuni numai daca ruleaza pe Windows XP:

Aplicatia e compilata cu Visual Studio 2005 SP1. Masina virtuala contine un XP SP1 proaspat instalat. Daca incerc sa copiez EXE-ul intr-un director in masina virtuala (de exemplu: C:\Test ) si sa-l execut, nu va merge si-mi va da o eroare de genul: 

deoarece aplicatia este link-ata dinamic cu CRT-ul si cu MFC si are nevoie de DLL-urile respective. Pentru a putea rula aplicatia, voi copia librariile necesare in directorul aplicatiei. Din directorul: C:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86 de pe masina gazda, voi copia directoarele Microsoft.VC80.DebugCRT si  Microsoft.VC80.DebugMFC in directorul aplicatiei din masina virtuala (C:\Test). Am folosit DLL-urile din directorul Debug_NonRedist deoarece aplicatia mea este compilata in modul Debug.

Dupa ce am rulat aplicatia si am dat click pe butonul Ok, aceasta a crapat.

Dar cum sa-mi dau seama exact unde a crapat aplicatia? Sa instalez Visual Studio in masina virtuala? Nu am timpul necesar pentru asa ceva. Care e solutia? Remote debugging cu VMWare

Incepand cu versiunea 6, VMWare ofera optiunea de remote debugging din Visual Studio si Eclipse. Asa ca am deschis aplicatia mea in Visual Studio si apoi din meniul VMWare -> Options m-am apucat sa configurez aplicatia pentru remote debugging.

Prima data am setat ce se va executa in masina virtuala. Am indicat calea C:\Test\TestMFC.exe pentru ca acolo se va gasi executabilul in masina virtuala si Run Command as a guest path pentru a indica faptul ca este o comanda ce va rula in masina virtuala.

Apoi am setat calea masinii virtuale cu care voi lucra (in cazul meu un Windows XP SP1).

Daca fac niste modificari in aplicatie, va trebui sa copiez din nou fisierul executabil in masina virtuala. VMWare poate face acest lucru pentru mine, asa ca-I voi seta ca inainte de debug sa-mi copieze fisierul de pe masina gazda, pe masina virtuala.

La sfarsit, optional, pentru a face putina curatenie ii voi spune sa stearga fisierul de acolo dupa ce s-a terminat sesiunea de debugging.

Suntem aproape gata. Inainte de a face debugging mai trebuie sa ne asiguram ca pe masina virtuala avem acelasi cont si aceeasi parola ca si pe masina gazda. Altfel vom avea parte de urmatorul mesaj:

Daca incercam acum sa rulam aplicatia si sa facem debugging in masina virtuala, vom vedea urmatorul dialog:

Apasam No si pentru a rezolva problema mergem pe masina virtuala in Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> Security Options si setam la Network access: Sharing and security model for local accounts optiunea Classic "“ local users authentificate as themselves

Gata. Acum putem da drumul aplicatiei: Din meniul VMWare -> Start sau apasand F6. Astfel VMWare va porni Visual Studio Remote Debugging Monitor in masina virtuala.

Daca apasam pe butonul Ok, ne vom intoarce la Visual Studio si vom vedea eroarea si linia la care s-a produs. Asadar putem observa ca un pointer NULL era sursa erorii noastre atunci cand codul se executa pe Windows XP.

(click pe poza pentru a o mari)

In concluzie, am facut debugging la aplicatia mea pe un Windows XP SP1 si nu a fost nevoie sa instalez Visual Studio in masina virtuala. Eficient, nu?

O solutie rapida, dar nu 100% convenabila pentru unii este urmatoarea:

Deschideti proiectul scris in C cu Visual Studio. Pentru reprezentare am creat o aplicatie Win32 Console in care calculez suma numerelor de la 1 la 10.

Apoi i-am setat un breakpoint la intrarea in functie:

Dupa care am rulat aplicatia si codul s-a oprit in dreptul breakpoint-ului setat de mine. Apoi am ales din meniu : Debug-> Windows-> Disassembly pentru a vedea codul dezasamblat.

Astfel mi-a aparut codul in C langa cel in ASM.

Astfel cineva isi poate face rapid o idee despre cam cum ar arata codul unui program scris in C, daca l-ar scrie in ASM.

In opinia mea este o buna metoda de a face primii pasi in Assembler

UPDATE: Ovidiu are o completare despre cum sa instruiti compilatorul sa genereze automat fisierul .asm daca vreti sa vedeti tot codul (nu numai locul in care ajungeti cu executia in urma setarii unui breakpoint). Pentru a face acest lucru, mergeti in meniu Project -> Properties -> Configuration Properties -> C/C++-> Output Files si la Assembler Output alegeti "Assembly With Source Code (/FAs)"

In astfel de situatii,cand Windows-ul nu mai porneste, anumiti prieteni de-ai mei au o solutie simpla: format si reinstalare . Solutia respectiva nu e tocmai potrivita in cazul in care ai anumite aplicatii si/sau documente de care depinzi si pe care ai vrea sa le salvezi.

Pana acum, solutia era sa caut un CD de recovery care recunoaste NTFS sau alte solutii de acest gen (Hiren's Boot CD, BartPE etc.) Dar ce te faci cand ti-a crapat calculatorul la ora 11 noaptea si nu ai internet la indemana sau vreun prieten care sa-ti aduca repede un CD cu o solutie de recovery?

In astfel de situatii am observat ca o solutie buna si la indemana s-a dovedit a fi CD-ul de Vista Cum asa?

Pe un sistem cu Windows XP care nu mai boota din cauza unui software nou instalat, am pornit cu CD-ul de Vista si am selectat optiunea: Repair your computer

Dupa ce mi-a cautat instalarile de Windows si nu mi-a gasit nimic pentru ca spunea ca poate repara doar instalarile de Windows Vista, eu nu l-am crezut si am dat Next.

Apoi, din lista de optiuni, am deschis un Command Prompt.

In momentul acela mi-a aparut o fereastra linie de comanda cu un drive X: . Nu am stiut ce e cu el, asa ca am incercat sa aflu. As fi avut nevoie de anumite unelte dar nu aveam nimic instalat pe sistem in afara de Windows XP si software-ul respectiv. Cum sa fac rost de software? Aveam pe un stick USB mai multe utilitare pe care le folosesc. Dar oare puteam sa-l folosesc?

Am conectat stick-ul respectiv pe USB si apoi am luat drive-urile la rand sa vad daca-l pot accesa. C: era discul cu Windows, D: era CD-ROM-ul, si am putut accesa stick-ul respectiv prin drive-ul E: . Fericit ca-l pot accesa, am rulat Total Commander de pe el.

In momentul acesta puteam face orice doream cu fisierele mele: sa le copiez de pe o partitie pe alta, sa fac backup pe un stick USB sau pe alta partitie etc.

Dar eu unul eram curios ce e cu drive-ul X: . Asa ca am rulat (tot de pe stick-ul USB) un utilitar care sa ma ajute: WinOBJ

M-am uitat in directorul GLOBAL?? in dreptul lui X: si am gasit: \Device\Ramdisk... Apoi am rulat Process Explorer (tot de pe stick) pentru a vedea ce procese sunt in memorie.

Am observat un proces numit WinPE Shell si atunci am facut legatura.

In concluzie, CD-ul de Windows Vista creeaza un disc in memorie (ramdisk) si apoi ruleaza o varianta de Windows minimala numita Windows PE. Asta inseamna ca dupa ce ati pornit cu CD-ul de Windows Vista, il puteti scoate din unitate si introduce orice CD cu software care v-ar putea ajuta sa va reparati computerul, deoarece Windows-ul ruleaza de pe discul din memorie.

Per total, mi se pare o facilitate foarte importanta, daca stau numai sa ma gandesc la ce optiuni aveam cu CD-ul de Windows XP: un recovery console cu o interfata DOS in care puteam rula doar cateva comenzi.

Luni, 30 aprilie, in Politehnica Bucuresti, Rectorat, Amfiteatrul AN 010, ora 9:00

Nu stiu daca este doar parerea mea si a lui Razvan, dar se simte lipsa (cel putin in Bucuresti) a unor evenimente/prezentari tehnice. Bineinteles, exista evenimente in care se vorbeste despre lucruri flashy/"la moda", dar si pentru acestea intr-o maniera foarte diluata.

Sunt tehnnologiile de stocare de date si sistemele distribuite doua subiecte interesante pentru tine? Pentru noi cu siguranta sunt. Chiar daca stii sau nu ce este un sistem de fisiere, poti afla mai multe luni, 30 aprilie, de dimineata in Politehnica Bucuresti.

Adi Oltean este unul din cei carora le vei multumi atunci cand tocmai ti-ai sters accidental tema pentru facultate/colectia de muzica/documentul important, dar ai Vista instalat. De ce? Pentru ca Adi este Senior Software Design Engineer in cadrul echipei de dezvoltare Microsoft Windows si unul din creatorii facilitatii Previous Versions din Windows Vista. Daca nu ai timp sa vezi despre ce e vorba, iti spunem doar un cuvant: undelete. Daca ti-am trezit interesul, ne vedem la prezentare. Adi va vorbi despre:

• Fundamente in tehnologii de stocare de date;
• Inovatii si noi functionalitati in Windows Vista si Windows Server 2003 R2 legate de tehnologii de stocare de date (storage). Aplicatii: VSS, Previous Versions, FSRM;
• Noi directii in industrie, tehnologii noi in domeniul sistemelor de stocare de date;
• Aplicatii ale standardelor pentru servicii web (WS-Management, SMI-S) pentru administrarea sistemelor de stocare de date;
• Dezvoltarea de aplicatii pentru stocare de date.

In a doua parte a zilei, Florin Lazar va vorbi despre sisteme distribuite pe platforma .NET. Florin este Senior Program Manager in grupul de Tranzactii din divizia Microsoft Windows. Subiectele abordate vor fi:

• Fundamente in architecturi distribuite
• Evolutia tehnologiilor de sisteme distribuite Microsoft: COM/COM+/DCOM, .Net Remoting, ASP.NET;
• Elemente de programare distribuita bazate pe Windows Communication Foundation (WCF);
  • Principii de baza;
  • Modelul de obiecte;
  • Functii principale in WCF: Securitate, Reliable Messaging si Tranzactii;
  • Suport pentru standarde Web (WS-*);
• Directii de viitor (architecturi orientate pe servicii, modelare folosind workflow, memorie tranzactionala).

Nu uita sa te inregistrezi pentru participare pe http://reg.studentclub.ro/DetaliiEveniment.aspx?idEveniment=52

Daca esti din Iasi sau Cluj, nu e nevoie sa vii pana in Bucuresti. Adi si Florin vor veni la tine in oras pe 2 mai (Cluj-Napoca/Universitatea Babes-Bolyai) si 4 mai (Iasi/Universitatea Alexandru Ioan Cuza).

Ne vedem luni, 30 aprilie, in Politehnica Bucuresti, Rectorat, Amfiteatrul AN 010, ora 9:00.

Spune-le si prietenilor: Invitatie seminar

Recunosc ca si pentru mine Delphi a fost cel mai bun mod de a incepe programarea Win32 (nu stiam C pe atunci). Cand am renuntat la Pascal, am inceput sa ma uit in stanga si in dreapta dar C++ Builder deja o apucase pe un drum mort asa ca singura varianta a fost Visual C++ si (eventual) MFC pentru aplicatii Win32.

Post-ul este aici:

http://blogs.codegear.com/nickhodges/archive/2006/12/14/30532.aspx

Daca aveti rabdare sa cititi tot, cititi si comentariile. Sunt foarte interesante. Pentru cei care citesc mai multe pe acolo, am o intrebare:

Ce parere aveti voi in legatura cu acest lucru? Cati dintre voi mai sunt "native Win32" si cati sunt convinsi ca nu mai avem nevoie sa scriem cod nativ (pentru ca avem JIT) si ca totul trebuie sa mearga on top of .NET?

Pentru ca insistam sa ma uit la TV, am decis sa investighez problema . M-am gandit la ce tool m-ar putea ajuta mai mult in situatia de fata si m-am oprit la IDA pe care l-am luat de aici . Apoi am deschis fisierul cu pricina: C:\Program Files\WinFast\WFTVFM\WFTV.exe si l-am lasat pe IDA sa-l analizeze.

(click pe poza pentru a o mari)

Apoi am pornit debugger-ul din IDA. La scurt timp a ajuns la codul cu pricina si a dat un warning:

(click pe poza pentru a o mari)

Ducandu-ma la cod am observat ca dereferentia un pointer NULL. Dupa cum se vede, incerca sa acceseze membrul unei structuri care nu era alocata (registrul EDX avea valoarea zero si se incerca accesarea zonei de la adresa EDX+4)

(click pe poza pentru a o mari)

Mai departe am vrut sa aflu ce e cu structura respectiva. Am vazut ca eroarea are loc in apelul functiei fgetc, datorita parametrului stream care este NULL si a carui valoare era copiata in EDX. De aici am banuit ca se incearca citirea dintr-un fisier care nu a fost deschis. Pentru a confirma banuiala am apelat tot la IDA. M-am uitat pe stiva pentru a vedea cine este apelantul lui fgetc si pentru a vedea de unde vine argumentul eronat.

(click pe poza pentru a o mari)

Asa ca am dat dublu-click pe adresa apelantului (47B48Ah) pentru a vedea codul.

Am vrut sa vad apoi cum se ajunge cu executia aici asa ca am urmat calea indicata de a doua sageata albastra. Am ajuns asadar la locul unde s-a incercat deschiderea fisierului deci banuiala era confirmata. Se incerca deschiderea fisierului wincdl.cfg.

(click pe poza pentru a o mari)

Uitandu-ma pe codul dezasamblat am vazut ca nu se facea vreo verificare a rezultatului apelului catre fopen. In concluzie, in cazul in care deschiderea esueaza (fopen intoarce NULL), cazul nu este tratat si se merge mai departe cu un pointer NULL. Pentru a verifica aceasta, m-am uitat la rezultatul intors de fopen (stocat in registrul EAX). S-a dovedit a fi NULL, deci deschiderea fisierului a esuat.

M-am uitat in directorul aplicatiei si am observat ca fisierul lipsea asa ca am decis sa creez un fisier gol cu numele respectiv si sa rulez din nou aplicatia. Surpriza! Aplicatia a rulat fara probleme!

Am observat cu aceasta ocazie inca o data cat de importante sunt tratarea erorilor si testarea in ciclul de dezvoltare al unui produs software. Am anuntat compania producatoare si voi reveni cu un update in cazul in care primesc un raspuns.

In final, ii multumesc lui IDA pentru ca datorita acestui soft minunat acum ma pot uita la TV fara probleme

Cauza era o incompatibilitate de MTU intre calculatorul meu si gateway-ul prin care aveam access la Internet (calculatorul lui Bogdan). Se pare ca valoarea implicita folosita de Windows pentru MTU nu asigura un transfer bun al pachetelor prin interfata de retea cu Bogdan (Local Area Connection in cazul meu).

Pentru a rezolva problema am gasit un articol salvator care descrie solutia pentru Windows 2000/XP si Windows 98/Me. Articolul arata cum se poate gasi experimental o valoare MTU buna (care sa asigure comunicarea fara probleme intre calculatorul meu si gateway) si cum sa o setezi apoi ca parametru in Registry pentru interfata de retea cu probleme.

Recent am instalat Vista intr-o masina virtuala si m-am lovit de aceeasi problema. Am gasit la fel o valoare MTU buna, dar nu stiam cum sa o setez deoarece cheile din Registry ce tin de setarea respectiva s-au schimbat pe Vista. Pentru a rezolva si pe Vista am facut asa:

1. Am deschis un Command Prompt ca Administrator (deoarece schimbarea parametrilor interfetei de retea necesita niste privilegii de securitate pe care nu le aveam).

2. Am rulat comanda netsh interface ipv4 show subinterfaces pentru a vedea lista interfetelor de retea.

3. Pentru a seta valoarea MTU la valoarea gasita experimental (1460), am rulat comanda netsh interface ipv4 set subinterface "Local Area Connection" mtu=1460 store=persistent

(click pentru a mari imaginea)

Dupa ce am facut modificarea n-am mai avut probleme cu browsing-ul site-urilor respective.

Zilele acestea am dat peste un tool care ar putea sa-i readuca zambetul pe buze. E vorba despre un wizard pentru Visual Studio care poate genera rapid un driver simplu si il si poate compila. Este vorba despre DDKWizard ce se foloseste de scriptul DDKBUILD. Spre deosebire de alte wizard-uri similare, acesta foloseste compilatorul din DDK si nu acela din Visual C++.

Pe pagina autorului gasiti pentru descarcare un setup al lui DDKWizard ce nu contine insa DDKBUILD, asadar acesta trebuie descarcat separat. Va recomand sa cititi manualul PDF (nu are decat cateva pagini) pentru a intelege clar cum instalati DDKWizard.

Dupa instalare si configurare nu ramane decat sa intrati in Visual Studio si sa creati un nou Driver Project.

Parca e mai usor sa lucrezi cu mediul cu care esti obisnuit decat sa lucrezi in Notepad de exemplu si apoi sa intri in linie de comanda si sa dai build si sa astepti sa vezi la ce linii ai erori iar apoi sa te intorci in editorul de texte si sa rezolvi liniile respective.

Ce pare mai atractiv? Un build normal cu mediul de build din DDK...

sau sa lucrezi direct cu Visual Studio?

(click pe poze pentru a le mari)