Newsgroup: it.comp.programmare.win32
Titolo: [VxD] Qualche questione

Pongo alcune questioni circa i VxD per Win95-98-ME nella speranza che
qualcuno possa contribuire a chiarire almeno qualcuno dei grossi punti
interrogativi che non riesco a spiegarmi.
Lo scopo dichiarato e` la stesura di un documento generale (in parte gia`
allestito) sulla programmazione di device drivers, ad uso didattico per il
mio corso di Sistemi in una scuola superiore di Informatica.
Comincio con alcune domande di carattere vario; se il tono del dibattito lo
consentira` provero` anche ad approfondire.
A. Un aspetto stranamente trascurato dalla documentazione reperita (DDK,
Oney e internet in generale) e` la comunicazione asincrona VxD ->
Applicazione: come notificare all'applicazione che una operazione di I/O (su
un VxD) e` completata, evitando il polling dell'applicazione verso il VxD?
Una strada e` l'accoppiata Evento (lato applicazione) e
VWIN32_DIOCCompletionRoutine (lato VxD) e, dopo vari tentativi mi risulta
funzionare adeguatamente.
Ma altre due strade, piu` naturali, non riesco proprio a comprenderle:
1. VxD che invia un messaggio (un WM_qualcosa) all'applicazione. Eviterebbe
il thread addormentato su un evento e mi pare la via piu` naturale (il VxD
del mouse e della tastiera fanno cosi`, immagino). Si, lo so, esistono
_SHELL_PostMessage, _SHELL_BroadcastSystemMessage,... ma evidentemente non
riesco a implementarle con la supposta linearita`. Mi sfugge qualcosa,
evidentemente.
2. Funzioni OpenVxDHandle() / _VWIN32_*Event*(). Ma, a parte il mio
scarsissimo inglese, sfido anche solo a leggere l'help del DDK su questa
faccenda (chi chiama chi, chi passa cosa a chi ecc...).
B. Di tutt'altra specie: ogni applicazione Dos eseguita sotto windows (in
finestra) e` gestita dal VMM che 'vede' l'applicazione DOS in modalita`
'magica V86'. Ok. Quindi la schedula pure come ogni altro task. E' vero e
dimostrabile facilmente. Ma se la finestra viene espansa a tutto schermo il
VMM non schedula piu` gli altri task. Cosa e` successo? L'applicazione Dos
gira ancora in V86, SICURO. Ma COSA e` successo?
C. Un testo che ormai ha qualche anno (Schulman, W95 Dentro il sistema)
spiega come in V86 (quindi per applicazioni in finestra) VMM setti quasi
sempre il privilegio dell'I/O (IOPL) in modo che NON generi trappole; il
tutto per aumentare le prestazioni (e compromettere la stabilita`,
naturalmente). E' ancora cosi`? E questo e` uno dei motivi per cui in
NT/2000 le applicazioni DOS sono 'piu` lente'? E, mi verrebbe da dire, come
mai una applicazione Dos che opera massicciamente con l'I/O come Norton
Commander (quando si linka in seriale con un altro PC, p.e.) funziona a
meraviglia sotto NT WorkStation, mentre altre applicazioni analoghe vengono
ignobilmente rifiutate?
Per ora basta cosi`. L'argomento e` sufficientemente esoterico per meritare
scarsissima attenzione ANCHE dalle riviste specializzate che, peraltro, sono
estremamente attive quando si tratta di promuovere l'ennesimo ambiente di
sviluppo o linguaggio chissenefrega.
susanna

 chissenefrega.
il fatto è che Microsoft non vuole che tu, pinca pallina qualsiasi, 
scriva driver per Windows senza aver comprato i loro costosi libri, 
senza esserti certificata con i loro costosi corsi per professionisti, e 
senza che tu lavori per una ditta di hardware pronta ad apporre il 
marchio "Designed for Windows" su ogni pezzo prodotto. Sono proprio in 
pochi a sapere come funziona questa roba, e quelli che sanno devono 
tacere per contratto.
Come ultima risorsa ti mando qui:
http://www.sysinternals.com/
lavorano e programmano principalmente per Windows NT, ma hanno anche 
prodotto un paio di driver VxD molto interessanti (codice sorgente 
incluso, ovviamente)

 ha scritto nel messaggio
news:9bnv3f$4su...@synet.symbolic.it...
 > 1. VxD che invia un messaggio (un WM_qualcosa) all'applicazione.
 >Eviterebbe
 > il thread addormentato su un evento e mi pare la via piu` naturale (il VxD
 > del mouse e della tastiera fanno cosi`, immagino). Si, lo so, esistono
 > _SHELL_PostMessage, _SHELL_BroadcastSystemMessage,...
