Installation of floppy controller card runs into gtk-configure problem

It seems that apt-get runs into a regex interference:

> george@george-DA237A-ABA-6430NX-NA910:/etc$ sudo apt-get install gtk-1.2
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Note, selecting 'libaiksaurusgtk-1.2-0' for regex 'gtk-1.2'
> Note, selecting 'libaiksaurusgtk-1.2-0c2a' for regex 'gtk-1.2'
> Note, selecting 'libaiksaurusgtk-1.2-dev' for regex 'gtk-1.2'
> libaiksaurusgtk-1.2-0c2a is already the newest version.
> libaiksaurusgtk-1.2-dev is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.

Result: /etc/gtk-2.0 & /etc/gtk-3.0 exist, but not /etc/gtk-1.2

How do I force apt-get to look for and download gtk-1.2 ?

Why would a driver require a graphical toolkit? You should search for a solution that does not require installing a version of GTK+ that is 16 years old: installing GTK+-1.2 looks harder than your original problem!

Maybe the driver you found can be compiled without GTK+-1.2 (which, I guess, is a dependence of some kind of graphical configuration utility)...

Magic Banana inquired:
> Why would a driver require a graphical toolkit?

Funny you should ask. DeviceSide.com suggests both a command-line method of accessing the 5-1/4 inch floppy (presently held up by my difficulty in translating "usb-2" in dmesg results into a device in the /dev directory for the essential purpose of mounting the floppy file system) and a gui method. The compilation of the floppy driver requires that I "sudo apt-get install" gcdc, make, binutils, libusb-dev, and gtk-1.2. It's that last one that's blocking things right now. I don't even know if gtk-1.2 contains gtk-config. ... and that's what is blocking that alternative gui method of reading the floppies.

Legacy floppies seem to require legacy code, it would seem.

I could have plugged this board into a Win98 setup, for which the drivers don't need a compile step, but this seemed like a good opportunity for testing the compile-from-code waters.

I can write new 5-1/4 inch floppies from my PCXT, which still exists somewhere in my household, but that PC can't write 3-1/4 inch floppies and of course has no idea what a CDROM is.

I'm trying to make a lasting repository of stuff I wrote in the years after 1985 and before *indows 3.11.

I only recently threw away a hundred pounds of IBM cards & Fortran programs from the 60's. I still have the line-printed hard copies.

Solved.

It appears that the following packages were also needed in addition to the ones suggested in the instructions by DeviceSide.com supplied with the accompanying CDROM: libusb-dev & libgtk2.0-dev,
which I obtained easily with "sudo apt-get install [filename]"

Then I found out, strictly by trial & error, that installing the software in a partition formatted fat32 isn't a good idea. I also found out that it's better not to use "sudo make" when compiling the drivers, but to keep my own identity instead. Once everything was installed in a proper linux-formatted partition, the Device Side Data package reads 5-1/4 inch floppy disks quite nicely. Out of thirty disks read so far, only a very old "flight simulator" disk could not be read. Of the other 29 disks, only a few files could not be opened, but some of those had errors on both the first floppy and a second, backup floppy written at the same time.

The files are initially copied as "disk000x.img" images and have to be mounted suitably with a command like this: "sudo mount -t msdos ~/Disk0NNN.img ~/floppies/diskname -o loop" after creating a suitable mounting point with "sudo mkdir ~/floppies/diskname"

Eventually one runs out of loop devices, so additional ones can be created one at a time with the command: "sudo mknod -m 660 /dev/loopN b 7 N" where N is the next-numbered loop device needed. It also helps to umnount the "diskname" directories once their contents have been saved; this frees up their loop devices.

Postscript: As to the question of durability: Some of these floppies carry data that's thirty years old, written about fifteen years ago from the original PCXT hard drive. Files that can be read come out perfectly. Disks that can be read may have some bad data but one can always examine the 360KB disk images by more sophisticated means, I suppose.

Followup:

The process of extracting data from those old floppies has settled into a workable routine.

First, I start DeviceSideData's terminal interface, put a floppy disk into the 5-1/4 inch drive, and capture an image of the disk into an appropriate directory.

Then I create a mount point.

Then I mount the image as a loop device as previously described (when I run out of loop devices, I either have to unmount one that was previously analyzed or add some more as also descried above).

That gives me the contents of the floppy as a list of files, as for any other directory.

Now comes the good part: The only way I could find for opening DisplayWrite 3 files is with Adobe FrameMaker (No endorsement implied except that I got it on that famous internet auction site) which I first applied laboriously with a *indows 'puter, but which today I installed in the Trisquel 7 'puter that has the DeviceSideData floppy controller by using Wine, first to set up the application and then to start it - two steps !). Now it's in the list of app's under Wine.

The only complication I found with FrameMaker is that it doesn't understand the concept of separately mounted disk drives, so I have to move the DW3 files to Trisquel's "Documents" folder, which is a trivial step.

FrameMaker will then open them as DisplayWrite 5 files, which is close enough for this engineer.