Ha suscitato molto interesse il recente articolo di Alessio Di Domizio, che ha rispolverato un’autentica chicca sconosciuta ai più (a me sicuramente, ma anche a molti altri, a giudicare dai commenti), l’interfaccia “amichevole” BOB di Microsoft.
Trattandosi di un’applicazione realizzata per Windows 3.1 e Windows ’95, non dovrebbe essere difficile farla girare nei nostri PC, pur trattandosi di “vecchiume”. Sappiamo, infatti, che la soluzione che Microsoft ha adottato quando si parla di far girare codice “datato” (o legacy, come si dice in gergo) sono i subsystem (sottosistemi), di cui abbiamo ampiamente parlato in quest’articolo .
Nessun problema, quindi, anche facendo girare l’applicazione in versione WIN16? Purtroppo i subsystem non sono perfetti e non risolvono al 100% i problemi di incompatibilità, per cui alcune vecchie applicazioni possono non girare, o comunque non girare correttamente.
Ad esempio un s.o. della famiglia NT (NT, 2000, XP, Vista) non permette in alcun modo a un’applicazione a 16 bit (che gira nel suo apposito subsystem) di accedere direttamente all’hardware o manipolare gli interrupt, per cui possiamo dire addio a vecchi giochi DOS non proprio “ortodossi” che sfruttavano questa (ai tempi legittima) possibilità.
Si tratta sicuramente di un grosso limite, ma permettere, come facevano le versioni di Windows fino alla ’98, l’interazione con l’hardware alle applicazioni DOS poteva facilmente portare a problemi di stabilità o addirittura al crash dell’intero sistema. Virtualizzare e bloccare le risorse hardware rappresenta, quindi, il miglior compromesso raggiungibile per garantire solidità al sistema e un buon livello di compatibilità.
Si potrebbe pensare che almeno le applicazioni WIN16 (che, quindi, giravano sotto Windows 3.x) possano girare tutte senza problemi. Anche questo purtroppo non è vero, perché esistono dei limiti precisi del WOW16 (è chiamato così il layer che si occupa di “traslare” le richieste dell’applicazione dal subsystem WIN16 a quello WIN32, che si occupa di effettuare poi il lavoro vero e proprio).
WOW16 permette di far funzionare esclusivamente applicazioni che girano nella modalità “standard” di Windows 3.x, e non “enhanced”. Quindi sono tagliate fuori tutte le applicazioni più recenti che sfruttavano gli 80386 (e successori) e il codice a 32 bit. Possibile, dunque, che il già citato BOB non sia in grado di girare nella versione per Windows 3.1.
Un altro limite poco noto è quello del numero massimo di handle che un’applicazione WIN16 poteva utilizzare. Un handle rappresenta una “risorsa” (blocco di memoria, file aperto, thread, processo, ecc.) che è stata allocata dal s.o. e che l’applicazione può utilizzare.
Un handle richiede 16 bit per essere memorizzato, per cui un’applicazione WIN16 è teoricamente in grado di poter allocare e gestire fino a 65536 “risorse”. Ebbene, non si sa per quale motivo sia stato fatto, ma WOW16 limita a 14 bit (16384) questo dato. Quindi applicazioni WIN16 particolarmente complesse e avide di risorse, a un certo punto potrebbero smettere di funzionare generando l’errore “The Win 16 Subsystem has insufficent resources to continue running“.
Sembra, comunque, che qualcuno abbia trovato una soluzione a questo problema, patchando in maniera opportuna la libreria di sistema WOW32.dll tramite un procedimento un po’ macchinoso, ma che sembra funzionare.
I problemi con le applicazioni DOS e WIN16 non sono finiti ma, al contrario, sono irrimediabilmente peggiorati se consideriamo che sulle versioni di Windows a 64 bit non è nemmeno possibile farli girare, in quanto i relativi subsystem sono stati rimossi.
In particolare per le WIN16 il problema era particolarmente rognoso da risolvere, in quanto tutti gli handle generati da questi s.o. sono a 32 bit, per cui non era possibile semplicemente “troncarli” restituendo soltanto 16 bit alle vecchie applicazioni.
Non tutte rose e fiori, dunque, con la retrocompatibilità garantita dai subsystem. Purtroppo ogni scelta è sempre frutto di compromessi, e la soluzione adottata da Microsoft non è esente da difetti, ma permette comunque un buon livello di compatibilità con le vecchie applicazioni che, tutto sommato, non dispiace.
Io mi sono sempre chiesto se, data l’ormai abbondante dotazione hardware di ogni computer per le applicazioni home/office, non sia il caso di rendere disponibile la retrocompatibilità su Windows al 100% tramite virtualizzazione, piuttosto che attraverso la logica dei subsystem che in qualche modo penalizza.
Non avrà a che vedere col fatto che i nuovi OS trainano anche nuove applicazioni?
Personalmente la userei per i subsystem troppo vecchi, quindi DOS e WIN16.
Per il resto il meccanismo WOW funziona egregiamente. Vedi WIN32 che gira su s.o. a 64 bit.
Sull’ultima osservazione concordo. E non potrebbe essere altrimenti. Anche qui, Vista che si porta dietro in esclusiva le DirectX 10, è un chiaro esempio di politica volta a favorire lo sviluppo di nuove applicazioni.
per come la vedo io non ha piu’ senso garantire la compatibilità di applicazioni così vecchie su sistemi moderni tramite layer che, se mal programmati, possono portare anche a potenziali problemi di sicurezza e stabilità.
guardiamo al futuro, non al passato (remoto)!
Bhe i nostalgici dove li metti ? Comunque tralasciamo che l’esclusività della DX10 su vista più che favorire lo sviluppo di nuove applicazioni, si voleva uccidre XP nel ambito videoludico portanto ad un trasferimento in massa dei videogiocatori al nuovo OS, ma come ban sappiamo, questo non è successo per ovvi motivi.
Comunque invece di virtualizzare, si potrebba fare un software che simuli le vecchie api, tipo wine per intenderci.
Quoto quanto detto da alessio.
Ormai la virtualizzazione è alla portata di tutti e in questo frangente tenere un subsystem che occupa risorse e mina la stabilità del sistema non ha più senso.
La via dell’emulazione ormai è obsoleta, abbiamo la possibilità di virtualizzare in toto un ambiente a nostro piacimento che a mio avviso porta diversi vantaggi, uno su tutti la scissione dal sistema vero e proprio (esempio: un’applicazione crasha portandosi giù tutto il sistema, va giù la macchina virtuale ma l’os non ha fatto una piega).
Una cosa simile (mi pare, non vorrei dire una cavolata) l’ha fatta Apple con l’ambiente Classic che se non erro è una virtualizzazione di un sistema pre-X (prima di mac os x, da mac os 9 in giù).
Un altro esempio è DOSbox che svolge un lavoro egregio per far funzionare tutti quei vecchi giochi DOS che ci hanno regalato tante ore di divertimento quando eravamo piccini.
Possibile che sia così difficile o così sconveniente alla Microsoft implementare una funzione del genere?
Bah.
In garage ho un 486 con WIN 3.1 e DOS 5.0 ogni tanto lo porto nello studio e faccio girare le cose vecchie che voglio vedere, senza bisogno di virtualizzare.
Anche questa è una soluzione.
Non capisco il motivo di questa sterile polemica. Siamo nel 2009, usiamo programmi quasi sempre a 32bit e spesso a 64 e adesso, tutto d’un colpo, sembra che non avere la possibilità di far girare roba a 16bit o programmata alla C.d.C. sia diventato un handicap grave.
Per anni ci si è lamentati che il grosso delle falle di windows venivano da una esagerata retrocompatibilità e finalmente che si sta facendo qualcosa per chiudere questo infausto capitolo, al grido di “chi ci pensa ai nostalgici” (anche a costo di riscoprire e magari rivalutare oscenità come BoB) e magari, perchè no, “il mio gestionale del 1980 mi serve ancora tanto tanto tanto” si cerca adesso di fare come i gamberi ?
Ma usare Doxbox e farsi meno per… non rompere l’anima è troppo difficile ? Virtualizzare ? Ma dove s’è mai sentita… con la potenza dei computer di oggi e le infime richieste di quei programmi è solamente una cosa inutile se non dannosa (magari il giochino schizza niente meno che a 600 frame per secondo, ma forse quello è il prossimo passo per trovare qualcosa da ridire).
non vedo l’ora che abbandonino la retrocompatibilità e diano un bel taglio al passato e presente e ripartano da capo SENZA alcun virtualizzatore per far funzionare cose obsolete..
per quelle ci sono i sistemi operativi obsoleti..
se win non fosse “obbligato” a tenere questi accrocchi sarebbe migliore in tutti i campi..
@Jak696: purtroppo c’è ancora tanto vecchio software che viene utilizzato, per cui ha senso mantenere questi subsystem.
La stabilità del sistema non è a rischio, perché si tratta di ambienti isolati dagli altri. Ne parlo meglio nel precedente articolo sui subsystem, di cui ho fornito il link.
@Ciny2: diciamo che a livello astratto i subsystem funzionano come WINE, con la traslazione delle chiamate dalle vecchie API alle nuove. Più precisamente, questo è il ruolo svolto dal layer WOW.
Per quanto riguarda le DX10, non possono girar su XP perché richiedono il nuovo driver model che è stato introdotto con Vista.
Gli “ovvi motivi” di cui parli mi sono ignoti; se hai informazioni in merito di cui non sono a conoscenza, riportale pure.
@Don Luca: i subsystem non minano alla stabilità del sistema. Anzi, sono fatti apposta per isolare gli ambienti.
DOSBox e la virtualizzazione sono molto diversi dall’approccio dei subsystem, e richiedono intrinsecamente più risorse.
Inoltre, e questa è la cosa più importante, si tratta di far girare in parallelo s.o. diversi, mentre coi subsystem le applicazioni lanciate sono “omogenee” con quelle native del s.o. (fatta eccezione per le applicazioni DOS, ovviamente).
Infine, coi subsystem tutte le applicazioni possono “cooperare”, condividendo anche dati. Con le macchine virtuali è più complicato e meno efficiente da realizzare.
@Monty: vero. Per chi ne ha la possibilità. :)
@D: non puoi ragionare in termini soggettivi. Purtroppo c’è gente (mi riferisco ad aziende, in particolare), che ha bisogno di far girare vecchie applicazioni.
A volte quando vado in qualche negozio e sono alla cassa mi sporgo un po’ per vedere cosa mostra il terminale, e… ti assicuro che spesso non si tratta di software “ultima moda”. Tutt’altro.
Purtroppo quella della retrocompatibilità responsabile di falle è una leggenda metropolitana dura a morire. Di codice vecchio nei moderni s.o. ce n’è ben poco, proprio perché le chiamate alle API vengono traslate pari pari a quelle nuove, che si occupano di effettuare il lavoro vero e proprio.
Infine ti faccio notare che il mio è un articolo divulgativo, che mira a fare informazione e mettere in chiaro come funzionano i subsystem e i loro limiti. E ne parlo perché si tratta di roba che c’è e che puoi ancora “toccare con mano”.
Se per te fare informazione significa “fare sterile polemica”, allora ne prenderò atto, ma… dissento fortemente.
@Notty: non è possibile farlo per quanto ho detto prima.
Per il resto non vedo perché i subsystem dovrebbero penalizzare Windows in qualche modo. Per come sono realizzati, anzi, offrono un’estensione della compatibilità a un costo che possiamo tranquillamente definire irrisorio, visto che le risorse consumate sono infime.
“non puoi ragionare in termini soggettivi. Purtroppo c’è gente (mi riferisco ad aziende, in particolare), che ha bisogno di far girare vecchie applicazioni.
A volte quando vado in qualche negozio e sono alla cassa mi sporgo un po’ per vedere cosa mostra il terminale, e… ti assicuro che spesso non si tratta di software “ultima moda”. Tutt’altro.”
“Vecchie applicazioni” dovrebbe essere un programma per windows 95, non per il dos 3.0. Aziende e negozi che non vogliono proprio mollare hanno solo da scegliere: continuano con il vecchio 286 fino a quando non schiatta o si arrangiano con qualcosa tipo dosbox.
Sicuramente un problema di incompatibilità c’è però mi domando se è realmente un problema, a parte le nostalgie di vecchi giochi mi domando a chi serva realmente ricorrere a vecchi applicativi a 16 bit.
Io ho molti vecchi giochi che direi mitici e che giravano in ambiente DOS a 16 bit, di tutti l’unica sopravvissuta è la idSoftware (grande Karmak) con il suo primo Doom e la sua reincarnazione II, girano egregiamente in windows XP Professional e non mi è stato diffcile farli girare (be però i programmatori sono stati formati proprio da Microsoft lo stesso Karmak era un ex programmatore Microsoft)
per D:
La maggior parte degli applicativi che vedi nei negozi sono applicativi prodotti da “Buffetti”, io li ho usati qualche anno fa anche se ora non ricordo proprio i nomi … ma ti assicuro li ho usati e ti assicuro che, benché sono applicativi con GUI spartana tipica degli applicativi DOS, sono comunque applicativi a 32 bit
Io non capisco questo incallimento su Vista, le DirectX 10 per la prima volta interfacciano la grafica GDI questo è un’enorme vantaggio perché in Vista il processore centrale non si occupa affatto di grafica tutto è demandato alla GPU, e vi pare poco questo?
E’ chiaro che al vantaggio è contrapposto lo svantaggio della quasi incompatibilità con applicativi non proprio recenti.
Addirittura Autodesk AutoCAD ha problemi a girare in Vista solo la versione 2008 è totalmente compatibile, immaginate gli studi di progettazione (in uno dei quali lavoro io e quindi ne parlo con cognizione di causa)che hanno speso migliaia di euro per la grafica CAD cosa comporta per loro questa incompatibilità … a mio avviso questo il vero problema di Vista, ma parliamoci chiaro vi sono dei momenti che per favorire l’evoluzione della tecnologia è strettamente necessario tagliare con il passato
“La maggior parte degli applicativi che vedi nei negozi sono applicativi prodotti da “Buffetti”, io li ho usati qualche anno fa anche se ora non ricordo proprio i nomi … ma ti assicuro li ho usati e ti assicuro che, benché sono applicativi con GUI spartana tipica degli applicativi DOS, sono comunque applicativi a 32 bit”
Ma vorrei ben sperare che applicativi adesso in vendita siano come minimo a 32bit ma qui il problema è un altro.
Oggi per fare contenta la pizzeria o il meccanico che non vuole mollare il programma che usa da 30 anni (non 5/6, facciamo anche 10, prima del fantomatico bug del 2000 che è servito solo a vendere consulenze fuffa) si pretende una compatibilità esagerata con strutture arcaiche anche a costo di portarsi dietro falle grosse come una casa (da una parte sono contento che gli x86 non derivino dal 6502 o ci sarebbe chi pretenderebbe una retrocompatibilità con il c64 ed il mangiacassette). Domani c’è il furbone che va in giro a dire che fare gli aggiornamenti al sistema è sbagliato portando come giustificazione le più assurde boiate su “bill che spia i computer”. Poi c’è quello che promuove di disattivare procedure di sicurezza a lungo attese come uac ed il controllo driver sparandone certe al cui confronto il furbone di prima potrebbe perfino essere scambiato per uno intelligente ed alla fine, quando abbiamo un sistema non solo fallato ma letteralmente “chiavato” da parte a parte, ecco che scatta la solita riffa di ca_ate che windows è buggato, che è terreno fertile per virus e botnet, che non funziona, che a microsoft sono tutti degli idioti che non sanno programmare….
Ohhh ma basta… retrocompatibilità va bene ma la pizzeria ed il meccanico si diano una regolata che non si può fermare il mondo per loro !
Da una parte viene da chiedersi perchè le nostre leggi sono tanto incasinate quando si parla di specifiche nella realizzazione dei gestionali ma dall’altra c’è solo da ringraziarle e sperare che venissero fatte applicare di più, altrimenti ci sarebbe ancora chi pretenderebbe di usare la pascalina del trisavolo per fare le fatture !
per D:
Ancora sugli applicativi dall’aspetto tipico di quelli che giravano in ambiente DOS … per Windows una finestra è semplicemente un’area rettangolare dello schermo tanto è vero che anche tutto lo schermo è una finestra, si può definire la classe della finestra privandola totalmente dei classici stili e si puo fare in modo che abbiano l’aspetto spartano tipico dei vecchi applicativi DOS ma ciò non vuol dire che l’applicazione è a 16 bit è tutto una questione di rivestimento estetico e decorazione delle finestre … gli applicativi che girano nelle casse dei negozi mantengono il vecchio aspetto semplicemente per rendersi familiare con l’operatore è risaputo che nei negozi agli operatori nella cassa interessa poco i fronzoli grafici come le Enviromental Mapping di Vista, quello che importa è che ritrovano gli stessi menu e la stessa grafica che hanno appreso anche perché sono molto restii ad aggiornarsi (anche dal punto di vista economico)
per D:
Ancora con il codice X86? il codice X86 è diventato semplicemente un protocollo, a partire dal vecchio processore Intel Pentium Pro tutti i processori Intel eseguono codice RISC e sono dotati di apposito convertitore di istruzioni X86 ad istruzioni RISC tanto per far contenti i programmatori e soprattutto i creatori di assemblatori/compilatori di codice ad alto livello. Stessa cosa dicasi per i processori AMD a partire dai vecchi processori K6 II ed è per questo motivo che ad AMD è stato uno scherzetto estendere le istruzioni x86 a 32 bit ad istruzioni x86 a 64bit come gli è stato facile mantenere la totale retrocompatibilità nei primi Athlon64 e nei primi processori Opteron, Intel ha lasciato fare AMD perché pensava di proporre la ex-nova architettura dei suo processori Itanium ma a causa della retrocompatibilità ha riservato gli Itanium per il mercato mainframe dei server e per il settore consumer ha adottato in toto la tecnologia di AMD.
Io non sto parlando di aspetto grafico ma proprio di codice che sta sotto.
Un programma che è stato scritto 20 anni fa di sicuro non può essere *compatibile* con un sistema moderno, a meno che questo non preveda delle librerie di supporto le quali, per svariate ragioni, possono anche portarsi dietro delle falle di sicurezza.
Dopo un certo periodo di tempo aggiornarsi non solo è consigliato ma DOVUTO !
L’ho già spiegato sopra, non si può avere l’uovo e la gallina.
Non si può pretendere sicurezza ed allo stesso tempo completa e totale retrocompatibilità. Il subsystem a 16bit non gestisce tutti gli handle che ci sogniamo di notte ? Pace ! Chi ha progettato la cosa avrà avuto i suoi motivi e solo per aver avuto voglia di supportare tale anticaglia va ringraziato invece che rimproverato. Tecnicamente nel 2009 non dovrebbe neanche più esistere un subsystem a 16 bit su macchine e os che stanno cercando di sbarcare nei 64.
Ho parlato dell’aspetto grafico proprio per rimarcare il fatto che non è la grafica che individua in modo univoco se gli applicativi sono a 32 o 16 bit, e ripeto nuovamente che i programmi che vedi nelle casse dei negozi sono semplici gestionali di magazzino a 32 bit io li ho usati in passato e gia allora erano a 32 bit, la scelta dei produttori di questi software di mantenere la vecchia grafica dos è solo per facilitare gli operatori molto restii ad utilizzatre nuovi programmi, del resto nelle casse si vedono addirittura gli appunti dei tasti per attivare le funzioni dei gestionali di magazzino e questo la dice lunga sul fatto che agli operatori interessano poco i nuovi software e sono restii a cambiare applicativi (del resto se sono dipendenti al datore di lavoro costa aggiornare i dipenenti per nuovi applicativi)
@Fede: sui processori x86, come funzionano all’interno, e il motivo per cui sono stati fatti così stai sbagliando. Ma l’argomento è OT, e avremo modo di affrontarlo a tempo debito.
io vado decisamente controcorrente: i difetti maggiori di win derivano proprio dall’incapacita’ di rompere con il passato portandosi dietro compatibilita’ folli. Segare un po’ di rami secchi e ripartire da 0, oppure a dottare un modello alla unix con librerie di diverse versioni slottate, non un minestrone come allo stato attuale :|
Potresti cortesemente chiarire cosa intendi con “modello alla unix” per le librerie, e quale sarebbe l’attuale situazione che non ti piace?
unix ha un unico grande vantaggio ed è il virtual filesystem
dover garantire la retrocompatibilità a livello di API o dover estendere l’API per supportare nuove classi di periferiche richiede uno sforzo mostruoso
pensa a Cell e com’è stato possibile in pochi mesi portarvi Linux…con Windows ci sarebbero voluti un paio di anni lavorando a perdifiato
il discorso delle librerie di unix invece si può riportare pari pari su windows….alla fine usano lo stesso metodo e cioè creare librerie “retrocompatibili” che fungono da stub verso l’API corrente
Anche Windows, da NT in poi se non erro, ha un virtual filesystem.
Inoltre Windows è stato portato anch’esso su diversi sistemi, e non ci sono voluti anni.
@cesare di mauro
mi riferisco al fatto che ora come ora windows non ha una chiara separazione di cosa e’ usato per la retrocompatibilita’ e cosa no, il risultato e’ avere sempre caricate parti di librerie inutili. Oltre a questo tutta l’infrastruttura utilizzata per la gestione della retrocompatibilita’ e’ un freno allo sviluppo di api nuove partendo da 0 dando un taglio a codice di 10 anni fa
in unix e derivati ci sono spesso dei break di compatibilita’ che obbligano a riscritture onerose ma permettono di mantenere una struttura piu’ moderna, oltre ad esserci una separazione molto piu’ chiara delle componenti richieste per avere a disposizione funzioni piu’ datate
win putroppo paga troppo l’estrema compatibilita’, vuoi per scelte di progettazione, vuoi per scelte anche di marketing
La separazione, al contrario, è netta e garantita proprio dai subsystem.
Proprio i subsystem permettono di “tagliare” col passato fornendo un nuovo modello di API, che ammoderniscono il s.o..
Pensiamo anche a .NET, ad esempio: è taglio nettissimo col passato, e probabilmente diventerà il subsystem standard in futuro. Un po’ come è accaduto con le WIN32.
E al contrario, non credo che il mondo Unix possa essere preso come esempio di modernità, con API vecchie di quasi 40 anni che vengono ancora mantenute e che, anzi, fanno proprio parte della basi del s.o.. Tagli netti come .NET difficilmente ne vedremo…
Non è detto che una API vecchia di 40 anni debba essere eliminata.
Se va bene così com’è può vivere anche per i prossimi 100 anni.
Non è vero che Microsoft tiene sempre alla retrocompatibilità, ad esempio dal framework .NET 1.0 al 3.5 sono cambiate diverse cose, generando non pochi problemi al sottoscritto.