Se il messaggio è diretto ad un'unica App. Win32 si può benissimo 
utilizzare _SHELL_PostMessage, in quanto _SHELL_BroadcastSystemMessage è 
utilizzata per inviare lo stesso messaggio a una lista di app. o vxd.
Il prototipo (in asm) è il seguente:
VxDcall _SHELL_PostMessage, <hwnd, uMsg, wParam, 
lParam,  <OFFSET32pfnCallback>, dwRefData>
hwnd = Handle dell'applicazione a cui si vuole comunicare qualcosa.
I 16 bits superiori sono riservati e devono essere a zero.
uMsg = Nei 16-bits inferiori va inserito il messaggio da inviare (conviene 
definire un proprio messaggio ,'WM_USER+un valore',
comune per il vxd e l'app.).
I 16 bits superiori contengono informazioni di scheduling e conviene 
settarli al valore SPM_UM_AlwaysSchedule, altrimenti potrebbe capitare che 
la funz. di callback venga chiamata prima che il 
servizio(_SHELL_PostMessage) ritorni.
wParam,lParam = Sono i soliti parametri di un messaggio.
pfnCallback = L'indirizzo della procedura di callback chiamata quando la 
funzione PostMessage, chiamata dal servizio  _SHELL_PostMessage, ha 
inserito il messaggio nella coda della finestra desiderata; può essere 
nullo se non c'è bisogno di effettuare controlli sulla riuscita dell'invio 
del messaggio.
dwRefData = Indirizzo dei dati per la funzione di callback.
La funzione ritorna zero se qualcosa è andato storto.
La funz. di callback è chiamata solo quando il messaggio è stato postato 
nella coda della finestra.
Il prototipo è il seguente:
[pfnCallback], <dwRc, dwRefData>
dwRc = E' il valore ritornato dalla funz. PostMessage; se diverso da zero 
l'invio è riuscito.
dwRefData = E' il valore passato nella chiamata a _SHELL_PostMessage.
A questo punto il messaggio dovrà essere gestito nella WndProc della 
finestra dell'app. come un normalissimo altro messaggio.
Per quanto riguarda il secondo metodo è molto più complicato, e non c'è una 
spiegazione esauriente, per cui le consiglio di utilizzare il primo.
 > B. ... Ma se la finestra viene espansa a tutto schermo il
 > VMM non schedula piu` gli altri task. Cosa e` successo? L'applicazione Dos
 > gira ancora in V86, SICURO. Ma COSA e` successo?
 >
Riporto di seguito un pezzo di un articolo della MSDN:
Multitasking
The VMM uses a time-slice scheduler and execution priority to carry out 
pre-emptive multitasking for virtual machines.
................
The VMM relies on time-slice priorities and flags to determine how much CPU 
time it grants to the virtual machines.
Every virtual machine has a foreground and a background time-slice priority 
in addition to the virtual machine's execution priority. The virtual 
machine with the largest time-slice priority receives a greatest share of 
CPU time. The VMM uses the foreground priority to determine the amount of 
CPU time to grant a virtual machine if the virtual machine has the 
execution focus (is the foreground
virtual machine).
Otherwise, the VMM uses the background priority.
If a virtual machine is not the foreground virtual machine, it receives no 
time slices unless the CB_VM_Status field in its control block specifies 
the VMStat_Background or VMStat_High_Pri_Back values. If a virtual machine 
has the VMStat_Exclusive value, no
other virtual machine receives time slices while the exclusive virtual 
machine has the execution focus.
Evidentemente, quando un programma Dos viene eseguito a tutto schermo il 
campo CB_VM_Status del VMCB (VM control block) è settato a VMStat_Exclusive 
e questo comporta la sospensione da parte del VMM delle altre VM.
ayeye
-- 
Posted from [194.153.73.220] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ha scritto nel messaggio
news:9bnv3f$4su...@synet.symbolic.it...
<omissis>
:Se il messaggio è diretto ad un'unica App. Win32 si può benissimo
:utilizzare _SHELL_PostMessage, in quanto
:_SHELL_BroadcastSystemMessage è  utilizzata per inviare lo stesso messaggio
:a una lista di app. o vxd.
:Il prototipo (in asm) è il seguente:
<omissis>
Se ci mettevi il wrapper in C eri meglio del DDK.
Ma dove mi inceppavo io? Provero`.
<omissis>
:Riporto di seguito un pezzo di un articolo della MSDN:
:Multitasking
:The VMM uses a time-slice scheduler and execution priority to carry out
:pre-emptive multitasking for virtual machines.
:................
<omissis>
Vabbe`, 2 a 0.
Ma come hai trovato l'articolo, che chiave di ricerca hai usato?
Grazie mille.
susanna

:
:
: non essendo programmatore di driver ti dirò cosa so io che sto
: "dall'altra parte", di chi cioè i driver li usa...
:
<omissis>
:
: confermo. Gli oggetti Event sono la strada migliore. Al massimo evita
: l'interazione *diretta* driver-applicazione frapponendo una dll, che
: smisti gli eventi ed esponga all'applicazione una più familiare
: interfaccia a callback (come fanno ad esempio le funzioni WriteFileEx e
: ReadFileEx quando chiamate in modalità asincrona)
Si, e` sicuramente un'ottima soluzione.
: le VxD di I/O pare non usino i messaggi. Almeno non mi risulta.
: Dev'essere il thread a rimanere appeso all'oggetto finchè non scade il
: timeout o l'oggetto entra in stato segnalato. Oppure si fa creare un
: thread da una dll esterna che lo faccia al posto dell'applicazione, e
: notifichi l'applicazione con una semplice chiamata di funzione.
Non sono d'accordo.
Molta documentazione cita la tecnica di spedizione di messaggi VxD ->
Win32App.
: > B. Di tutt'altra specie: ogni applicazione Dos eseguita sotto
: > windows (in finestra) e` gestita dal VMM che 'vede' l'applicazione
: > DOS in modalita` 'magica V86'. Ok. Quindi la schedula pure come
: > ogni altro task. E' vero e dimostrabile facilmente.
: se è NT Workstation escludo GO32V2, DPMI, DOS4GW, e tutte le varie altre
: estensioni a 32 bit di DOS. L'unica risposta che so darti, ahimè, è che
: la Symantec è storica partner Microsoft... e lupo non mangia lupo...
Potrebbe essere, in effetti, un particolare stile di programmazione 'Dos'
utilizzato negli applicativi Symantec.
<omissis>
: il fatto è che Microsoft non vuole che tu, pinca pallina qualsiasi,
: scriva driver per Windows senza aver comprato i loro costosi libri,
: senza esserti certificata con i loro costosi corsi per professionisti, e
: senza che tu lavori per una ditta di hardware pronta ad apporre il
: marchio "Designed for Windows" su ogni pezzo prodotto. Sono proprio in
: pochi a sapere come funziona questa roba, e quelli che sanno devono
: tacere per contratto.
Credo ci sia del vero in tutto cio`.
Soprattutto 'pinca pallina' 8-)
Grazie mille.
susanna

 ha scritto nel messaggio
news:9bnv3f$4su...@synet.symbolic.it...
<omissis>
Ci ho messo un po', ma poi ce l'ho fatta: il mio primo VxD che invia un bel
WM_USER+1 ad una applicazione Win32.
Mancava il wrapper, ma guardandone uno in <shell.h> l'ho costruito ex-novo:
DWORD VXDINLINE
SHELL_PostMessageSusannaPincaPallina(DWORD hwnd, DWORD uMsg, DWORD wparam,
DWORD lparam, PDWORD pfnCallback, DWORD dwRefData)
{
    _asm    push    dwRefData
    _asm    push    pfnCallback
    _asm    push    lparam
    _asm    push    wparam
    _asm    push    uMsg
    _asm    push    hwnd
    Touch_Register(eax)
    Touch_Register(ecx)
    Touch_Register(edx)
    VxDCall(_SHELL_PostMessage);
    _asm    add esp, 6*4
}
Scusa quest'appendice, ma mi dovevo togliere la soddisfazione: ci ho messo
tre (3) ore!
A te il mio tutorial sui VxD _IN ITALIANO_ come premio (tra una quindicina
di giorni, pero`).
ciao
susanna

