Forum libero

...che quel belliffimo systema che la MS chiama Finestre, dopo tutti questi anni, ha dei problemi se una sua applicazione gira col direction flag impostato? A quanto pare ci sono delle chiamate asincrone che non si possono controllare, e che se beccano il thread che stava eseguendo in quel momento con DF=1 in EFLAGS, fanno casino in memoria. Ho verificato divertenti conseguenze mentre allocavo una console (AllocConsole), tipo che il programma funzionava se aveva un certo nome ma non un altro nome (l'eseguibile, proprio), e ovviamente non per via della lunghezza dei nomi, no... proprio la sequenza di lettere.

E` sempre stato un sistema assurdo. Mi ero documentato prima della scelta di usare DF come call state, ma msdn diceva che era importante solo per le funzioni del "C run-time" di Visual Studio. Sicche` m'ero detto vabbe', questa e` un'altra cosa. Invece e` proprio il sistema fallato, non sopporta bene STD mentre sta animando delle cazzate sullo schermo tipo una finestrella di testo.

Il problema e` che ora non posso usare DF per il call state. O rinuncio al call state, che pero` mi piace come idea, oppure lo sposto da un'altra parte conveniente. Vi viene in mente nulla di thread-safe, considerato che tutti i registri sono occupati e che lo stato di quel flag dev'essere indipendente dal call stack?

Intanto provo a spostarlo nel bit di segno di ESI, che mappa il registro E. Ma siccome "E" viene usato per mappare i call frame e quindi e` sempre un puntatore n-flat, i puntatori n-flat sono a 30 bit dove ce ne sono 32 perche` vengono multiplicati incondizionatamente per 4 dall'address generator, quindi i due bit piu` alti sono in teoria disponibili. Diventa casinoso pero` impostare e dismettere i call frame stando attenti a non modificare il bit di segno di ESI. La questione e` contorta.