Newsgroup: it.comp.lang.c++
Titolo: Windows 2000

Le routines che scrivono o leggono dalla porta seriale o parallela, generano
un errore se si e' in Windows 2000.
Qualcuno ha trovato lo stesso problema ?
Enzo


No visto che non esiste nessun problema.
Ciao
Gaetano.
PS. Spostati su it.comp.programmare e continuiamo li.
-- 
Posted from 
dell-01.mm.eutelsat.org
 [194.214.173.17] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 wrote in message
news:TkdL7.7944$BA4.2...@news1.tin.it...

1) sei OT
2) non specifichi neppure di che routine stai parlando
3) non ci ho mai provato
4) se le routine le hai scritte tu, il problema č tuo. Sotto Win32 per
scrivere/leggere con la seriale si usano le stesse API che si usano per
scrivere e leggere i file e NON si puņ scrivere/leggere sulla parallela
se non chiamando direttamente il driver della stessa (o passando dalle
API di stampa). Pertanto non č chiaro di che parli!
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

Il problema e' semplice.
Basta scrivere,  ad esempio:
status=_inp(ser_Status) e' si ha, solo in Windows 2000, un errore.
dove ser_Status e' un'indirizzo della porta seriale  (ad es. 0x3FD), secondo
o standard in vigore da sempre.
Lo stesso se si accede alla porta parallela; e' un problema per chi ha
programmi scritti in assembler o C, sfruttando direttamente l'hardware del
PC.

 wrote in message
news:3qCL7.12164$4M2.3...@news2.tin.it...

Questo non vale solo per Win2000 come dici tu. Vale per tutti i SO seri.
Quindi dovrebbe valere per Linux, WinNT, Win2000, WinXP etc. etc. Non
vale per quei sistemi operativi in cui ad un programma applicativo è
permesso "rompere le palle" ad altri programmi applicativi e al SO
stesso mandando la macchina in palla completamente senza che il SO
glielo possa impedire. In particolare DOS, Win3.x e Win95/98/Me (e in
teoria già Win95/98/Me non ti permettono di fare tutto, ma solo alcune
cose).
Ricordati come è strutturato un OS serio:
1) un programma accede al sistema tramite le API del SO. Alcune di
queste API astraggono operazioni comuni (per esempio la stampa). Altre
danno accesso ai device driver (per esempio quello che gestisce la porta
parallela). IN NESSUN CASO il programma accede direttamente ne all'HW ne
al device driver, ma solo tramite API.
2) un device è gestito da un (o più) device drivers. Un device driver
riceve i comandi dal sistema (che a sua volta eventualmente li riceve
dal programma tramite le API). Il device drivere decide e gestisce la
logica del device e traduce i comandi in sequenze di accesso all'HW ma
NON FA direttamente accesso all'HW. L'accesso all'HW lo fa solo tramite
un device driver di livello più basso oppure tramite il SO sfruttando le
API relative all'HAL (Hardware Abstraction Layer) che sono accedibili
solo ai device drivers e non agli applicativi.
3) l'accesso vero e proprio all'HW è riservato ad una piccola parte del
SO che si chiama HAL e che è l'unico codice di tutto il sistema che puù
accedere direttamente all'HW. Questo è (teoricamente) l'unico codice che
viene eseguito in una modalità a privilegio assoluto di accesso. Tutto
il resto del codice (teoricamente compreso il SO e i Device Drivers)
vengono eseguiti in una modalità di privilegio ristretto in cui la CPU
impedisce l'accesso all'IO HW, alle parti di memoria mppate HW, alla
memoria "speciale" usata dalla CPU (interrupt jump table, per esempio),
ai registri di sistema della CPU stessa e alle istruzioni della CPU che
riguardano queste operazioni (incluso ovviamente il cambio del livello
di privilegio).
La realtà è leggermente diversa dalla teoria e in generale su NT e
famiglia (e credo anche su Linux) i device driver possono di fatto
accedere all'HW direttamente. Salvo che se non lo fanno nel modo
previsto dal sistema (per NT tramite HAL) hai il 99,999% di probabilità
che il sistema si impalli entro i primi due minuti dall'accensione (e
spesso se il DD è scritto male si impalla persino prima di poter
disattivare quel DD, motivo per cui chi sviluppa DD lavora sempre con
due o più macchine a disposizione!).
Quindi il c0omportamento da te rilevato è corretto. Previsto.
Conosciuto. E credo persino sia una FAQ (se non lo è dovrebbe esserlo).


Ti ringrazio della spiegazione, ma le operazioni di I/O verso semplicemente
la porta seriale o parallela non possono mandare in palla alcun sistema
operativo. Queste sono gravi limitazioni introdotte forse ad arte da Windows
2000 e non esistenti nelle versioni precedenti.
Fino ad ora i miei applicativi hanno sempre funzionato bene (da anni), anche
in un'ambiente gracile come Windows.
Usare le API non e' mai stato obbligatorio. Il fatto che programmi in DOS
non funzionino in W2000 e' grave.
Saluti, Enzo.

 non funzionino in W2000 e' grave.
Guarda che lo sanno tutti che i programmi DOS non girano sotto WinNT/2000.
La struttura dei due S.O. è troppo diversa, al contrario di W95 e W98, ed è
possibile solo una blanda emulazione.
Termino quì perché la discussione è OT.
Ciao.

 non funzionino in W2000 e' grave.
Usare le API è sempre stato obbligatorio. Il non usarle era una
concessione fatta a prorammi scritti prima del 1995 nell'attesa che
fossero riscritti (MS disse di riscriverli entro 1997, poi diede tempo
ulteriore fino al 1999).
Il fatto che programmi DOS non funzionino sotto NT è risaputo da 10
anni. Il fatto che i programmi DOS non sarebbero più stati supportati è
stato annnunciato da oltre 8 anni. In teoria i programmi DOS non
avrebbero dovuto girare più su nessun OS MS fin dal 1997. Siamo nel 2001
e non puoi lamentarti del tempo che ti hanno dato per riscriverli.