Ok, aspetto il tuo tutorial.
Comunque se ne volevi qualcuno in italiano, molto semplici e in asm, te li 
potevo spedire io, li avevo scaricati un pò di tempo fa da un sito che oggi 
non c'è più.
Per quanto riguarda dove ho trovato l'articolo:
ho cercato soto 'DDK Documentattion->Windows 95 Device Driver Kit->Chapter 
2 ...->Multitasking'.


 ha scritto nel messaggio
news:4.3.2.7.0.200104...@mail.nopay.it...
:Comunque se ne volevi qualcuno in italiano, molto semplici e in asm, te li
:potevo spedire io, li avevo scaricati un pň di tempo fa da un sito che oggi
:non c'č piů.
Manda pure. L'indirizzo, senza l'antispam, e` valido.
ciao
susanna

non c'č piů.
se ti riferisci a sito di Rinzer0 esite ancora
(
http://ringzer0.goldrake.com/
) anche se ormai non lo aggiorniamo piu'
da molto, e sinceramente non so nemmeno se mai verra' aggiornato di
nuovo.. cmq sia i tutorial tradotti erano quelli di Iczelion,  che
come da te anticipato sono semplici e di grande chiarezza per chi si
avvicina ai VxD, DDK, ecc.. 
Ad ogni modo considerato che nel frattempo ne sono stati redatti altri
il mio consiglio per Susanna e' di fare una capatina al homepage di
Icz 
http://spiff.tripnet.se/~iczelion/
Saluti,
 Walker Boh

ignobilmente rifiutate?
restando su codice legacy, insomma senza hack-o-rama, mi vengono in
mente due possibilita': 
1) drastica : non e' DOS ma c'e' solo un stub loader che spawna 
un'applicazione console nel caso giri under NT
2) meno drastica : vengono utilizzati dei VDDs 
ovviamente sono solo supposizioni.. cmq se trovo un po' di
tempo/voglia, e riesco a riesumare una vecchia di NC gli daro'
un'occhiata..
Saluti,
    Walker Boh

_Shell_Call_Appy_Time,le nested executions, o
Rotfl... diamo il premio "oscurita'" a Walker Boh, vi prego...
Forse un giorno postera' un messaggio scritto in un linguaggio
decente... ;)

 wrote:
<omissis>
: direi che e' l'intero argomento dell'interazione KM(VxD) <-> UM(App)
: ad essere lacunoso nel DDK..
D'accordo.
<omissis>
: della Kazzah che e' molto + preciso e dettagliato per quel che
: concerne i VxD rispetto all'Oney che e' incentrato sul modello WDM.
Ok (anche se mi riferivo all'Oney di 'Systems programming for Windows95').
Sarebbe (il libro della Kazzah)?
<omissis>
: scusa ma non condivido la tua definizione di + naturale realtivamente
: ad questo scenario di I/O asincrono APP <-> VXD (che mi par di capire
: non prevede una gestione interrupt driven) :
: il requester thread invoca DeviceIoControl; il VxD serializza
: la richiesta ad un suo worker thread; il requester a questo punto
: puo' proseguire l'elaborazione ma e' altamente probabile che
: a breve debba cmq sospendersi x attendere il completamento
: dell'I/O richiesto e necessario all'elaborazione,
..., e questo sarebbe 'piu` naturale'?
In un sistema operativo che offre alle applicazioni un massiccio punto di
ingresso sottoforma di messaggi, il minimo che ci si puo` aspettare e` che
lo stesso sistema operativo (e un VxD E' sistema operativo) avvisi le
applicazioni tramite un messaggio. Questo intendo per 'naturale'.
Mi sembra invece piu` 'artificioso', nel nostro contesto, obbligare una
applicazione a creare un thread sospeso su un evento; in fondo un punto di
ingresso asincrono ce l'ho gia`: la coda dei messaggi.
<omissis>
: >_SHELL_PostMessage, _SHELL_BroadcastSystemMessage,... ma evidentemente
non
: >riesco a implementarle con la supposta linearita`. Mi sfugge qualcosa,
: >evidentemente.
: non mi e' chiaro cosa tu voglia significare con "supposta linearita'",
: _SHELL_Post* mi paiono sufficientemente lineari da utilizzare,
: che tipo di problemi o comportamenti anomali ti si prensentano ?
Ehm, in effetti, dato che scrivo i VxD in C, mi mancava solo la routine
'wrapper' giusta (cioe` quella che costruisce l'involucro per la chiamata in
assembler) .
Una volta assemblata, il servizio funziona a meraviglia.
: >2. Funzioni OpenVxDHandle() / _VWIN32_*Event*(). Ma, a parte il mio
: >scarsissimo inglese, sfido anche solo a leggere l'help del DDK su questa
: >faccenda (chi chiama chi, chi passa cosa a chi ecc...).
: OpenVxDHandle non fa altro che "rimappare" in KM l'handle x il
: dispatch object creato a UM (essendo questi win32 kobjs e' abbastanza
: naturale che il loro domain attraversi i due rings): passando questo
: handle a r0 via DeviceIOControl lo si puo' utilizzare con le varie
<omissis>
Ok, vedro` di riprovare (se riusciro` a tradurre *anche* i tuoi suggerimenti
8-))
<omissis>
: >dimostrabile facilmente. Ma se la finestra viene espansa a tutto schermo
il
: >VMM non schedula piu` gli altri task. Cosa e` successo? L'applicazione
Dos
: >gira ancora in V86, SICURO. Ma COSA e` successo?
<omissis>
: non e' che il primary scheduler non scheduli + gli altri VM/threads
: (btw VMStat_Exclusive _non_ impedisce lo scheduling della system VM)
: il problema risiede nel fatto che la VM beneficia della priority di
: foreground + un boost x il focus, e contemporaneamente il suo thread
: e' visto come high priority dal secondary scheduler che e' ignaro
: del boost gia' applicato dal primary
Ma allora dovrebbe succedere una cosa analoga con applicazioni win32 quando
sono espanse a tutto schermo: "...priority di foreground + un boost x il
focus".
Ma non e` cosi`.
Propendo per la spiegazione di ayeye, sempre che tu non abbia altri
elementi.
<omissis>
: attenzione a non dimenticare che in modo V86 le istruzioni INx, OUTx
: _non_ sono IOPL sensitive e restando di conseguenza "trasparenti"
:  rispetto a EFLAGS.IOPL=0:
: cio' che determina eventuali traps nell'accesso I/O space e' la bitmap
: (quello che la doc chia local I/O trapping) che VMM mantiene x ogni VM
: ed utilizza per aggiornare la TSS.IOPM:
: nel caso di una VDM il c.d. local I/O tracing e' "sostanzialmente"
: disabilitato x tutto cio' che non e' di interesse dei VxD di sistema..
In effetti era quello che sostenevo: Windows assegna (quasi) sempre IOPL=3
alle applicazioni eseguite in V86 mode, pertanto tutte le eventuali
istruzioni privilegiate contenute in codice 'reale' non sono intercettate
dal VMM (perche` anche il codice eseguito in V86 mode e` a ring3, cioe` gli
e` assegnato un CPL=3).
<omissis>
: 1) drastica : non e' DOS ma c'e' solo un stub loader che spawna
: un'applicazione console nel caso giri under NT
Possibile.
: 2) meno drastica : vengono utilizzati dei VDDs
Che sarebbero (i VDDs)?
: Saluti,
:
:     Walker Boh
Grazie molte.
Se ti e` possibile, dai un'occhiata anche al prossimo messaggio su questo
tema.
ciao
susanna

