Copy Link
Add to Bookmark
Report
Telematicus Volume 02 Numero 04
#### 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 <stdio.h>
#ifndef MSDOS /* i.e., UNIX */
# include <pwd.h>
#endif
#include <sys/types.h> /* MSDOS or UNIX */
#include <sys/stat.h>
/* 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 <stdio.h>
#define OUT stdout/* Unix, MS-DOS: anybody with decent redirection */
#define NUM_ARGS 2
#define USAGE "Usage: uuencode [infile] remotefile\n"
#include <sys/types.h>
#include <sys/stat.h>
#if MSDOS
#include <io.h>
#include <fcntl.h>
#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<n; i += 3)
outdec(&buf[i], out);
putc('\n', out);
if (n <= 0)
break;
}
}
/*
* output one group of 3 bytes, pointed at by p, on file f.
*/
outdec(p, f)
register char *p;
register FILE *f;
{
register int c1, c2, c3, c4;
c1 = *p >> 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 ###
############ ###
<Commonwealth Hackish> 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 <meta> 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, <fish>, e cosi`
via (vedi <foo>, 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}.
<compact>: 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 <feature> e <cruft> che non si
amalgamano bene con lo schema complessivo del progetto.
<compress> [comprimere - UNIX]: vt. Se usato senza un qualificatore, si
riferisce generalmente al <crunch>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 <USENET>.
<computer confetti> [coriandoli di calcolatore]: n. Sin. <chad>. 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.
<computer geek>: [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. <larval
stage>). Detto anche `turbo nerd', `turbo geek'. Vedi anche {wannabee}, {ter-
minal junkie}.
<computron>: /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 <bitty box>, <Get a real computer!>,
<toy>, <crank>. 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. <bogon>). 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.
<condition out>: [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. <canonical>) e` `#if
0' and `#endif' in C. Confr. <comment out>.
<condom>: [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 <SEX>, 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!
<cons>: [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".
<considered harmful>: [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.
<console>: s. 1. La postazione di operatore su un <mainframe>. 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 <tty> 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 <X>.
<content-free> [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
<flamage>, 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".
<Conway's Law> [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].
<cookie> [biscotto]: un qualunque simbolo di conferma tra processi coo-
peranti. "Gli ho dato un packet, e lui mi ha ritornato un c.". Confr. <magic
cookie>; vedi anche <fortune cookie>.
<cookie file>: s. Una collezione di <fortune cookies> 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.
<cookie monster> [da `Sesame Street': il mostro dei biscotti]. Uno degli
scherzi apparsi all'inizio degli anni '70 sui sistemi <TOPS-10>, <ITS>,
<Multics> e altri, che bloccava il terminale della vittima o la <console> 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 <wabbit>.
<copy protection> [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.
<copybroke> [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. <copywronged>.
<copyleft> [gioco su `copyright']: s. 1. L'avviso di copyright (`General
Public License') compreso nel software <GNU> e in genere della Free Software
Foundation, che garantisce riuso e diritti di riproduzione a tutti gli utenti
(ma vedi anche <General Public Virus>). 2. Per estensione, ogni copyright che
intende raggiungere simili scopi.
<copywronged> [gioco su `copyright'] agg. Sin. per <copybroke>.
<core> [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 <core dump> che
il `core image' o `core file' da esso prodotti sono termini favoriti.
<core dump> [gergo comune nella <Iron Age>, conservato da UNIX]; s. 1.
una copia dei contenuti del <core> 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. <bits>, 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. <brain dump>). V. <core>.
<Core Wars> [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. <core>.
<cosmic rays> [raggi cosmici]: s. Teoricamente, la causa del <bit rot>.
Pero`, ha un utilizzo semiindipendente; esso puo` essere invocato come un modo
umoristico per scacciare via (v. <handwave>) tutte le <randomness> (casuali-
ta`) che non sembrano valere la pena di essere investigate. "Hey, Eric - Mi e`
venuta della schifezza sul mio <tube>, da dove e` arrivata?" "Raggi cosmici,
penso." Confr. <sunspots>, <phase of the moon>. 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)" <ESU0001@HPEENR51.BITNET>
Subject: Uno strano fenomeno
Sender: Red Users Group on Provided Software <RED-UG@TREARN.BITNET>
To: Maurizio Codogno <mau@bilbo.cselt.stet.it>
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 ####
