#### TELEM016 - Telematicus - Volume 02 - Numero 04 - Anno 1992 - 88 pag. #### @@@@@@ @@@@@ @@ @@@@@ @@ @@ @@ @@@@@@ @@ @@@@ @@ @@ @@@@ @@ @@ @@ @@ @@@@@@@ @@@@ @@ @@ @@ @@ @@ @@ @@ @@@ @@ @@@ @@ @ @@ @@ @@ @@ @@ @@ @@ @@ @@@ @@ @@ @@ @@ @@ @@ @@@@@@ @@ @@ @@ @@ @@ @@ @@ @@@@@ @@@@@ @@@@@ @@ @@ @@ @@ @@ @@ @@@@ @@@@ @@@@ Aprile 1992 Bollettino telematico mensile a cura della region 2:33 Fidonet e di .mau. ============================================================================== Il materiale presente in Telematicus e` (C) dei singoli autori. E` espressamente consentita la distribuzione e il riutilizzo del bollettino in tutto o in parte, purche` non a fini di lucro e citando sempre autore e fonte di provenienza. ============================================================================== ***** Indice: pagina 2 - Who's Who: pagina 3 - Distribuzione: pagina 88 ***** ############ ### ### 0 ### INDICE ### ############ ### [ 1] Editoriale, di Maurizio Codogno . . . . . . . . pag. 4 [ 2] Cavi & cavetti - parte 1, di Alfredo Berlusconi . . . . pag. 5 [ 3] Product review: DrComm, di Rocco Rionero . . . . . . pag. 15 [ 4] Un BBS al mese: Olimpus e Kerigma . . . . . . . . pag. 29 [ 5] Il Progetto WARP, di Marco Russo . . . . . . . . pag. 36 [ 6] Il programmino: uuencode e uudecode . . . . . . . pag. 44 [ 7] Vivamiga, di Renato Rolando . . . . . . . . . pag. 60 [ 8] Feedback Utenti . . . . . . . . . . . . pag. 69 [ 9] Curiosita`: Il gergo hacker - parte 13 . . . . . . pag. 75 [10] Notizie Fidonet region 33 . . . . . . . . . pag. 85 Questo Telematicus e` nato con l'aiuto di... Editor inventor: Maurizio Codogno | * I collaboratori dai network: * Editor assiduus: Renato Rolando | Editor fossil: Rocco Rionero | Vertigo (331/301) Editor collegans: Alfredo Berlusconi | Editores presentantes: Luca Bello | Don Paolo Gherri | Editor invettivus: Fabio Filippi | Editor finestrator: Marco Russo | ############ ### ### 1 ### EDITORIALE ### ############ ### Carissimi lettori, numero grosso questa volta. Certo che non e` affatto bello che debba pietire la chiusura di telematicus (che tra l'altro vi ricordo che non mi rende nulla, eccetto un congruo numero di serate a rassettare tutti gli eventuali contributi, per non parlare di quando questi non ci sono) per avere del feedback. Comunque bando alle ciance e sotto con la lettura! ciaociao ... .mau. ############ ### ### 2 ### CAVI & CAVETTI - PARTE 1 ### ############ ### Quante volte vi sara' capitato di avere bisogno di connettere due CPU tramite due seriali ed accorgervi che il classico cavo db25 non serve assolu- tamente a nulla? Per non parlare poi di quando neppure una db9 e' standard e si va verso connettori piatti che di una seriale proprio non hanno neppure l'aspetto. [NdE: in questo momento in ufficio mi hanno messo dei cavi DB-423 - mi pare che si chiamino cosi` - che assomigliano ai jack dei telefoni americani, solo che hanno 6 fili invece di quattro. Boh.] E' incredibile quanto stupidi siano i produttori: ognuno col suo standard (?), chi piatto a 4x2 pin, chi db9, chi db9 ma scegliendosi i segnali da far arrivare ai vari pin (alla faccia di chi parla di mercato "maturo" se vi e' la compatibilita'). In questa giungla chi prospera sono i vari MISCO et simila che vi vendono super cavi "veri db25" che una volta acquistati e' un miracolo se oltre ai 3 fili sempre necessari, mettono un minimo di controllo di flusso (CTS/RTS) oltre al secondo me indispensabile DTR/DSR. Indispensabile, in quan- to parecchi modem, se non hanno il DTR on, non hanno la piu` pallida idea di come fare ad andare in linea. Bando alle ciance (come dicono i brianzoli anche se di adozione come me) e passiamo a fare un bell'elenco di come risolvere i vostri problemi coi cavi, facendo seguito ad una mia replay in echo Fido su di un problema di collega- mento di uno Z88. Innanzitutto ho diviso il problema in 3 sotto-problemi: - collegare il pc (DTE) col modem o la stampante (DCE) - collegare 2 PC identici - collegare 2 PC con differenti aspetti della stessa seriale o addirittura (caso ibm - mac) con 2 seriali diverse. Dopo gli esempi riportati qui sotto, sono sicuro che saprete farvi da voi stessi qualunque cavetto in qualunque caso, una volta conosciuti i segnali che arrivano alla vostra seriale. Innanzitutto, cerchiamo di parlare lo stesso linguaggio: quando prendete in mano una RS232C, potrete avere sia un connettore maschio che femmina. Ve- diamo la numerazione dei pin: [connettore maschio guardando il connettore dalla parte esterna] [ovvero NON dalla parte dove si faranno le saldature] O O O O O O O O O O O O O 1 2 3 4 5 6 7 8 9 10 11 12 13 O O O O O O O O O O O O 14 15 16 17 18 19 20 21 22 23 24 25 [connettore femmina guardando il connettore dalla parte esterna] [ovvero NON dalla parte dove si faranno le saldature] O O O O O O O O O O O O O 13 12 11 10 9 8 7 6 5 4 3 2 1 O O O O O O O O O O O O 25 24 23 22 21 20 19 18 17 16 15 14 Il "senso" della numerazione del connettore db9 e' lo stesso del db25 e quindi evito di riportarlo (compito a casa per voialtri). Passiamo ora a connettere i nostri non troppo standardizzati computers. ======================================================================== ================================ | APPLE MACINTOSH (tipo RS449) | ================================ Guardiamo sul retro di questo PC e noteremo sotto l'icona del telefono un connettore db9 femmina. Disponendo il connettore come la db25 qui sopra, do- vremmo leggere la numerazione della fila con 5 pin nel senso: 5 4 3 2 1. La 449 differisce dalla 232C sostanzialmente per il fatto che per 2 se- gnali non ci sono 3 pin (tx rx gnd in comune) bensi' 4: tx e rx hanno ognuno la propria massa, cosa che rende migliore il segnale e permette di utilizzare cavi molto piu' lunghi dei cavi della 232C. PINS: 1 2 3 4 5 6 7 8 9 Pgnd= massa di protezione Pgnd +5V Mgnd tx+ tx- +12V DTR rx+ rx- DTR = handshake lg0 lg1 lg0 lg1 Mgnd = massa di segnalazione ======================================================================== Collegamento Mac - Modem: MAC (DTE) <------------------> MODEM (DCE) 1 <------------------> 1 massa di protezione 3 <------------------> 7 gnd (comune per rx e tx) 5 <------------------> 2 tx da DTE a DCE 7 <------------------>20 DTR (o 4 se si vuole RTS) 9 <------------------> 3 rx DTE da DCE ======================================================================== Collegamento NULL-MODEM Mac - computer con RS232C MAC (DTE) <------------------> COMPUTER CON RS232C (DTE) 1 <------------------> 1 massa di protezione 5 <------------------> 3 tx --> rx 9 <------------------> 2 rx <-- tx 3 <------------------> 7 gnd (comune per rx e tx) 7 <------------------>20 DTR (o 4 se si vuole RTS) inoltre: 4>5 cortocircuitare 4 con 5 sulla 232C CTS/RTS cosi' da avere sempre l'ok del mancante Handshake Se il collegamento 7 <--->20 fosse invece 7 <--->4 allora il cortocircu- ito andrebbe effettuato fra 20>6 DSR/DTR per gli stessi motivi. ======================================================================== Collegamento NULL-MODEM Mac - Mac MAC (DTE) <------------------> MAC (DTE) 1 <------------------> 1 Pgnd 3 <------------------> 3 Mgnd 4 <------------------> 8 rx+ 5 <------------------> 9 rx- 7 <------------------> 7 HSK (input di handshake) 8 <------------------> 4 tx+ 9 <------------------> 5 tx- /////////////////////////////////////////////////////////////////// ================================ ============================= | MACINTOSH PLUS (tipo RS449) | & | APPLE ][ GS (tipo RS449) | ================================ ============================= Bene, bene. Con questo abbiamo terminato l'Apple Macintosh dotato di in- terfaccia RS449. Ma come sapete, esiste anche il fratello maggiore, il Mac- intosh Plus che, come ogni buona (?) famiglia che si rispetti ha connettore completamente diverso dal precedente db9. Si tratta sempre di una interfaccia RS449 (almeno quello...) ma come potrete immaginare cambiano sia il connettore (adesso e' un DIN8 che ricorda i vecchi registratori a nastro della Geloso) che il numero dei segnali occorrenti (qualcuno in meno). Sul retro del PC, all'estrema destra, troviamo la seguente femmina DIN 8: [connettore femmina guardando il connettore dalla parte esterna] [ovvero NON dalla parte dove si faranno le saldature] O O O 8 7 6 O O O 5 4 3 O O 2 1 PINS: 1 2 3 4 5 6 7 8 GND = massa di segnalazione +12V CTS TX- GND RX- TX+ NC RX+ CTS = handshake DTR HSK lg1 lg1 lg0 lg0 NC = non collegato La massa di protezione (non si vede) e' la schermatura metallica del con- nettore. ======================================================================== Collegamento Mac Plus - Modem: MAC PLUS (DTE) <------------------> MODEM (DCE) 2 <------------------> 5 input di handshake CTS da DTE a DCE 3 <------------------> 2 5 <------------------> 3 4 <------------------> 7 ======================================================================== Collegamento NULL-MODEM Mac Plus - computer con RS232C MAC PLUS (DTE) <------------------> COMPUTER CON RS232C (DTE) 3 <------------------> 3 tx --> rx 4 <------------------> 7 massa di segnalazione 5 <------------------> 2 rx <-- tx inoltre per l'handshaking ingannare la 232 cosi': 4>5 cortocircuitare 4 con 5 sulla 232C CTS/RTS 6>20 " " " 6 con 20 DSR/DTR ======================================================================== Collegamento NULL-MODEM Mac Plus - Mac Plus [DIN 8 - DIN 8] MAC PLUS (DTE) <------------------> MAC PLUS (DTE) 3 <------------------> 5 tx(-) --> rx- 4 <------------------> 4 massa di segnalazione 5 <------------------> 3 rx(-) <-- tx- 6 <------------------> 8 tx+ --> rx+ 8 <------------------> 6 rx+ <-- tx+ ======================================================================== Collegamento NULL-MODEM Mac Plus - Mac [RS449/DIN 8 - RS449/DB9] MAC PLUS (DTE) <------------------> MAC (DTE) DIN 8 DB9 3 <------------------> 9 tx(-) --> rx- 4 <------------------> 3 massa di segnalazione 5 <------------------> 5 rx(-) <-- tx- 6 <------------------> 8 tx+ --> rx+ 8 <------------------> 4 rx+ <-- tx+ ############ ### ### 3 ### PRODUCT REVIEW: DRCOMM ### ############ ### DRCOMM (FOSSIL-level 5 Communication Driver & System Interface) di ROCCO RIONERO Napoli - Italy (2:331/301.10@fidonet.org) DrComm e` un driver di sistema sviluppato secondo lo standard FOSSIL (Fi- do Opus Seadog Standard Interface Layer), in particolare aderisce totalmente alle specifiche del FOSSIL Level 5 descritto nel relativo documento FSC-0015 (Rick Moore, 1:115/333). Lo standard FOSSIL nasce per fornire alle macchine capaci di far girare il sistema operativo MS-DOS (ma non necessariamente 100% IBM-compatibili) un supporto consistente alle principali funzioni di I/O ed in particolare (ma non esclusivamente) alle comunicazioni asincrone, presentandosi come una vera e propria interfaccia di sistema abbastanza standardizzata. In DrComm sono con- centrati diversi anni di esperienza, a vari livelli, nel settore delle comuni- cazioni e della progettazione hw/sw, che mi hanno piu` volte portato a contat- to con le problematiche delle comunicazioni seriali. Trasferire il lavoro svolto sotto l'interfaccia FOSSIL ha consentito (a me, in primo luogo) di sfruttarne al meglio i risultati con tutti i programmi applicativi che ad essa facciano riferimento e con hardware seriale non standard. DrComm e` innanzitutto un driver molto flessibile ed ampiamente configu- rabile, tagliato su misura per gli utenti esigenti che intendano effettuare un preciso fine-tuning del proprio sistema. Il driver e` configurabile attraverso un apposito file di controllo (in puro ASCII) facilmente modificabile con un editor. Queste le caratteristiche fondamentali: - fino a 4 porte di comunicazione supportate - indirizzi ed IRQ per ogni porta definibili a piacere - capacita` di auto-detection dell'hardware seriale - dimensione dei buffers rx/tx fino a 64K - intervento flow control totalmente configurabile - supporto ottimizzato per 6 diversi tipi di UART - "burst-mode" per UARTs bufferizzati e "speciali" - "burst" di trasmissione e ricezione configurabili - speed-locking a tutte le velocita` supportate dell'hardware - doppio protocollo di flow control hardware - possibilita` di protocolli hardware "misti" - protocollo di flow control software (XON/XOFF) RX/TX - protocollo RX-XOFF con ripetizione - auto-disabilitazione TX-XOFF configurabile - monitoraggio anti-lock del sistema di interrupts - estese possibilita` di allocazione dei buffers - possibilita` nativa di occupazione nulla in memoria DOS - utilizzo ottimizzato in ambiente multitask - funzioni di profiling e statistica "built-in" - completa rimovibilita` del driver dalla memoria DrComm supporta fino a 4 porte seriali, utilizzando gli indirizzi presen- ti nella tabella gestita dal BIOS in memoria a 0040:0000, ed i seguenti tipi di UART: 2) INS8250A/16450 (standard su PC/AT) 3) INS16550 4) INS16550A (standard su PS/2) 5) INS16C552 6) i82510 e relativi cloni; gli UARTs non standard-PC (modelli 3..6) sono supportati *totalmente* nelle loro estensioni e non vengono fatti lavorare in modo "8250- compatible". In particolare DrComm e` scritto per gestire con la massima effi- cienza trasferimenti di un numero variabile di bytes in un singolo servizio (burst-mode), massimizzando le prestazioni degli UARTs bufferizzati. Come driver seriale, DrComm e` completamente configurabile. Per ogni por- ta e` possibile specificare: - la dimensione dei buffers di ricezione e trasmissione (in maniera to- talmente indipendente), fino ad un max di 65520 bytes con un minimo di 256 bytes per RX e 64 bytes per TX. - il valore del fattore di blocco di trasmissione (vedi apposita sezione sul "burst-mode"). - le soglie di intervento del flow control in ricezione, ovvero le per- centuali di riempimento del buffer RX alle quali disabilitare e riabilitare il trasmettitore remoto / DCE. - l'eventuale data-rate locking del driver; tutte le velocita` supportate dall'hardware (speed=115200/n con "speed" ed "n" interi) sono lockabili. In tal caso ogni richiesta di modifica da parte del software applicativo verra` rifiutata. - protocolli RTS/CTS e DTR/DSR, o anche protocolli misti per applicazioni particolari (eg. RTS/DSR). - l'uso delle estensioni (FIFO-mode) e la regolazione del livello di trigger in ricezione sugli UARTs per cui sono applicabili (vedi apposita se- zione sul "burst-mode"). - una variante del protocollo XON/XOFF nota come XOFF-repetition per la quale il driver continua ad inviare XOFF fino alla sospensione della trasmis- sione, garantendosi contro eventuali linee disturbate che abbiano fatto falli- re il riconoscimento dell'XOFF da parte del remoto. - la gestione di schede seriali "speciali" ad elevata bufferizzazione, o di UARTs "virtuali" in alcuni ambienti v86. DrComm e` scritto per gestire al meglio gli attuali UARTs bufferizzati; e` in grado, cioe`, di trasferire in una sola richiesta di servizio e con la massima efficienza un numero variabile di caratteri, in funzione dello stato dell'UART e dei parametri di configurazione, con una tecnica per certi versi simile ad una gestione DMA a blocchi ("burst mode"). E` importante sottolineare questo fatto dal momento che, data la compati- bilita` di base con il chip INS8250, gli UARTs bufferizzati (come INS16550A) sono spesso gestiti solo parzialmente dai drivers software, che si dichiarano in grado di supportarli in relazione alla sola capacita` di ABILITARE il buf- fering, senza pero` gestirlo in maniera ottimale. Se nelle normali condizioni di utilizzo questo comportamento e` difficil- mente rilevabile, in multitasking si fa sentire in maniera notevole: la durata di una ISR di DrComm e` fortemente indipendente dal numero di caratteri tra- sferiti e notevolmente inferiore alla media di altri drivers equivalenti. A parita` di transfer rate DrComm impegna di meno il sistema e riesce a garanti- re una frequenza di servizio tale da poter operare alle velocita` piu` elevate anche con normali UARTs non bufferizzati. Gli UARTs bufferizzati consentono di ottenere una riduzione della fre- quenza di interruzione di un fattore pari alla dimensione del "burst". Ad esempio un INS16550A contiene due buffers FIFO (uno per il trasmettitore ed uno per il ricevitore) della dimensione di 16 bytes ciascuno. In trasmissione e` possibile trasferire all'UART fino ad un massimo di 16 bytes in un unico servizio: dal momento che la richiesta di trasmissione viene generata allo svuotamento del FIFO, si ottiene una riduzione di 16 volte della frequenza di TXreq e contemporaneamente, nell'ipotesi di un tempo di latenza superiore al tempo di trasmissione di un singolo carattere -condizione di TX underrun-, se ne riduce della stessa misura l'incidenza sul transfer rate di trasmissione. Normalmente e` consigliabile mantenere la dimensione del burst di tra- smissione pari a quella del buffer FIFO, ma per applicazioni speciali e` pos- sibile ridurre tale valore. A tale scopo il parametro "block factor", nella configurazione di una porta, consente di specificare il max numero di caratte- ri da trasferire all'UART in un singolo servizio. Analogamente e` possibile programmare gli UARTs bufferizzati per generare IRQ di ricezione in funzione dello stato di riempimento del FIFO-RX, in modo da ridurre proporzionalmente la frequenza delle RXreq; ad esempio gli INS1655?? possono interrompere la CPU quando sono presenti 1/4/8/14 bytes nel buffer FIFO; se viene ricevuto un numero di bytes inferiori al livello di trigger programmato, un sistema di timeout interno al chip garantisce la gene- razione dell'interrupt per la lettura del "pacchetto incompleto" (piu` preci- samente: se la trasmissione del remoto si interrompe per un intervallo supe- riore al tempo necessario alla ricezione di 4 caratteri, ed il FIFO non e` vuoto, viene generato un "timeout-interrupt"). Anche qui, come nel caso della trasmissione, le migliori prestazioni si hanno massimizzando il burst di ricezione, ovvero programmando l'UART per in- terrompere al numero piu` elevato possibile di caratteri presenti nel FIFO, tuttavia e` necessario fare qualche ulteriore considerazione sull'incidenza del tempo di latenza nel servizio della ISR di ricezione: un livello di trig- ger "basso" per la generazione della richiesta di ricezione se da una parte non ne minimizza la frequenza, dall'altra lascia un certo margine di sicurezza nel caso di un elevato tempo di latenza. Un esempio e` forse piu` esplicativo di tante parole: programmando l'UART per generare RXreq alla ricezione del quarto carattere (trigger=4) si ottiene una riduzione per "appena" un fattore 4 della frequenza di richiesta, tuttavia si riserva un margine di 12 caratteri (16-4=12) nel caso in cui, per effetto del carico di I/O, la CPU non dovesse servire in tempo la richiesta: fino a 12 caratteri potrebbero continuare ad essere ricevuti completamente prima del- l'intervento della ISR di ricezione, senza che nessuno di essi venga perduto per overrun dell'UART. Programmando l'UART per un livello di trigger pari a 14 si riduce di ben 14 volte la frequenza di richiesta ma si lascia un margine di sicurezza di so- li 2 bytes, che potrebbe non essere sufficiente in talune situazioni. Come sempre e` necessario un compromesso. DrComm consente di selezionare, per gli UARTs che supportano il modo FIFO, due diversi livelli di trigger (che per la famiglia INS1655?? corrispon- dono ad 8 ed a 14 caratteri) in funzione delle condizioni di lavoro del siste- ma. Il primo, "difensivo", e` particolarmente vantaggioso in caso di sistemi in cui convivano contemporaneamente UARTs bufferizzati e non, o di multi- taskers con un notevole numero di tasks attivi. Nel caso di sistemi sufficien- temente veloci in cui il ridotto margine di sicurezza risulti piu` che suffi- ciente, e` possibile scegliere la configurazione col piu` elevato livello di trigger "rilassando" ulteriormente il sistema di interrupts. DrComm supporta oltre ai protocolli hardware RTS/CTS e DTR/RTS (ed even- tualmente "misti"), il protocollo software XON/XOFF sia in ricezione che in trasmissione. Il protocollo XON/XOFF in trasmissione presenta un potenziale pericolo: un carattere XOFF puo` bloccare a tempo indefinito il trasmettitore qualora non venga ricevuto per qualche motivo il corrispondente XON. In DrComm e` possibile abilitare a richiesta l'auto-disabilitazione della sospensione software, trascorso un determinato intervallo di tempo. Questo scongiura il blocco del trasmettitore in caso di falso XOFF o di XON perduto (ad esempio per rumore di linea con modem privi di correzione d'errore, o per perdita di sincronismo col trasmettitore remoto). L'abilitazione dell'auto-xon e` GLOBALE all'intero driver e quindi opera su tutte le porte configurate. Infine, una feature implementata principalmente per l'utilizzo in ambien- te virtual-86 (in cui gli "pseudorupts" sono generati via software) ma che ri- sulta preziosa anche in caso di UARTs "brain-damaged", di calcolatori "disa- strati", oltre che con certi multitaskers particolarmente inefficienti: un si- stema di monitor controlla periodicamente i "semafori" software delle ISR, ri- levando istantaneamente eventuali perdite di interrupts (TXI, MSI) che provo- cherebbero il blocco del driver e "forzando", se applicabile, una ripresa del- la trasmissione. Il sistema di monitor si rivela di preziosa utilita` anche in presenza di software applicativo "scorretto" che acceda direttamente all'UART modificandone lo stato e originando possibili anomalie nel funzionamento del driver. Uno dei grossi limiti dei TSR (DrComm E` un TSR) e` quello di consumare preziosa memoria RAM. DrComm, in modo nativo, consente di allocare in maniera molto flessibile i buffers di comunicazione in aree di memoria specificate dall'utente, ed eventualmente e` in grado di rilocare interamente il proprio codice rendendo nulla l'occupazione in memoria convenzionale. Questa capacita` e` attualmente poco sfruttata, data la grande diffusione di metodi "standard" per caricare i drivers TSR al di fuori della memoria DOS; tuttavia torna utile per quegli utenti che pur avendo macchine con memoria "extra" (tipicamente ne- gli ultimi 384K di ram del primo MB) non possono utilizzare per qualche motivo i normali DOS extenders (i.e. QEMM, etc.), fosse anche per il semplice fatto di non esserne in possesso... Come esempio di "curiosa" applicazione, e` stato possibile installare DrComm su un PC/XT con scheda Hercules, allocando l'intero driver (codice + dati + buffers di comunicazione) nella seconda pagina grafica (B800-BFFF) del- la scheda, preventivamente abilitata. E` ovvio che in tal caso non e` possibi- le eseguire programmi che sfruttino appieno la scheda video... La notevole configurabilita` di DrComm potrebbe confondere le idee: e` bello poter modificare a proprio piacimento tutti i parametri, ma la cosa di- venta frustrante se non si hanno le giuste indicazioni e se non si ha la pos- sibilita` di controllare direttamente il risultato delle modifiche. Quanti sono in grado di dire esattamente quale deve essere la dimensione ottimale per il buffer di ricezione, utilizzando un programma come BinkleyTerm con un modem a 19200bps? Eppure e` un parametro di notevole importanza, dal momento che un buffer troppo piccolo puo` andare in overrun o diminuire l'ef- ficienza del trasferimento con continui interventi del flow control, analoga- mente un buffer inutilmente grande puo` portare a sprechi di preziosa memoria (specie se i buffers sono allocati nei normali 640K "bassi"). Discorso analogo vale per le soglie d'intervento del flow control in ri- cezione, per la dimensione del buffer tx, per il block factor di trasmissione e la regolazione del livello di trigger di ricezione. Durante il normale funzionamento DrComm tiene costantemente traccia (e senza costi addizionali in termini di efficienza) di preziose informazioni sulle sue condizioni di utilizzo. E` possibile, ad esempio, conoscere il max numero di caratteri che siano mai stati contenuti nel buffer di ricezione, il numero di volte che si e` avuto un overrun dello stesso buffer, il max numero di caratteri contenuti nel buffer di trasmissione, il max numero di caratteri ricevuti eccedenti la soglia di intervento del flow-control e via di seguito... DrComm e` nato originariamente come driver FOSSIL-compatibile per l'am- biente DOS-standard. Esso ha sempre funzionato correttamente in ambiente mul- titask nella misura in cui quest'ultimo consentisse di far girare applicazioni DOS-standard. Dal momento che l'uso di multitaskers e` ampiamente diffuso (sia su sistemi multilinea che su sistemi monolinea adibiti contemporaneamente ad usi diversi da quello di BBS), con la versione 0.4.B2 DrComm prevede esplici- tamente la possibilita` di operazioni in ambiente multitask con l'utilizzo di moduli d'interfaccia specifici da caricare all'interno dei singoli tasks. Allo stato attuale e` disponibile il solo modulo per DESQview, ma e` pre- vedibile un successivo supporto ai multitaskers piu` diffusi in base alle ne- cessita` (degli utenti), al tempo (mio) ed alla disponibilita` di documenta- zione adeguata. Il modulo d'interfaccia consente il regolare funzionamento di *tutte* le applicazioni che sfruttano il FOSSIL: e` possibile installare al- l'interno dei tasks applicazioni "external" (ad esempio VFOSSIL) in maniera del tutto indipendente dagli altri tasks. E` analogamente possibile installare timer-handlers senza incorrere in crash del sistema. Inoltre il modulo di interfaccia consente al driver carica- to nella memoria shared di sapere costantemente da quale processo sia chiamato e di gestire in maniera automatica e trasparente (in base alla configurazione data dall'utente) le situazioni di polling, rilasciando il time-slice agli al- tri processi attivi: un normale programma che non preveda il funzionamento in multitask diventa automaticamente, col solo utilizzo di DrComm, un programma "cooperativo" in grado di occupare il solo tempo-CPU strettamente indispensa- bile. Il metodo utilizzato in DrComm per il supporto del multitasking e` com- pletamente originale e del tutto differente da analoghe implementazioni dispo- nibili che consentono una soluzione parziale (e per giunta discutibile) al so- lo problema del time-slicing. Il link stabilito tra il modulo di gestione in- task ed il driver shared e` di tipo puramente dinamico: il modulo *non* si ag- gancia al driver shared e questo, oltre a consentire l'utilizzo di un numero illimitato di moduli in altrettanti tasks (il FOSSIL *non* serve solo a gesti- re le comunicazioni!), garantisce che un task possa essere brutalmente "ammaz- zato" senza compromettere minimamente il funzionamento del driver shared e de- gli altri tasks. COME CONTATTARE L'AUTORE BBS2000 (2:331/301@fidonet.org) e` il BBS ufficiale per il supporto di DrComm. Il mio indirizzo Fidonet e` 2:331/301.10@fidonet.org (e-mail internet: rock@p10.f301.n331.z2.fidonet.org). Su BBS2000 e` sempre disponibile l'ultima versione del programma, prele- vabile in file-request col magicname "DRCOMM" (24H/24 esclusa ZMH ed eventi mail). ############ ### ### 4 ### UN BBS AL MESE ### ############ ### Questa volta a dire il vero i bbs sono due... eccovi la descrizione di Olimpus BBS e Kerigma BBS! .mau. ============================================================================== Ciao a tutti... Come richiesto da .mau. scrivo la mia presentazione. :-) Ho 15 anni, e sono 4 anni che frequento il mondo telematico. Molti di voi mi conosceranno gia' sia per avermi incontrato nelle aree ECHO, sia in ITAPAC, piuttosto che in giro per le varie BBS... Sono point da soli due anni, questo anche perche' c'era poca gente che conoscessi disposta a darmi una mano nel comprendere quel complicato mondo della Telematica. Ero un ragazzino di 11 anni davanti a un computerazzo che per l'epoca non era poi tanto male (un AMIGA 2000) con un modem, e tanta voglia di imparare... Dovetti fare tutto da solo, aumentando cosi' i tempi dell'apprendistato. Se non ci fosse stato Paolo Sobrito (all'epoca Paolo Paolo :-) ) a darmi una mano, sarei restato nel limbo della massa amorfe di utenti che bazzicano spo- radicamente nelle BBS con voglia solo di prelevare files, rimanendo parte im- produttiva. I problemi per settare un point furono piuttosto difficili da risolvere, poiche' il mio primo BOSS ne sapeva ben poco di TrapDoor e compagnia bella. Proprio a causa di questi problemi, incontrai per la prima volta il mio futuro CoSysop Matteo Penna, che mi aiuto' a settare il mio point (ed e' gia' passato un anno... siamo all'anno scorso). Io e Matteo, conoscendoci meglio, notammo che avevamo molte cose in comu- ne, tra le quali l'amore per AMIGA e la voglia di sviluppare qualcosa qui in Piemonte atta a fare da supporto a quella cerchia di utenti che utilizzano AMIGA (poco considerati in questo mondo di MS-DOS! :^) ) Concordammo col no- stro BOSS di montare sulla sua BBS un'area dedicata a questa piattaforma, en- trando in AMIGA_NET, ADS,SAN... Tanti progetti che sfumarono per una quasi inesistente collaborazione del BOSS (e qui chi ha orecchi per intendere, in- tenda! ;-) ) Da questo nacque l'idea di fondare noi una BBS che girasse su AMIGA... Cosi' fu: nacque OLIMPUS... All'inizio c'erano un sacco di problemi (Nuove versioni di Transamiga, l'implementazione del linguaggio AREXX e il nuovo OS2.0) che fecero slittare l'apertura da Natale ai primi di marzo. Ora e' perfetta! Per il momento e' l'unica BBS in Piemonte interamente ed esclusivamente dedicata ad AMIGA. Attualmente viaggiamo a 2400MNP5 dalle 19 alle 07 dal lunedi' al venerdi' e 24H il sabato e la domenica... (011-890084) Se ci sara' risposta da parte degli utenti, acquisteremo presto un modem HST DS e entreremo in SAN e ADS... Staremo a vedere gli sviluppi della situazione! Ciao! Luca Bello Sysop of 2:344/107 ============================================================================== Su espresso invito di Alfredo Berlusconi, di Lecco (circa), invio un ar- ticoletto di presentazione del nuovo BBS a sfondo 'religioso' nato in provin- cia di RE: "KERIGMA BBS". `Collaborazionismo': 1) eccessivo adattamento alle condizioni politico-cultu- rali di un determinato periodo che porta allo snaturamento dei valori di par- tenza... 2) impegno ad oltranza nel ricercare la collaborazione ad ogni costo come unica possibilita' di operare in un determinato settore... Dalla seconda di queste interpretazioni, da una grossa passione per l'e- lettronica, dalla marea di opportunita' offerte dal Word Processing... nacque nel 1989, prima come "Coordinamento" e poi come "Associazione", l'A.P.P.I. (Ass. per la Promozione della Pastorale Informatica). Scopo dell'Associazione e' la raccolta e la ridistribuzione di materiali catechistici e di supporto od ausilio alla pastorale formativa cristiana; inutile (o forse no) specificare che l'idea appartiene ad un gruppo di giovani preti reggiani. Dopo il secondo anno di attivita' associativa, con la raccolta e ridi- stribuzione di 1,2 Mb di materiale catechistico vario in sei provincie anche non emiliane, ecco apparire le prime nozioni telematiche. Quello `speciale' su BIT del settembre 1990, assolutamente incomprensibile senza aver mai accarez- zato un modem, [NdE: Capito, Carcillo?] ha lanciato un vero `petardo' in pic- cionaia: dopo aver sudato il primo settaggio hardware e software della comuni- cazione, ecco spalancarsi un mondo nuovo! La possibilita' di `chiacchierare' con persone a decine di Km di distan- za, la possibilita' di scambiare velocemente materiali, il poter partecipare in tanti alla stessa `discussione'... L'idea e' stata immediata: questo e' quello che ci vuole per far avanzare il nostro 'progetto'! Un SysOp vicino e disponibilissimo (Paolo di "THE DRAKE BBS", Guastalla) ha permesso al novellino di fare le prime esperienze e di introdursi progres- sivamente nel mondo `fatato' dei modem... Perche' non aprire un BBS tutto per la catechesi e la pastorale? L'idea, a dire il vero, era stata quasi abbandonata per le difficolta' delle varie configurazioni ed i legami tra i vari livelli in cui si articola la gestione di un collegamento BBS... ci si sarebbe accontentati di leggere qualcosa in MATRIX su THE DRAKE BBS. A meta' febbraio arriva pero' sul nodo 2:332/502 (The Drake) un messaggio via MATRIX da Genova che chiede informazioni circa una "NEWS" apparsa su "MC microcomputer"; Paolo me lo gira... corro in edicola: finalmente, dopo sei mesi, l'articoletto era stato pubblicato ed aveva suscitato attenzioni! MAXIMUS 2.0, gia' da tempo installato, nella speranza che fosse meno com- plicato da gestire del suo predecessore, comincia allora a girare frenetica- mente sotto i colpi della tastiera locale... Tempo tre giorni e "KERIGMA BBS" e' in grado di rispondere alle prime chiamate. Il tenore dei primi collegamenti e' davvero incoraggiante e le chiamate giungono da varie parti.. unanime il commento: OTTIMA IDEA, CI VOLEVA! Lo scopo di questo BBS e' dichiaratamente `tematico' ed esplicito: per- mettere a chi lo desidera di poter collaborare con altri operatori pastorali alla stesura di sussidi e creazione di nuovi materiali per la crescita cri- stiana, mettendo insieme idee, stili, opportunita' diverse. Qualcuno pare essersi subito `allarmato': "Come... i preti sono gia' qui?!!!" Cinque minuti di `Chattata' e tutto si rasserena... assicuro il col- lega delle nostre intenzioni: nessuna `propaganda' di parte! Non siamo ancora a questi livelli... e non ci interessano neppure! Per la nostra Associazione si tratta, prima di tutto, di una grossa ope- razione culturale: insieme e' meglio... comunque! Il lavoro d'equipe sara' l'unico a dare frutti, almeno in termini di competenza e di risparmio di ener- gie preziose, in un campo dove le forze si stanno drasticamente riducendo. Se oltre alla `Biblioteca Informatica di Pastorale' che ogni aderente al- l'Associazione crea a casa propria ci fosse anche la possibilita' di confronti e consultazioni `dirette', neppure piu' in `tempo reale' ma in `realta' di tempo' tra coloro che operano nello stesso settore, certamente tante cose si potrebbero fare molto meglio. Non e' tempo perso, quello passato davati al monitor ed alle lucine che corrono sul frontalino del modem... potrebbe invece essere la nuova dimensione della collaborazione e di una maggiore efficacia e resa del lavoro di chi in- contra di fatto la gente. Per la nostra Associazione e' una `scommessa', piu' dal punto di vista del metodo che della tecnologia semplicemente... questa ormai pare autonoma, visto che comunque KERIGMA BBS funziona! Chi fosse interessato a questo discorso, o conoscesse persone dell'am- biente che mostrino una certa sensibilita' verso questo tipo di `lavoro', e' vivamente pregato di farsi `sentire', meglio `vedere' (sul monitor). PS: date le evidenti dimostrazioni di intolleranza e pessima educazione e civilta' di cui e' stato oggetto un altro servizio telematico a carattere di- chiaratamante `religioso'... chiediamo il minimo dei diritti civili: esistere anche noi! KERIGMA BBS 0522-978207, 2400bps, 8N1, dalle 12,30 alle 14,00 e dalle 20,00 alle 2,00 (sosta 23,00-24,00) e festivi dalle 8,00 alle 18,00, Luzzara, P.za Castello 5, 42045 (RE) Per l'A.P.P.I. don Paolo Gherri (Kerigma SysOp) ############ ### ### 5 ### IL PROGETTO WARP ### ############ ### WARP - Windowed Architecture for Remote Protocol ------------------------------------------------ Definizione di un nuovo protocollo per l'accesso ad un sistema remoto tramite un'interfaccia utente basata sulle finestre. INTRODUZIONE L'avvento di interfacce utente sempre piu' sofisticate ma allo stesso tempo sempre piu' user-friendly sta rendendo obsoleti i classici sistemi di accesso ad un sistema remoto. Gli standard di emulatori di terminale piu' diffusi (VT-100, ANSI, ecc.) sono basati sulla trasmissione di tutti i caratteri che compongono cio' che l'utente vede; questo significa un'intenso traffico di dati tra host e termi- nale in quanto qualsiasi cosa venga visualizzata, essa deve essere descritta integralmente dall'host. Il terminale conosce quindi soltanto il concetto di carattere, a cui al limite puo' essere associata un'informazione supplementare quale il colore del carattere stesso. Questi protocolli sono nati e cresciuti in un' epoca in cui l'interfaccia utente era estremamente sintetica, anche perche' le risorse a disposizione non consentivano di offrire all' utente le comodita' di cui oggi dispone. Se 10 anni fa poteva non esserci una grossa differenza tra l'ambiente vi- sivo offerto da un'applicazione eseguita da un terminale e quello offerto da un programma su personal computer, oggi questa differenza e' enorme. La vasta diffusione dei personal computer ha pero' messo in secondo piano questa deficenza, perche' molte applicazioni girano oggi su personal computer (che ha definitivamente soppiantato il terminale vero e proprio) e l'accesso a computer remoti per il reperimento delle informazioni viene effettuato da spe- ciali programmi che effettuano queste operazioni in maniera autonoma e "tra- sparente" all' utente. Allo stesso tempo si sono sviluppati dei terminali grafici, quindi con un'interfaccia utente basata non piu' esclusivamente sul carattere ma soprat- tutto sulla rappresentazione grafica degli strumenti a disposizione dell'uten- te. Questi terminali sono progettati per essere collegati direttamente al- l'host tramite linee ad altissima velocita' e ricevono dall'host tutti i co- mandi grafici per disegnare quello che l'utente deve vedere sullo schermo. Uno dei protocolli di questo tipo oggi piu' diffusi e' l'X-WINDOWS, che rappresenta un vero e proprio standard in ambiente Unix. Questo protocollo e' "trasparente" per l'utente (nel senso che l'utente non si accorge del collega- mento non avendo tempi morti) se il collegamento host-terminale ha una veloci- ta' di 2Mbit/secondo. A 9600 baud questo protocollo (pur funzionando...) e' inutilizzabile. Tra questi due sistemi (il terminale a carattere e il terminale grafico) esiste un ampio divario, che oggi e' lasciato completamente vuoto. Non esiste, in pratica, un protocollo valido (standard o non-standard) che consenta di ot- tenere un'interfaccia utente basata su un ambiente a finestre utilizzando un collegamento su linea commutata coi modem oggi in commercio. LA PROPOSTA L'idea, peraltro neanche tanto originale, e' quella di creare un proto- collo che risponda a queste esigenze. Molte idee come questa si sono arenate prima della realizzazione finale. Io non conosco chi prima di me, e di chi con me intende collaborare, si e' ci- mentato in un' impresa simile a questa, ne' tantomeno conosco i motivi che hanno fatto desistere altre persone. Nonostante questo sono fermamente convin- to che il progetto sia realizzabile, anche se l'impresa non appare di modeste dimensioni. Il nome che ho pensato di dare provvisoriamente a questo nuovo sistema di trasmissione basato sulla descrizione degli oggetti rappresentati e' WARP (Windowed Architecture for Remote Protocol). CARATTERISTICHE GENERALI Come gia' detto, quello che si intende realizzare e' un protocollo di trasmissione tra un host e un terminale "intelligente" in grado di offrire al- l'utente un'interfaccia basata su finestre, menu, bottoni, ecc. La differenza tra WARP e gli altri protocolli e' che gli oggetti rappre- sentati (dove per oggetti si intendono finestre, menu, bottoni, ecc.) non ven- gono trasmessi come insieme di primitive grafiche/testuali, ma vengono tra- smessi con la descrizione delle caratteristiche dell'oggetto (tipo di oggetto, dimensioni, colore, ecc.). Ogni oggetto trasmesso e quindi visualizzato verra' poi trattato local- mente dall'emulatore di terminale senza generare traffico sulla linea di comu- nicazione fino a che l'azione dell'utente sull'oggetto non comporti la genera- zione di un comando corrispondente ad una richiesta che l'utente effettua tra- mite l'azione che ha compiuto. Questo significa che se viene trasmesso un oggetto finestra al terminale e' quest'ultimo a gestire autonomamente eventuali operazioni effettuate dal- l'utente, come spostamento/ridimensionamento della finestra. La chiusura di una finestra e' invece un evento che deve essere segnalato all'host, in quanto probabilmente significa la chiusura di una sessione di lavoro. In WARP verranno quindi definiti una serie di oggetti di base, che saran- no quelli che il progettista dell' interfaccia utente avra' a disposizione per costruire tutto quello che desidera visualizzare all'utente. Questi oggetti dovranno essere definiti in modo da prescindere dalle risorse disponibili sul terminale: quindi non dovra' essere indispensabile avere una scheda grafica piuttosto che una scheda testo, come non dovra' avere importanza la risoluzio- ne a disposizione nel caso in cui si disponga di una scheda grafica. Sara' il programma locale a sfruttare al meglio le risorse a disposizione in modo da effettuare la visualizzazione dell' oggetto nel miglior modo possibile. Sara' comunque opportuno prevedere sin dall' inizio un' estensione del protocollo WARP in modo che possa supportare ANCHE oggetti con peculiarita' grafiche (icone e disegni bit-mapped o vettoriali): questi oggetti saranno COMUNQUE opzionali e verranno trattati dall'host quando esso riconosce che il terminale puo' supportare questa estensione. E' importante non chiudere il si- stema in se stesso ma lasciarlo aperto ad implementazioni future, ma allo stesso tempo e' altrettanto importante fare in modo che i requisiti richiesti per supportare WARP siano minimi (la grafica comporta, oltre che la necessita' di un terminale "grafico", anche quella di un modem piu' veloce di un 2400 baud). WARP non prevedera' sofisticate tecniche di controllo degli errori. Que- sto perche' la sempre piu' grande diffusione di modem muniti di protocolli di correzione degli errori (MNP, V42bis) e il miglioramento qualitativo delle li- nee telefoniche non rendono giustificato un considerevole appesantimento del protocollo per gestire autonomamente errori di trasmissione. Ovviamente e' in- dispensabile prevedere un controllo minimo della correttezza delle informazio- ni ricevute, ma questo non significa che il trasmittente debba ricevere con- ferma dell'avvenuto ricevimento delle informazioni trasmesse. La ricezione di informazioni errate dovra' comportare quindi una semplice richiesta di ritras- missione delle stesse informazioni o la fine del collegamento. WARP verra' pensato come protocollo destinato ai collegamenti su linea commutata, ma occorrera' tenere conto di un suo utilizzo su rete a pacchetto in modo da non penalizzare eccessivamente questo sistema per i costi di uti- lizzo. Questo significa che non si dovra' seguire la filosofia del massimo nu- mero di informazioni trasmesse nel periodo di tempo piu' breve, ma occorrera' anche cercare di ottimizzare la trasmissione delle informazioni in modo da ri- durre comunque il traffico generato. SVILUPPO DI WARP WARP verra' sviluppato da un team di persone che lavoreranno su questo progetto senza pretendere un riconoscimento economico. Il loro contributo ver- ra' premiato con la pubblicazione dei loro nomi e dei loro indirizzi (even- tualmente di posta elettronica) nelle specifiche che saranno rese di pubblico dominio. Accanto ad ogni nome verranno evidenziate le parti sviluppate che piu' hanno beneficiato del loro contributo. Per lo sviluppo di WARP esiste una WARP Development Conference che ha co- me punto di riferimento il nodo 2:334/1 della rete Fidonet. Chiunque sia inte- ressato a sviluppare WARP e sottoscriva questo documento (accettando tutti gli obblighi imposti agli sviluppatori) potra' accedere all'area facendo una ri- chiesta a Marco Russo (2:334/1.110@fidonet.org) coordinatore del progetto. Il coordinatore costituisce un punto di riferimento per gli sviluppatori e prov- vede a scrivere e distribuire una documentazione delle specifiche sviluppate. I messaggi scritti in tale area non potranno essere divulgati all'esterno di essa salvo autorizzazione del coordinatore. Qualsiasi contravvenzione a questa regola potra' comportare l'esclusione immediata dal team di sviluppo. OBIETTIVI Le specifiche di WARP saranno rese di pubblico dominio quando esistera' una versione stabile e completa del protocollo e quando esisteranno gia' alcu- ni programmi sperimentali per il supporto di tale sistema. Qualunque software scritto dal team di sviluppo di WARP sara' di proprie- ta' dei singoli autori, che ne faranno l'uso che riterranno piu' opportuno. E' comunque consigliabile una diffusione di programmi di pubblico dominio o shareware che supportino tale protocollo, e questa operazione potra' essere effettuata soprattutto dagli sviluppatori di WARP. Chi avra' partecipato allo sviluppo di WARP non potra' pretendere nessun diritto di proprieta' sulle specifiche del protocollo; potra' comunque pubbli- cizzare il lavoro svolto alla stesura delle specifiche e riceverne un ritorno economico esclusivamente per l'esperienza che avra' acquisito con questo lavo- ro (per esempio offrendo consulenza a ditte che intendano implementare questo protocollo). Marco Russo 2:334/1.110 ############ ### ### 6 ### IL PROGRAMMINO ### ############ ### Questo mese abbiamo la coppia di programmi UUENCODE e UUDECODE. Essi sono di gran lunga i piu` famosi programmi di codifica ASCII di files binari (aumentando ovviamente la loro lunghezza, di un fattore 4/3 circa). Riporto separatamente le notizie di copyright. /* * Copyright (c) 1983 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms are permitted * provided that the above copyright notice and this paragraph are * duplicated in all such forms and that any documentation, * advertising materials, and other materials related to such * distribution and use acknowledge that the software was developed * by the University of California, Berkeley. The name of the * University may not be used to endorse or promote products derived * from this software without specific prior written permission. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ ============================== uuencode.c ==================================== /* * Modified 12 April 1990 by Mark Adler for use on MSDOS systems with * Microsoft C and Turbo C. * * Modified 13 April 1991 by Gary Mussar to be forgiving of systems that * appear to be stripping trailing blanks. */ #ifndef lint static char sccsid[] = "@(#)uudecode.c5.5 (Berkeley) 7/6/88"; #endif /* not lint */ #ifdef __MSDOS__ /* For Turbo C */ #define MSDOS 1 #endif /* * uudecode [input] * * create the specified file, decoding as you go. * used with uuencode. */ #include #ifndef MSDOS /* i.e., UNIX */ # include #endif #include /* MSDOS or UNIX */ #include /* single-character decode */ #define DEC(c)(((c) - ' ') & 077) main(argc, argv) char **argv; { FILE *in, *out; int mode; char dest[128]; char buf[80]; /* optional input arg */ if (argc > 1) { if ((in = fopen(argv[1], "r")) == NULL) { perror(argv[1]); exit(1); } argv++; argc--; } else in = stdin; if (argc != 1) { printf("Usage: uudecode [infile]\n"); exit(2); } /* search for header line */ for (;;) { if (fgets(buf, sizeof buf, in) == NULL) { fprintf(stderr, "No begin line\n"); exit(3); } if (strncmp(buf, "begin ", 6) == 0) break; } (void)sscanf(buf, "begin %o %s", &mode, dest); #if !defined(MSDOS) /* i.e., UNIX */ /* handle ~user/file format */ if (dest[0] == '~') { char *sl; struct passwd *getpwnam(); struct passwd *user; char dnbuf[100], *index(), *strcat(), *strcpy(); sl = index(dest, '/'); if (sl == NULL) { fprintf(stderr, "Illegal ~user\n"); exit(3); } *sl++ = 0; user = getpwnam(dest+1); if (user == NULL) { fprintf(stderr, "No such user as %s\n", dest); exit(4); } strcpy(dnbuf, user->pw_dir); strcat(dnbuf, "/"); strcat(dnbuf, sl); strcpy(dest, dnbuf); } #endif/* !defined(MSDOS) */ /* create output file */ #ifdef MSDOS out = fopen(dest, "wb");/* Binary file */ #else out = fopen(dest, "w"); #endif if (out == NULL) { perror(dest); exit(4); } #if !defined(MSDOS) /* i.e., UNIX */ chmod(dest, mode); #endif decode(in, out); if (fgets(buf, sizeof buf, in) == NULL || strcmp(buf, "end\n")) { fprintf(stderr, "No end line\n"); exit(5); } exit(0); } /* * copy from in to out, decoding as you go along. */ decode(in, out) FILE *in; FILE *out; { char buf[80]; char *bp; int n, i, expected; for (;;) { /* for each input line */ if (fgets(buf, sizeof buf, in) == NULL) { printf("Short file\n"); exit(10); } n = DEC(buf[0]); if ((n <= 0) || (buf[0] == '\n')) break; /* Calculate expected # of chars and pad if necessary */ expected = ((n+2)/3)<<2; for (i = strlen(buf)-1; i <= expected; i++) buf[i] = ' '; bp = &buf[1]; while (n > 0) { outdec(bp, out, n); bp += 4; n -= 3; } } } /* * output a group of 3 bytes (4 input characters). * the input chars are pointed to by p, they are to * be output to file f. n is used to tell us not to * output all of them at the end of the file. */ outdec(p, f, n) char *p; FILE *f; { int c1, c2, c3; c1 = DEC(*p) << 2 | DEC(p[1]) >> 4; c2 = DEC(p[1]) << 4 | DEC(p[2]) >> 2; c3 = DEC(p[2]) << 6 | DEC(p[3]); if (n >= 1) putc(c1, f); if (n >= 2) putc(c2, f); if (n >= 3) putc(c3, f); } /* * Return the ptr in sp at which the character c appears; * NULL if not found */ #defineNULL0 char * index(sp, c) register char *sp, c; { do { if (*sp == c) return(sp); } while (*sp++); return(NULL); } ============================================================================== ============================== uuencode.c ==================================== /* * Modified 12 April 1990 by Mark Adler for use on MSDOS systems with * Microsoft C and Turbo C. Standard input problem fixed 29 April 1990 * as per suggestion by Steve Harrold. */ #ifndef lint static char sccsid[] = "@(#)uuencode.c5.6 (Berkeley) 7/6/88"; #endif /* not lint */ #ifdef __MSDOS__ /* For Turbo C */ #define MSDOS 1 #endif /* * uuencode [input] output * * Encode a file so it can be mailed to a remote system. */ #include #define OUT stdout/* Unix, MS-DOS: anybody with decent redirection */ #define NUM_ARGS 2 #define USAGE "Usage: uuencode [infile] remotefile\n" #include #include #if MSDOS #include #include #endif /* ENC is the basic 1-character encoding function to make a char printing */ #define ENC(c) ((c) ? ((c) & 077) + ' ': '`') main(argc, argv) char **argv; { FILE *in; struct stat sbuf; int mode; /* optional 1st argument */ if (argc > NUM_ARGS) { if ((in = fopen(argv[1], "r")) == NULL) { perror(argv[1]); exit(1); } argv++; argc--; } else in = stdin; #if MSDOS /* set input file mode to binary for MSDOS systems */ setmode(fileno(in), O_BINARY); #endif if (argc != NUM_ARGS) { fprintf(stderr, USAGE); exit(2); } /* figure out the input file mode */ if (fstat(fileno(in), &sbuf) < 0 || !isatty(fileno(in))) mode = 0666 & ~umask(0666); else mode = sbuf.st_mode & 0777; fprintf(OUT, "begin %o %s\n", mode, argv[1]); encode(in, OUT); fprintf(OUT, "end\n"); exit(0); } /* * copy from in to out, encoding as you go along. */ encode(in, out) register FILE *in; register FILE *out; { char buf[80]; register int i, n; for (;;) { /* 1 (up to) 45 character line */ n = fread(buf, 1, 45, in); putc(ENC(n), out); for (i=0; i> 2; c2 = (*p << 4) & 060 | (p[1] >> 4) & 017; c3 = (p[1] << 2) & 074 | (p[2] >> 6) & 03; c4 = p[2] & 077; putc(ENC(c1), f); putc(ENC(c2), f); putc(ENC(c3), f); putc(ENC(c4), f); } ============================================================================== ############ ### ### 7 ### VIVAMIGA ### ############ ### La Seriale II (la rivincita) ---------------------------- Beh, lo ammetto, il number 15 e' stato molto deludente; non vi meritate neppure l'appellativo di 'mucillaggine informe' che vi avevo appioppato. Ed ora permettetemi di rispondere al mio migliore :) lettore: [NdE: grazie.] .mau.> [NdE: perche`, gli #include dell'Amiga non hanno degli .mau.> #ifdef per evitare di includere tutto da capo?] La risposta e' presto data: i file che compongono gli include del 2.0 so- no 230 (duecentotrenta)! E non si puo' chiaramente fare un #ifdef all'inizio di ogni file per evitare di non includere gli altri. Lo si puo' fare al massi- mo per gli include che appartengono ad uno stesso argomento, ma se si inseri- scono assieme due argomenti diversi ecco che si rischia di rileggere piu' vol- te le stesse cose (detto per inciso gli include possono essere 'compattati' per rendere piu' veloce la compilazione, peccato non siano piu' leggibili. Ci sono altre tecniche comunque...). [NdE: e io dovrei considerare decente un SO che non prevede nemmeno di organizzarsi gli #include? piuttosto rimango al- l'msdos] Dunque, ricapitoliamo un attimo le idee sulla precedente puntata; il no- stro task si rivolge al task addetto alla gestione della seriale tramite una message port non standard col tipico approccio client-server. Bene, vediamo ora cosa si puo' passare nell'interfaccia tra i due task. All'interno della dir DEVICES, nel file serial.h, nella struct IOExtSer troviamo inclusa la struct IOStdReq (la struct standard delle msg port): struct IOExtSer { struct IOStdReq IOSer; questa contiene tra le altre cose * 1C UWORD io_Command In questo posto scriveremo il comando da iniare alla seriale. La procedura solita e' fare una 'richiesta sincrona con blocco' (ne avevamo parlato all'i- nizio), ovvero chiedo al task supervisore della seriale di soddisfarmi la ri- chiesta e resto inchiodato li' fin tanto che non mi viene soddisfatta. Natu- ralmente vi sono altre possibilita' e ne vedremo qualcuna in seguito. Solitamente il task master riporta l'esito della richiesta nel campo * 1F UBYTE io_Error (che appartiene sempre alla struct IOStdReq) e, a seconda dei casi, compila il resto della nostra struct. Prima di fare qualche esempio ecco i comandi a di- sposizione della seriale (alcuni sono standard per tutte le devices, altri so- no specifici della serial): CMD_CLEAR, CMD_FLUSH, CMD_READ, CMD_RESET, CMD_START, CMD_STOP, CMD_WRITE, CMD_BREAK, CMD_QUERY, CMD_SETPARAMS Ecco il primo esempio! Voglio che il task elimini dal suo buffer interno tutti i caratteri ricevuti dal modem che non ho ancora letto: MyIOExtSer->IOSer.io_Command = CMD_CLEAR; DoIO ((struct IORequest *)MyIOExtSer); DoIO() e' il tipico invio di messaggio sincrono con blocco (il cast ci vuole per il fatto che non e' la struct standard, casomai te lo fossi dimenti- cato). [NdE: te chi??? io non leggo, guardo solo le figure] Un esempio piu' complicato: inviare una serie di caratteri. char Buff[]="Hello serial!"; MyIOExtSer->IOSer.io_Length = strlen((char*) Buff); MyIOExtSer->IOSer.io_Data = (APTR) Buff; MyIOExtSer->IOSer.io_Command= CMD_WRITE; DoIO ((struct IORequest *)MyIOExtSer); Notare il cast APTR. Questo indica che l'indirizzo dev'essere un multiplo di 4 byte (spero di non dire cazzate!). E' per il fatto che comunque il SO dell'Amiga e' stato programmato con l'antecedente del C e questo esigeva che i dati fossero posizionati seguendo un ben preciso indirizzo (un po' come il 68000 che non puo' leggere indirizzi dispari). La solita rogna della 'compa- tibilita'. [NdE: no, caro RRE, il fatto e` che un processore fa fatica a spo- starsi di un numero di byte qualunque e tende a posizionarsi tranquillo... tanto ce n'e` di RAM] Si potrebbe andare avanti a spiegare a come scrivere e leggere veramente i dati dalla seriale, ma lo spazio e' tiranno (piuttosto se il buon .mau. ha intenzione di scriversi la rivista da solo IO proprio non ce l'ho!) [NdE: e quando mai ne ho voglia?] e tu non vedi l'ora di finire di leggere l'articolo :). [NdE: una volta o l'altra mi dirai chi e` il tuo lettore] Ho deciso piuttosto di spiegare come implementare una richiesta asincro- na. Facciamo un esempio pratico, il ^C. Col DoIO in attesa di caratteri dalla seriale un ^C da tastiera non fa il benche' minimo sollettico al nostro task, questo e' stato messo a dormire in attesa di un evento che lo svegli, e l'unico evento che possa svegliarlo a questo punto e' il completamento di cio' che e' stato richiesto al master task. Voglio dire che al mio task non e' dedicato NEPPURE un ciclo di CPU, [NdE: lo credi tu...] ma viene solo schedulato a livello di segnale. La soluzione e' questa: spedire in modo asincrono la richiesta alla se- riale, preparare una maschera in cui siano riportati gli eventi che devono svegliarci ed... andare a dormire. Noi in questo caso aspettiamo un evento dalla seriale ed uno dalla tastiera (altra device). ULONG WaitMask; ----> la mia maschera, questa ha i primi bit dedicati agli eventi del SO, vo- lendo creare un nuovo tipo di evento si procede piazzandolo dopo aver shiftato ad 1. In questo caso SIGBREAKF_CTRL_C e' riconosciuto dal SO. /* inizializzo le mie struct */ WaitMask = SIGBREAKF_CTRL_C | 1L << SerPort->mp_SigBit; ----> preparo la maschera, mp_SigBit viene settato dal task master quando ha finito di processare il nostro messaggio /* nella procedura Read */ MyIOExtSer->IOSer.io_Length = n; MyIOExtSer->IOSer.io_Data = (APTR) &RBuff[0]; MyIOExtSer->IOSer.io_Command= CMD_READ; ---> mi aspetto di leggere n caratteri SendIO ((struct IORequest *)MyIOExtSer); ----> invio la richiesta di lettura in modo asincrono, quindi continuo a fare altre cose nel mio programma... ... while(FOREVER) { temp = Wait(WaitMask); ----> decido a questo punto di bloccarmi sino a quando non ho uno dei due eventi richiesti. Il Wait() e' il comando di SO che mi permette di andare a dormire in attesa che qualcuno setti uno dei bit che ho settato in WaitMask. /* ho una richiesta di break forzata ... */ if(SIGBREAKF_CTRL_C & temp) { Hang_up(); Write(fout, "\n", 1); WriteError(16); Close_Serial(); exit(16); } /* esco con un break se e' veramente ora */ if(CheckIO((struct IORequest *)MyIOExtSer)) { WaitIO((struct IORequest *)MyIOExtSer); break; ----> bisogna SEMPRE rispondere ad un messaggio (altrimenti non libero la coda del task). Questo e' il metodo piu' semplice per farlo. Prima nel caso del ^C non ho risposto perche' nella routine di chiusura della seriale forzo il can- cellamento di tutte le code liberando eventuali task in attesa. } } /* esco dalla routine di READ riportando il numero di char ricevuti */ return((ULONG) MyIOExtSer->IOSer.io_Actual); Ho deciso alla fine di inserire un pezzo del Gali (il programma per con- nettersi al Galileo) nella speranza di far vedere come in realta' le cose non siano molto casinose ! :) Chiaramente avessi voluto sapere in modo asincrono se il msg era o no soddisfatto mi sarebbe bastato controllare il campo SerPort->mp_SigBit. Bene, il discorso della seriale non si esaurisce qui, spero di concluder- lo la prossima volta illustrando ancora qualcosina di piu' avanzato come la richiesta alla seriale di darci tutti i caratteri fino ad uno a piacere (sen- tinelle) o altre chicche... Naturalmente conto sul tuo silenzio; a proposito una sola persona (oltre- tutto un 2:334/100) mi ha detto di aver provato Gali... e dire che e' finito nella rete SAN. Comunque costui mi ha detto che, essendo solo di 20K, doveva essere un prg facile a farsi. QED. Signori, avete tutto il mio disprezzo. RRE 2:334/100.9 etc. etc. ############ ### ### 8 ### FEEDBACK UTENTI ### ############ ### Vi lascio alla prima parte di un enorme messaggio arrivatomi da Fabio Fi- lippi (che sicuramente ha surclassato il Piola nella classifica dei maggiori scrittori di FidoNet). Ho cercato di lasciare il piu` possibile intatto il suo gergo, a volte particolare... se non lo capite chiedete pero` lumi direttamen- te a lui! ============================================================================== Fatemi capire una cosa... per voi un utente che vampirizza e` un vero utente???? Io credo che un utente che non e` altro che un VEGETALE deve capire che, oltre a supportare la BBS con veri Upload e non uploadare versioni inesi- stenti tanto per farsi crediti deve anche supportare la BBS con dei MSG. Se avessi una BBS non vorrei trovarmi utenti LEECHERS VEGETALI ma utenti reali con la testa sulle spalle che hanno capito il vero spirito di una BBS. Questo msg l'ho pensato quando uno mi risponde che vampirizzare gli sem- bra giusto e quindi ad un certo momento che era l'ora di fare un sondaggio in RETE. Io credo che Tutti sono stufi di vedere che di nuovi files non ce ne sono molti e che a volte downlodano versioni false messe dai VEGETALI tanto per farsi vedere che uppano. Questo se fatto andrebbe punito con la perdita di al- meno 10 volte il file uppato.. su 100k FAKE 1000k persi. Solo che nessuno ha capito che in generale i Download non hanno limite: ci si fida degli utenti ma come al solito si da` un dito e ti prendono il braccio. Ad uppare sono sempre gli stessi mentre i VEGETALI prendono solo. Altra cosa che fanno i VEGETALI e` il 197. Qua andrebbero puniti in maniera drastica. Secondo voi e` giusto prendere e prendere senza dare nulla???. La prima scusa accampata dai VEGETALI e` quella che sono lenti: per pren- dere pero' non sono lenti???? Si fanno 4 utenze per prendersi i 4 dischi di Monkey; e come se non bastasse non rispondono neanche ai msg dei SYSOP, figu- riamoci a quelli dei veri utenti. Come si fa a defenire un vero utente??? e` molto difficile... e non ho voglia di parlarne adesso. Comunque i VEGETALI in Rete sono molti e quindi a nulla e` valso il mega frullamento dello USER.DATA perche` i VEGETALI ne pensano una piu` del diavolo... spediscono le fotocopie di amici; e il Sysop non puo' chiamare tutti, poi lo dovrebbe fare via Modem per verificare se esiste veramente un modem in quella casa. Comunque si fanno scoprire facilmente: chiamano sempre di fila... escono e richiamano subito. Cosi dopo un po' si individuano i VEGETALI multiutenza. Come fare a debellare un VEGETALE??? semplice si impone un RATIO di MSG, ogni TOT di K presi bisogna upparne una quantita' (io direi che un 7/1 sarebbe anche troppo ma potrebbe andare bene) quindi ogni 100k mandati ne prendi 700K o addirittura 1MB. Ma con un particolare!!! devono anche fare un TOT di MSG. Non credo che fare un capture di 5 minuti di un'area e rispondere a casa e poi ASCIISENDare il tutto sia gravoso sulla bolletta. Il problema e` imporre il ragionamento nella mente dei VEGETALI VAMPIRI. Il VEGETALE e` anche un utente che non risponde mai a nulla... e` il primo a protestare che questo e quello non va... poi alla fine prendono solo!. Se tutti fossero cosi' allora chi mette roba nuova in linea??? il SYSOP?? Non mi pare giusto: lui offre il servizio, noi i programmi. Mi sembra il minimo, ma si sa un VEGETALE non ha un cervello per recepire queste cose. Probabilmente non leggera` mai questo mes- saggio, a meno che non venga inserito come FILE in ogni Archivio... forse l'unico modo di comunicare coi VEGETALI e` proprio questo... sempre che poi leggano il testo per intero invece di deletarlo subito. Certo trovare un SYSOP che s'azzardi a mettere un RATIO da 10 a 1 (di solito e` 2/1 o 3/1) non ci vuole magari tanto. Ma non ditegli di mettere un Ratio di MSG... credo che avrebbe paura di farlo... Comunque perdere degli utenti VEGETALI VAMPIRI mi- gliora solo la RETE: almeno chi deve scrivere e mandare programmi trova piu' facilmente libero. A volte basterebbe poco per migliorare tutto ma i VEGETALI manco mandano 1000 lire per le spese... non mandono programmi, se chiedi loro qualcosa e` come offenderli, se mandano qualcosa mandano versioni vecchie per fare i fur- bi, usano i 197 e le Multiutenze... roba da LOCKOUT, cancellare e poco... Met- tere 5 minuti a collegamento e vedere se con il cervello da VEGETALE riesce a capire che ha fatto qualcosa di brutto. E dire che una soluzione per uppare gratis c'e`, anzi si prendono tre piccioni con una fava. I VEGETALI crederanno che sia uno scherzo... ma i file possono anche essere spediti via posta, se il SYSOP non li avesse. Visto che sono solo scuse, quella di essere in Teleselezione o a 2400? Il ridicolo e` che il discorso e` HALF DUPLEX. Finche` prendono tutto OK... ma devono rispon- dere o mandare qualcosa??? Arrivano le scuse. Almeno cosi' potete dire di partecipare anche voi assieme a Tutti alla crescita della RETE. Non mi pare quindi che i VEGETALI possano trovare scuse per non dare nulla. Ma rimane il problema della Multiutenza... i 40/50 minuti esclusi i 20 o persino di piu' che potete prelevare dalla TIME BANK non bastano per quello che dovete fare???? Ma scherzate??? come non bastano... anche un 2400 in un'ora riesce a prendere i files piu' lunghi... il fatto e` che essendo VEGE- TALI si crede che tutto sia dovuto. Mi sembra incredibile... su 2000 utenti in Rete circa... solo meno di 100 scrivono... gli altri 1900 che fanno??? 1500 sono i VEGETALI con doppie utenze quindi si scende a 500 utenti reali. C'e` una buona parte che magari non chiama regolarmente oppure non chiama piu. Si scende ancora... intorno ai 150... c'e' poi chi non sa cosa dire oppure dove inserirsi per dire la sua. Ma mi sembra che di argomenti in ECHO se ne trattino abbastanza... quindi e` evi- dente come anche questa sia solo una scusa. Come e` possibile??? In oltre 80 aree ECHO non ce n'e` neanche una che vi potrebbe coinvolgere??? Forse la ve- ra verita` e` che non sapete neanche voi cosa dire perche' siete VEGETALI e non sapete come fare a compiere i primi passi verso una crescita verso Utenti SEMIATTIVI, quelli meta' VEGETALI e meta' normali. Un ibrido insomma... rispondono solo e continuano a parlare se li stimoli con discorsi... ma appena passa un attimo ecco che tornano VEGETALI. Sono una razza molto difficile da capire, molto piu' difficile che capire i VEGETALI al 100%. A volte parlo con qualche SEMI ATTIVO poi mi scompare, magari ha dei problemi e non chiama per un po', ma poi non ritorna piu'. Lo devi incitare a tornare a parlare e allora forse riesce a superare per la seconda volta la barriera del VEGETALE e tornare SEMI ATTIVO. Solo una piccolissima parte cre- sce ancora e diventa utente ATTIVO. Uno che non usa multiutenze, ha un buon ratio fra Upload e Download, uno che parla e quindi e` di casa in Rete. Posso capire lo CHOC iniziale di entrare in una Rete, ma comunque alla fin fine e` come un BBS a piu' piani. Quello che devo ancora capire non e` perche' ci siano i VEGETALI... quello e` inevitabile, in ogni campo esistono i VEGETALI... ma i SEMIATTIVI proprio non li capisco. Sembra non sappiano de- cidere quale strada che debbano compiere... sono ad un bivio e non sanno cosa fare, quindi pascolano un po' in attesa di prendere una decisione, ma a volte non arriva... Adesso comunque sorge un altro problema! Come faccio a smettere di essere VEGETALE?? cosa posso scrivere di utile per gli altri utenti???? A parte i programmi da uppare che a volte qualcuno non puo' procurarsene ma comunque dovrebbe cercare di far qualcosa... Anche piccole cose sono gradite... magari dei moduli o delle GIF o piccole utility prese da altre parti. Basta fare un passo per volta... cominciamo a vedere co- me un VEGETALE puo' cercare di inserirsi in un discorso... [segue] Fabio Filippi 2:331/301.0 ############ ### ### 9 ### IL GERGO HACKER - PARTE 13 ### ############ ### s. Il gergo hacker come parlato fuori dagli USA, sp. nel Commonwealth. E` stato riportato che in quei paesi e` piu` comune pro- nunciare `char', `soc', ecc. come scritto (/ciar/, /sok/) piuttosto che al- l'americana /keir/ o /sosh/. Il prefisso puo` essere pronunciato /mi'ta-/, e in genere le lettere greche beta, zeta... si leggono /bita/, /zita/. Le metavariabili sintattiche preferite sono EEK, OOK, FRODO, e BILBO; WIBBLE, WOBBLE, e in emergenze WUBBLE; BANANA, WOMBAT, FROG, , e cosi` via (vedi , sign. #4). Alternative al raddoppio del verbo comprendono i suffissi `o-rama', `frenzy' [frenesia, smania] e `city' (come in "barf city!" "hack-o-rama!" "core dump frenzy!"). Si noti infine che i termini americani `parens', `brackets' e `bra- ces' per (), [], and {} non sono comuni; si preferisce `brackets', `square brackets', e `curly brackets'. Fuori dagli USA e` anche comune l'uso di `pling' per {bang}. Vedi anche {attoparsec}, {calculator}, {chemist}, {console jockey}, {fish}, {grunge}, {hakspek}, {heavy metal}, {leaky heap}, {lord high fixer}, {noddy}, {psychedelicware}, {plingnet}, {raster blaster}, {seggie}, {spin-lock}, {ter- minal junkie}, {tick-list features}, {weeble}, {weasel}, {YABA}, e le note o definizioni sotto {Bad Thing}, {barf}, {bogus}, {bum}, {chase pointers}, {cosmic rays}, {crippleware}, {crunch}, {dodgy}, {gonk}, {mess-dos}, {nybble}, {root}, {tweak}, e {xyzzy}. : agg. Di un progetto, descrive la preziosa proprieta` di potere essere compreso in un colpo solo. Questo significa generalmente che le cose create dal progetto possono essere usate con maggiore facilita` e minore erro- ri rispetto a un progetto equivalente che non e` compatto. Si noti che la com- pattezza non implica banalita` o mancanza di potenza: ad esempio, il C e` com- patto e il FORTRAN no, ma il C e` piu` potente del FORTRAN. Il progetto diven- ta non-compatto mediante la concrezione di e che non si amalgamano bene con lo schema complessivo del progetto. [comprimere - UNIX]: vt. Se usato senza un qualificatore, si riferisce generalmente al ing di un file usando una particolare imple- mentazione in C della compressione Lempel-Ziv di James A. Woods et al., e circolata ampiamente via . [coriandoli di calcolatore]: n. Sin. . Anche se questo termine e` comune, questo uso dei chad da una scheda perforata non e` una grande idea, perche` i pezzi sono spessi e hanno angoli acuti che possono ferire gli occhi. GLS riferisca che un tempo ando` a un matrimonio al MIT in cui lui e qualche altro invitato lanciarono entusiasticamente chad al posto del riso. Lo sposo si lamento` in seguito del fatto che lui e la moglie dovet- tero passare buona parte della serata cercando di togliere quella roba dalla testa. : [geco dei computer?] s. Uno che mangia (computer) bugs nella vita. Uno che risponde ai piu` cupi stereotipi negativi sugli hackers: un monomaniaco asociale, maleodorante, pallido con la personalita` di una grattugia. Non puo` essere usato da estranei senza un insulto implicito a tut- ti gli hacker, un po' come la parola `nigger'. Un c.g. puo` essere un indivi- duo fondamentalmente incapace o un proto-hacker allo stato larvale (v. ). Detto anche `turbo nerd', `turbo geek'. Vedi anche {wannabee}, {ter- minal junkie}. : /kom'piutron/ [computrone] s. 1. Un'unita` nozionale di po- tenza di calcolo che combina velocita` delle istruzioni e capacita` di memo- ria, definita all'incirca come istruzioni/secondo per megabytes RAM per mega- bytes disco. "Non puoi fare girare GNU EMACS su quella macchina, non ha abba- stanza computroni!" Questo uso si ha generalmente nelle metafore che trattano la capacita` di calcolo come un bene fungibile, come il raccolto di un campo o la potenza di un motore diesel. Vedi , , , . 2. Una mitica particella subatomica che porta la quantita` unitaria di computazione o informazione, piu` o meno allo stesso modo in cui un elettrone porta un'unita` di carica elettrica (v. ). E` stata svi- luppata un'elaborata teoria pseudoscientifica sui computroni, basata sul fatto fisico che le molecole in un oggetto solido si muovono piu` rapidamente se lo si riscalda. Si arguisce che un oggetto fonda perche` le molecole hanno perso la loro informazione su dove dovrebbero essere (cioe`, hanno emesso dei compu- troni). Questo spiega perche` i calcolatori si scaldano cosi` e richiedono il condizionamento d'aria; usano computroni. Inversamente, si potrebbe raffred- dare un oggetto facendolo attraversare da un raggio di computroni. Si pensa che questo possa anche spiegare il fatto che le macchine che funzionano in fabbrica falliscano nella stanza dei calcolatori - perche` i computroni sono gia` stati usati tutti dal vostro altro hardware. : [condizionare via] vt. Fare in modo che una parte di co- dice non venga compilata ponendola in mezzo a una direttiva di compilazione condizionale che sia sempre falsa. L'esempio canonico (v. ) e` `#if 0' and `#endif' in C. Confr. . : [preservativo] s. La custodia protettiva di plastica dei di- schetti da 3.5". A differenza del write protect, il c. (se lasciato) non solo impedisce la pratica del , ma e` stato dimostrato avere un alto tasso di fallimento quando i meccanismi del drive cercano di accedere al disco - e puo` persino frustare fatalmente l'inserzione! : [dal LISP] 1. v. Aggiungere un nuovo elemento a una lista, sp. all'inizio. 2. `cons up': vt. Sintetizzare da pezzi piu` piccoli: "to cons up an example". : [considerato nocivo] agg. L'infame nota di Edsger W. Dijkstra nelle Communications of the ACM di marzo 1968, `Goto Statement Con- sidered Harmful', lancio` la prima bordata nella guerra della `programmazione strutturata'. E` divertente notare che l'ACM ha considerato la lite risultante cosi` nociva da evitare (per policy) di pubblicare un articolo che prenda una posizione cosi` assertiva contro una pratica di codifica. Nelle decadi succes- sive, un gran numero di articoli seri o parodistici sono usciti con titoli della forma `X considerato Y'. La guerra della programmazione strutturata e` terminata quando si capi` che entrambe le parti avevano torto, ma l'uso di ti- toli simili sono rimasti come tormentone. Il `considerato stupido' (considered silly) trovato spesso tra queste voci e` correlato. : s. 1. La postazione di operatore su un . Nel lonta- no passato, era una postazione privilegiata che conferiva poteri divini a co- lui (quasi invariabilmente un `lui') che aveva le dita sui tasti. Sotto UNIX e altri SO multiutente, e` semplicemente il da cui si fa partire il siste- ma. Rimane pero` del mistico, ed e` tradizionale per i sysadmin postare mes- saggi urgenti per tutti da /dev/console. 2. Sui microcomputer UNIX: lo schermo principale e la tastiera (opposti ai terminali a caratteri collegati via se- riale). Tipicamente solo la console puo` fare grafica o girare . [libera dal contenuto]: agg. Ironica analogia di `context- free' [libera dal contesto], usata per un messaggio che non aggiunge nulla al- le conoscenze del destinatario. Anche se l'aggettivo e` a volte applicato al , connota piu` in genere derisione per gli stili di comunicazione che esaltano la forma sopra la sostanza, o sono centrati su questioni irrilevanti rispetto all'attuale soggetto. Usato per lo piu` con riferimento ai discorsi dei presidenti di societa`. "Content-free? Uhm... qualunque cosa stampata su carta patinata". [Legge di C.]: prov. La regola che afferma che l'organiz- zazione del software e l'organizzazione dei softwaristi sono congruenti: espressa originariamente come "Se hai quattro gruppi che lavorano su un compi- latore, si otterra` un compilatore a quattro passi". E` stata promulgata originariamente da Melvin Conway, un protohacker del pas- sato che scrisse un assembler per il Burroughs 220 chiamato SAVE. Il nome non aveva nessun significato nascosto; era stato scelto semplicemente perche` ve- nivano buttati via meno listati - in cima a tutti c'era scritto SAVE [salva]. [biscotto]: un qualunque simbolo di conferma tra processi coo- peranti. "Gli ho dato un packet, e lui mi ha ritornato un c.". Confr. ; vedi anche . : s. Una collezione di in un formato che facilita la loro estrazione da un programma di fortune [le massime]. Ce ne sono diversi liberamente distribuibili, e i sysadm ne creano spesso a partire da varie sorgenti compreso questo lessico. [da `Sesame Street': il mostro dei biscotti]. Uno degli scherzi apparsi all'inizio degli anni '70 sui sistemi , , e altri, che bloccava il terminale della vittima o la do- mandando ripetutamente "I WANT A COOKIE" [voglio un biscotto]. Le risposte ri- chieste variavano in complessita` da "COOKIE" a "HAVE A COOKIE" [prendi un bi- scotto] e oltre. Vedi anche . [protezione dalla copia]: s. Una classe di metodi in- telligenti per prevenire i pirati incompetenti dal rubare software e i legit- timi acquirenti dall'usarlo. Considerato stupido. [gioco su `copyright']: agg. Usato per descrivere una copia di un programma protetto dalla copia che e` stato `broken' [violato]: cioe`, un copia con la protezione contro le copie disabilitata. Sin. . [gioco su `copyright']: s. 1. L'avviso di copyright (`General Public License') compreso nel software e in genere della Free Software Foundation, che garantisce riuso e diritti di riproduzione a tutti gli utenti (ma vedi anche ). 2. Per estensione, ogni copyright che intende raggiungere simili scopi. [gioco su `copyright'] agg. Sin. per . [nucleo]: s. Memoria principale o RAM. Data dal tempo della memo- ria in nuclei di ferrite; ora arcaico al di fuori dell'IBM, ma ancora usato anche nella comunita` UNIX e da vecchi hacker o chi vuol far credere di esser- lo. Alcuni modi di dire da esso derivati sono ancora correnti: `in core', per esempio, significa `in memoria' (opp. a `su disco'), e sia il che il `core image' o `core file' da esso prodotti sono termini favoriti. [gergo comune nella , conservato da UNIX]; s. 1. una copia dei contenuti del prodotti quando un processo abortisce per certi tipi di errore interno. 2. Per estensione, usato per uomini che svenga- no, vomitino o abbiano uno choc estremo. "Ha fatto un c.d. . Tutto sul pavi- mento. Che casino." "L'ha sentito... e ha fatto un c.d.". 3. Una ricapitola- zione di conoscenze (confr. , sign. 1). Da qui, sparare tutto quello che si sa su un argomento, spec. in una presentazione o come risposta a una doman- da di esame. "Risposte corte e concise sono meglio di c.d." (dalle istruzioni di un esame di qualificazione alla Columbia: confr. ). V. . [guerre dei nuclei]: s. Un gioco tra programmi `assembler' in una macchina simulata, dove l'obbiettivo e` uccidere il programma del vostro avversario soprascrivendoci. E` stato popolarizzato nella rubrica di A. K. Dewdney su `Scientific American', ma si narra che e` stato inventato da Victor Vyssotsky come un hack su un PDP-1 hack, nei Bell Labs all'inizio degli anni '60. Corre voce che il gioco sia una versione civilizzata di un divertimento chiamato DARWIN comune sulle macchine multitask prima dell'avvento dei segmen- ti protetti di indirizzo. V. . [raggi cosmici]: s. Teoricamente, la causa del . Pero`, ha un utilizzo semiindipendente; esso puo` essere invocato come un modo umoristico per scacciare via (v. ) tutte le (casuali- ta`) che non sembrano valere la pena di essere investigate. "Hey, Eric - Mi e` venuta della schifezza sul mio , da dove e` arrivata?" "Raggi cosmici, penso." Confr. , . Gli inglesi sembrano preferire l'uso di `cosmic showers' (tempeste cosmiche); si sente anche dire `alpha par- ticles', poiche` fasci di particelle alfa che passino attraverso i chip di me- moria possono causare errori di un bit (cosa sempre piu` probabile man mano che grandezza e densita` delle memorie crescono). Nota fattuale: le particella alfa causano il bit rot, i raggi cosmici no (ge- neralmente, tranne forse per calcolatori spaziali). L'Intel non poteva spiega- re errori casuali nei suoi primi chip. Un'ipotesi era quella dei raggi cosmi- ci. Essi crearono allora Il Piu` Grande Schermo Piombato Del Mondo, 25 tonnel- late di piombo, e usarono due schede identiche per il test. Se davvero il bit rot era causato dai raggi cosmici, si sarebbe dovuta trovare una differenza statisticamente significante tra il tasso di errore nelle due schede. Risulta- to: ipotesi scartata. Ulteriori investigazioni dimostrarono che la colpa era delle emissioni di particelle alfa dal torio (e in minor misura dall'uranio) nel materiale di incapsulazione. Visto che e` impossibile eliminare questa ra- dioattivita`, distribuita uniformemente sulla crosta terrestre, con la insignificante deviazione statistica delle miniere di uranio), divenne ovvio che il disegno delle memorie dovesse tenerne conto. ############ ### ### 10 ### NOTIZIE FIDONET REGION 33 ### ############ ### Stante la solita mancanza di notizie dagli altri network (piu` precisa- mente, Vertigo mi avvisa esplicitamente che questo mese non ci sono nuove dal 331, oltre a spedirmi la presentazione di DrComm tagliata per ragioni di spa- zio), ricordo solamente agli affezionati lettori del network 334 che la riunione mensile non programmata ad aprile si terra` invece, rimandata a lunedi` 13 - ore 21 - C.so Sicilia 12 c/o il CRDC. Confermata la riunione del 2 maggio, nella quale potreste magari anche fare gli auguri di compleanno al vostro editor preferito :-) Puo` essere pero` interessante questa notizia che ho recuperato nella lista europea universitaria sui PC IBM e che potrebbe probabilmente riaprire un discorso in DEWDNEY.ITA. Eccola qui, debitamente tradotta: ============================================================================== From: "Harrie Overdijk. (++31-2246-4597)" Subject: Uno strano fenomeno Sender: Red Users Group on Provided Software To: Maurizio Codogno Cari *.*, Ieri ho fatto una scoperta molto interessante: Stavo facendo degli esperimenti e volevo sapere il peso di un dischetto "3M" da 5.25 pollici, alta densita`. Ho formattato il disco e l'ho pesato con una bilancia di precisione (io studio chimica, quindi in laboratorio non ho problemi a recuperarla). Il suo peso era di 13.695 grammi (la precisione della bilancia e` di 1/200 di grammo). Ho poi pesato un disco che avevo precedente- mente azzerato (avevo scritto un programmino che creava un files con tutti i 1213952 bytes a zero). Il peso del disco era di 13.645 grammi. La cosa mi ha stupito alquanto, e ho preso gli altri dischetti da format- tare della scatola. Effettivamente il peso medio di questi dischetti era di 13.700 grammi, quindi statisticamente parlando il disco con tutti 0 pesava 0.055 grammi meno degli altri. Ho immediatamente scritto un nuovo programmino che riempisse il mio dischetto di prova con i bit tutti settati a 1. Non ci crederete, ma effettivamente il disco pesava 0.055 grammi piu` della media di quelli non formattati. Ma la cosa che mi ha lasciato piu` stupito e` stata il fatto che, scrivendo sul disco i bit alternati (01010101...) il disco non e` risultato pesare 13.700 grammi come immaginavo, ma 13.620 grammi, cioe` *meno* di quello con tutti zeri. Chi e` che puo` spiegarmi questo fenomeno? Ha forse a che fare col campo magnetico terrestre? (questa idea mi e` venuta adesso, purtroppo non ho pensato a girare i dischetti prima di pesarli). Greetings, Harrie Overdijk Bitnet/EARN : ESU0001@HPEENR51 ECN - Petten Internet : OVERDIJK@ECN.NL Holland Noisenet : ++31-2246-4597 ============================================================================== Beh, se avete qualche idea di spiegazione scrivetemi, altrimenti saro` costretto a vedere cosa mi diranno i miei amici in DEWDNEY.ITA... Telematicus puo` essere downloadato dai seguenti nodi Fidonet: 334/100 - 011-3299706 | 334/1 - 011-5765565 | 331/112 - 0341-360511 333/603 - 040-3783111 e dai nodi ISN 331/301 - 02-76006857 | 331/106 - 0332-706469 | 331/201 - 030-293250 331/202 - 0373-273188 | 331/206 - 0523-896512 | 331/318 - 0382-575369 332/206 - 019-853037 | 332/404 - 051-554430 | 332/305 - 0541-777003 332/402 - 051-6331730 | 332/403 - 051-6231940 | 332/102 - 055-2364065 332/108 - 055-2298120 | 332/502 - 0522-824379 | 332/504 - 059-450643 333/304 - 049-9200386 | 333/207 - 0445-530103 | 333/401 - 0471-200004 333/404 - 0474-21123 | 333/505 - 0422-431041 | 333/507 - 0431-430945 334/0 - 011-5765568 | 334/306 - 0121-542795 | 335/210 - 081-5709527 335/405 - 06-315323 #### End of TELEM016 ####