Che sarebbero (i VDDs)?
Virtual Dos Drivers: sostanzialmente sono delle helper dll che girano
a ring3 e che NTVDM utilizza come interfaccia fra KM e VDM x
virtualizzare la gestione dell'hardware, cmq se vuoi maggiori dettagli
sono blandamente ducumentate nel DDK di NT/2K,ecc.
Saluti,
 Walker Boh

 wrote:
:
: >Ok (anche se mi riferivo all'Oney di 'Systems programming for
Windows95').
: >Sarebbe (il libro della Kazzah)?
: "Writing windows VXDs and device drivers" , K. Hazzah . Miller Freeman
: 1996 (sorry x il typo che ha generato la "sintesi" Kazzah =P )
Grazie.
<omissis>
: Inoltre come regola generale: i window messages riguardano il
: sottosistema di windowing che i criteri di separazione che governano
: i S.O. moderni vogliono giustamente disgiunto ed ignoto al kernel
: (che sia monolitico, micro, nano,ecc..)
Questo mi sembra giusto.
Ma qualche eccezione rimane: i messaggi WM_MOUSE*, es.
<omissis>
: no xche' come del resto e' chiarito nel DDK (si fa per dire.. l'unica
: cosache chiarisce in win9x davvero sono eventuali books sugli
: internals o un KM debugger) VMStat_Exclusive non inibisce lo
: scheduling della system VM ma solamente delle altre VM..
: quello che influenza lo scheduling e' come detto un boost implicito
: assegnato dal primary scheduler, boost di cui e' all'oscuro il
: secondary scheduler, che quindi non gestisce correttamente situazioni
: di starvation,ecc  situazioni che si acuiscono quando la VDM effettua
: pesanti operazioni di I/O o causa molte transizioni in V86<->PM
: (via INT,ecc.)
Provero` ad indagare.
: Saluti,
:  Walker Boh
Grazie.
susanna