Ecco Microsoft Windows 2003 Server

x CFranco: scusami se non ti rispondo adesso, ma sono stanotte non ho dormito molto e tra poco mi devo rimettere a lavorare: ne approfitto per riposare un po'.
Se ho tempo stasera avrò cura di farlo. Nel frattempo hai dell'altro materiale su cui riflettere...

Bè sì non intendevo dire che sono spariti, ma che una volta inizializzati vengono toccati il meno possibile. Ad es. sotto linux (ma credo anche sotto win32), CS & co sono gli stessi per tutti i programmi (e il kernel giocherella con le tabelle di pagine per gestire la memoria virtuale) (*)
Nel 286, invece, eravamo costretti a usarli in continuazione. Adesso tutte le combinazioni (2^12 mi sembra, tolti i 4 bit riservati) che offrono sono sovrabbondanti rispetto a quello che servono (e in effetti ormai hanno praticamente perso il loro scopo principale).



(*) eccezione fanno - guarda un pò - quei rari programmi che devono eseguire codice a 16 bit, in modalità protetta o in emulazione vm86. Ovvero quelli che in teoria dovrebbero poter girare ancora sul "mostro"

Non sto dicendo che avrebbe dovuto rinunciare ma imitare. Non hanno saputo farlo. Punto. Avevano da fare altro come lo stack TPC/IP e IE e Outlook.

Ti stai confondendo col 286: questo processore, una volta passato in modalità protetta, non aveva modo di tornare in quella reale se non utilizzando un trucchetto (caricando l'indirizzo di ritorno in una particolare locazione del BIOS e richiedendo un'operazione di shutdown al controller CMOS, alla porta I/O $70).
Col 386 le cose sono cambiante, ed è possibile passare dalla modalità reale a quella protetta e viceversa quante volte si vuole.
Comunque trovi tutto nei manuali di programmazione di sistema della Intel...

Più precisamente diciamo che questa modalità viene da loro utilizzata per far girare le applicazioni DOS...

Non è così. Entrambi i s.o., come dicevo, utilizzano il virtual mode per far girare le applicazioni DOS, ma il real mode non esiste più: non ci sono passaggi dall'una all'altra modalità, e d'altra parte non sarebbe possibile far coesistere le applicazioni a 32 bit senza girare esclusivamente in modalità protetta.
Le scorie di cui parli sono porzioni di memoria che vengono condivise da TUTTE le applicazioni di Windows, siano esse a 32 bit che a 16 bit (virtual mode DOS box), ed è questo che crea problemi (assieme al fatto che è possibile accedere alle istruzioni I/O e ad alcune privilegiate, come CLI e STI ad esempio).

Vedi sopra: il s.o. gira sempre e comunque in modalità protetta (a 32 bit), e la vulnerabilità è data da ciò che è ho già scritto.

Più che altro IE è composto da una miriade di DLL e OCX, per cui puoi disinstallare l'eseguibile (di pochi KB), ma tutte le sue funzionalità rimangono presenti nel sistema, che ne fa pesante uso.

Diciamo che non hanno voluto supportare nessun altro s.o. oltre al loro, per cui non hanno scritto un boot loader generico che permetta di poter selezionare qualunque s.o.. D'altra parte anche con Linux, se non installi LILO, non puoi far girare nessun altro s.o...
Comunque se si usano programmi di terze parti (come Boot Magic, ad esempio), non vedo quale sia il problema: MS può incazzarsi quanto vuole ma non ci può fare niente. Si sa com'è finita la causa con Dell?

D'altra parte non tutti possono diventare esperti informatici: il mondo ha bisogno anche di muratori, dottori, macellai, ecc.

Lo so.

Non ci possiamo fare: entrambe le società hanno come scopo principale fare soldi, come ho già detto, per cui ognuno tira acqua al proprio mulino. OS/2 veniva venduto, esattamente come Windows, per cui MS ha preferito non dividere la fetta della torta con IBM.
Per il declino di OS/2 MS ha certamente le sue colpe, non v'è dubbio, ma è IBM che ha continuato il suo sviluppo e che alla fine non è riuscito a farlo decollare.

Allora, hai ragione, ma premetto ancora una volta che stavamo parlando di implementazione di un s.o., per cui la comparazione 286 vs 386 era estremamente importante per i motivi che ho già esposto e per far capire come funziona internamente un s.o. che supporta contemporaneamente applicazioni a 16 e 32 bit, che girano "solidali" in un unico ambiente.

Le combinazione sono 2^13 (i bit riservati sono 3: uno per selezionare il tipo di tabella dei selettori fra quella globale e quella locale, gli altri due per il livello di privilegio del selettore).
E' vero che ormai non si usano perché il sistema offre un ambiente "omogeneo", dove si fa uso della paginazione della memoria per gestire, appunto, gli accessi e l'esecuzione del codice, ma nessuno c'impedisce di realizzare un s.o. che utilizzi contemporaneamente segmentazione e paginazione anche a livello applicativo: è una soluzione più complicata da gestire (avremmo puntatori a 48 bit), ma che da un certo punto di vista offre anche molti vantaggi (es: la realizzazione di array dinamici diventa banale da gestire e con un impatto praticamente nullo a livello computazionale, in quanto non ci sarebbero più "spostamenti" di memoria a seconda dell'espansione della contrazione dell'array).
Comunque, questo è un discorso che lascia il tempo che trova: ormai funziona tutto in maniera più semplice (per un programmatore ). A me serviva solo per far capire il concetto di cui sopra.

