Newsgroup: it.comp.retrocomputing
Titolo: [Mac software] WinWorld

In un altro thread, è stato menzionato WinWorld come archivio di sw per 
Mac.
Dopo aver scaricato praticamente tutto, senza averlo provato, ho avuto 
l'idea di provare sul Plus qualche System precedente al 6-7.
Il problema è il seguente: i files scaricati da WinWordl sono .rar e, 
decompressi, generano files .img o .image.
Naturalmente, ho scelto le immagini da 800k, scartando quelle da 400k e 
da 1440k.
Trasferite sull'LC III, Disk Copy (4.2 o 6.3.3) non le riconosce affatto.
E la cosa sembra ripetersi per tutte le immagini che ho provato.
Il System 6.0.8 che uso, per ora, sul Plus, l'ho scaricato dal sito 
Apple, ed era .sea, nessun problema.
Ho pensato che, nell'espansione del .rar nella macchina Linux, si perda 
un fork.
Installo StuffIt 5.5 (sul 7.1, con boot dal Network Access Disk 7.5 
perché l'Installer si lamentava che non c'era almeno il 7.1.1): gli dico 
di espandere l'immagine .rar e non fa assolutamente nulla, neanche un 
lamento.
Domanda: qualcuno di voi ha provato il materiale presente su WinWorld ?
Oppure, come dice il nome, Win (dows) ha provveduto a render il materiale 
inutilizzabile ?
L'ultima prova che posso fare è con le immagini da 1440.

Unrar descrive i files contenuti nell'archivio, di tipo Win95/NT, dunque 
niente forks archiviati.
Dev'esser il formato dell'immagine a non esser gradito ...

 E la cosa sembra ripetersi per tutte le immagini che ho provato.
Ciao Supervinx,
sinceramente non avevo mai provato le versioni di Mac OS su WinWorld, ma 
facendo qualche test sembrerebbe che i dischi fossero stati creati con 
DiskCopy, quindi copiati su un filesystem che non supporta i resource 
fork e lì compressi. In poche parole, è praticamente impossibile 
ricreare i files originari.
Comunque, se ti servono solo i System precedenti alla 6.0, li puoi 
trovare anche su Mac Garden o Preterhuman.
Saluti
EngiNerd


È proprio la stessa cosa che avevo pensato io ... WinWorld ... il 
passaggio attraverso Windows è sempre deleterio ... :P
Domanda: non è che si può ricreare la "resource" mancante con ResEdit o 
consimili ?

 un fork.
muoio dalla voglia di conoscere il tuo concetto di fork in una copia bit to 
bit.
con simpatia ;-)

 consimili ?
Quasi certamente se l'immagine non ha una dimensione tipica e/o il 
contenuto compresso la cosa è impossibile, dato che nel resource fork 
sono salvate le informazioni sulla dimensione, la checksum ed altri dati 
in formato binario.
Per quanto riguarda invece le immagini non compresse di floppy, credo 
che qualche speranza la si possa nutrire, anche se in passato ho fatto 
alcuni tentativi conclusisi purtroppo con esito negativo: per esempio ho 
creato un'immagine vuota con DiskCopy, ho aperto quest'ultima con 
ResEdit ed ho fatto copia&incolla degli elementi del resource fork;
ho anche provato ad usare DiskDup+ e ShrinkWrap, software per il 
recupero dati da immagini disco danneggiate, ma anche in quest'ultimo 
caso nulla da fare.
Se ci fossero sviluppi vi farò senz'altro sapere
Saluti
EngiNerd
P.S.: se ti servisse qualcosa di specifico sono sempre a disposizione 
(per contattarmi usa la mail dell'intestazione o 
webmaster<dot>crrc<at>gmail<dot>com )



Senza usare la terminologia adatta, della quale sono sprovvisto in ambito 
Mac:
1) Le immagini provenienti dall'espansione di un .sea (sito 
Apple), .image, sono visualizzate con una bella icona e riconosciute da 
Disk Copy.
2) Le immagini provenienti dall'espansione di un .rar (WinWorld), 
sempre .image, non hanno nessuna icona e non sono riconosciute da alcun 
programma.
3) Ora, benché i dati dovrebbero essere una copia bit-a-bit del disco 
originale, non la posso ricreare su di un Mac in assenza delle ulteriori 
informazioni contenute (presumibilmente) nel resource fork che si è perso 
strada facendo (non è contenuto nel .rar). Faccio notare che le immagini 
prelevate da WinWorld contengono un header di 84 bytes.
4) Ora, se l'immagine è da 1440K, rimosso l'header posso utilizzare dd ed 
ovviare. 
5) Se l'immagine è da 800K, dal momento che i Mac utilizzano il GCR, non 
posso utilizzare dd su di un PC.
6)-> 4) A meno che non ci sia un'utility su Mac che non sia Disk Copy ed 
accetti i dati così come sono. Previa rimozione dell'header, s'intende.
Riassumendo: se si rimuove l'header di 84 bytes iniziali
(ad esempio, immagine da 1440k)
dd if=image of=image.raw ibs=1 obs=512 skip=84 count=1474560 
image.raw può esser scritta con dd e letta tranquillamente.
Mi resta il problema per le immagini 800k.
Rimuovendo l'header, cosa utilizzo in ambito Mac ?

 Rimuovendo l'header, cosa utilizzo in ambito Mac ?
non saprei.. però se mi dici l'url, provo a fare il debug con vmac ^^
bye. 



http://winworldpc.com/downloads.php?path=%28Abandonware%29+Operating
+Systems%2FMacintosh/
Mi chiedevo solo se esistesse un programma analogo a dd su Mac, per 
scrivere immagini disco raw non compresse.
Ma un'idea m'è già venuta: con Disk Copy effettuo un'immagine valida di 
un disco 800k. Mi copio il resource fork, lo adatto all'immagine che ne è 
sprovvista, la unisco ad essa e la dò in pasto a Disk Copy.
Fatto la prima volta, si scrive un bello script che automatizza il tutto.

Ho risolto in questo modo:
partendo dall'immagine del 6.0.8 (800k) prelevata dal sito Apple e 
funzionante, ho scaricato ResEdit ed ho aperto l'immagine senza resource 
fork.
ResEdit ne ha creata una nuova, e lì ho duplicato i valori presenti 
nell'altra immagine, soprattutto il campo "Creator".
In questo modo, le immagini 1440k le posso gestire da PC/Linux, quelle da 
800k in un Mac con ResEdit.
Manca, adesso, solo un compressore che generi un .sea o .hqx sul Mac, per 
ricreare le immagini complete.



Dimenticavo ...
L'operazione ha successo purché l'immagine sia, in ogni caso, di tipo 
noto.
Ho appena incontrato un paio di immagini dalla dimensione sospetta, 
819200 anziché 838484.
Infatti, le immagini mancano dell'header e sono più corte. :(
Giustamente, non sono Disk Copy.
Che altro c'era e c'è in giro per Mac, oltre Disk Copy ? Illuminatemi :)
Nonostante tutte le modifiche, Disk Copy ha detto che non è roba sua...