Beh, se mi consenti OS/2 non era graficamente appagante come lo era Windows.
Hanno deciso strade diverse e i risultati li conosciamo tutti. Che ci possiamo fare? Niente, come utenti. Altrimenti avremmo dovuto comprare abbastanza azioni MS da permetterci di poter avanzare le nostre proposte.
Comunque, alla fine abbiamo XP che mi sembra non essere un s.o. tanto malvagio...

Sì e la TLB ringrazia sentitamente

Stavo parlando del 286 infatti , e del perché si sia rinunciato ad usare la modalità protetta dello stesso .


Windows 3.x funziona in modalità reale ( si può far girare anche su un 8088 ) , Windows 95 ( e anche 98 ) contiene ancora parte di quel codice , che gira nella modalità reale virtuale del 386 , questa parte del codice contiene , ad esempio , la gestione delle porte parallela e seriale .


Parte del kernel di W95/98 é derivato direttamente da Win 3 ed é scritto per girare su un 8088 .


Quindi il tutto non é modulare .


C' é una bella differenza , il Lilo ( ma c' é anche Grub ) lo puoi installare sul MBR , oppure sul primo settore della partizione per usare un boot loader di terze parti ( volendo si può usare anche quello di M$ ) , qui si tratta di cancellare *senza chiedere e senza avvisare* un settore di disco dove potrebbe essere installato un programma , ci sono gli estremi per chiedere un risarcimento per il danneggiamento .


Dell ha calato le braghe , i PC uscivano con Windows e BeOs , ma per avviare quest' ultimo bisognava usare un floppy


Quello che ha fatto M$ non rientra nella categoria della normale concorrenza tra società , piuttosto direi "sabotaggio" , "mancato rispetto del contratto" e "concorrenza sleale" , come d' altronde certificato anche dalla commissione antitrust americana .

La TLB deve già fare i conti con i segmenti (vengono comunque usati, anche se precaricati), per cui cambia poco...

P.S. Anche gli x86-64, in Long mode, non è che facciano del tutto a meno della segmentazione (anche se il modello d'indirizzamento della memoria per le applicazioni è solo ed esclusivamente paginato): FS e GS sono ancora riservati per l'indirizzamento della memoria del s.o. (NT & co. sicuramente, non so se anche per Linux, ecc. è lo stesso) tramite i classici prefissi di segmento...

Come non detto, allora...

Sì, lo so.

Mah, che dire: mi risulta un po' difficile. Immagina cosa dovrebbe accadere quando arriva un interrupt del controller USART o della parallela: viene richiamato un interrupt in modalità protetta a 32 bit tramite la IDT (perché comunque Win9x opera sempre in modalità protetta a livello di kernel), poi si dovrebbe chiamare un task gate virtual 8086 per fargli fare un po' di lavoro (e qui immagina il tempo per il task switch e per il passaggio delle informazioni), per poi tornare nuovamente alla modalità protetta (e ancora qui ci sarebbe un altro task switch e passaggio delle informazioni).
Francamente si perde meno tempo ad effettuare il porting di quelle quattro righe di codice che utilizzare un meccanismo contorto come questo. Per lo meno io, ai tempi del DOS, ho perso poco tempo per implementare tutta la gestione delle seriali e della parallela...
Comunque, se sei sicuro che funziona così, ne prendo atto (a parte che non avrei alcuna voglia di andare a disassemblarmi il codice di Windows per andare a controllare... )

Il Kernel gira sempre in modalità protetta, altrimenti la gestione dei task, degli interrupt e della memoria sarebbe praticamente impossibile avendo a che fare con applicazioni a 32 bit.
Al più, se si verifica quanto hai scritto sotto, si potrebbe appoggiare a del codice vecchio.

In ogni caso, ritornando un po' indietro col discorso, non sarebbe certamente questo funzionamento a minare alla base la stabilità del s.o...

Al contrario, proprio per questo motivo è estremamente modulare. Le DLL e gli OCX in cui è suddiviso IE svolgono ognuno dei compiti ben precisi e le loro funzionalità possono essere integrate in qualunque applicazione. Ad esempio la classe THTMLBrowser della VCL di Borland incapsula direttamente l'oggetto per la visualizzazione di pagine HTML dentro un controllo visivo...

Sì, questo l'avevo capito. C'è da considerare anche l'EULA per ricercare eventuali responsabilità.
Tra l'altro quando installi Windows 9x, se è presente anche un s.o. di classe NT lo falcia via lo stesso...

Avrà preferito tutelare il vantaggioso contratto OEM con MS...

Anche per OS/2 ha avuto problemi? Questa non la sapevo... Avrà pagato almeno?