[Offer] IBM Windows 3.1

[os2fan2]

A copy of IBM Windows 3.1 mastered from the original diskettes.

Diskette 4 is recreated by adding files to the Windows diskette 4, but the original wreckage is available for inspection.

Printer drivers on diskettes 6 and 7 were not in the purchaced set.

Download at https://drive.google.com/drive/folders/ ... sp=sharing

Sample diskette. All five in the file.

Wendy

[YourAverageJoe]

Are you sure that's the link? I don't see floppy image files on there

[os2fan2]

It is the link. But i thought it would upload to the open folder, rather than the base.

I fixed it up now. It's called IBMWIN31.ZIP, and is signed by me.

[Lucas Brooks]

Even though disk 4 is not in a good shape, most critical information survived and it should be possible to restore it manually.

Without knowing the location of damaged sectors, I will have to go through the dump sector by sector and compare each file. Not sure why some broken parts of the files got replaced with spaces (20h).

[os2fan2]

Looking at the order of the fat, I suspect to delete also mouse.sy_ and add it back into the image. That would create a new FAT chain. It's listed last in the fat. There are 133 sectors broken, in these files:

Code: Select all

APPS.IN_       DRIVERS.CP_    MAIN.CP_       MIDIMAP.DR_    PROGMAN.EX_
CARDFILE.HL_   DRWATSON.EX_   MARBLE.BM_     MMSYSTEM.DL_   RAMDRIVE.SY_
CHARMAP.HL_    DSWAP.EX_      MCICDA.DR_     MOUSEHP.CO_    RECORDER.HL_
CLIPBRD.HL_    EMM386.EX_     MCISEQ.DR_     MOUSEHP.SY_    SHELL.DL_
COMMDLG.DL_    HONEY.BM_      MCIWAVE.DR_    MPU401.DR_     WINFILE.HL_
DDEML.DL_      LEAVES.BM_     MIDIMAP.CF_    MSD.EXE

These files are reported as having different crc's than the original.

The bulk of the broken sectors are in the low cylinders, although there is a bad sector in the high range. (based on the graphic of recdsk.).

I suspect using a file-compare of the fats of a Windows diskette 4, and this one, since it appears that that they first deleted mouse.co_ and mouse.sy_ to make room for mouse.com, but restored mouse.co_ (compressed, as per the reconstructed one), and then mouse.sy_.

It would had been highly unusual for IBM to have used an msdos40 boot sector, when the usual fare was to use IBMDOS 5 boot sectors.

[Lucas Brooks]

I just restored the disk from what you have provided and is it possible to take a look at it? Download here. Everything done in a hex editor and the image should be original but I make no guarantee.

It would be helpful to provide a screenshot of bad sectors so it is possible to verify the fixed image. The "high range" bad sector contains parts of WINFILE.HLP I think. Some FAT sectors died but FAT is easy to fix so image header is in a good shape. I checked CRCs of files on my fixed disk and all files matches the old IBM OEM folder dump.

[os2fan2]

Here is the damage list for anyone interested.

Code: Select all

apps.in_      10E0-11FF  3510-35FF
cardfile.hl_  0740-07FF  2B40-2BFF
charmap.hl_   03D0=3DFF
clipbrd.hl_   0120-01FF
commdlg.dl_   0710-07FF  0BC0-0BFF  2B20-2BFF  2FC0-2FFF  4F40-4FFF
              53B0-53FF  7340-73FF  77C0-77CF  9A00-9BFF  9C40-9DFF
              9F80-9FFF  BE00-BFFF  C390-C3FF
ddeml.dl_     1A00-1BFF  1F80-1FFF  3E00-3FFF
drivers.cp_   0800-09FF  2C00-2DFF  5000-51FF
drwatson.ex_  2000-21FF  4400-45FF  47C0-47FF
dswap.ex_     1E00-1FFF  21C0-21FF  4200-43FF  4590-45FF
emm386.ex_    1C00-1DFF  1F90-1FFF  4000-41FF  4390-43FF  6400-65FF
              6790-67FF  8800*8BFF  8C49-8DFF  AC00*AFFF
honey.bm_     0000-0158 (all of the file)
leaves.bm_    01A0-01FF
main.cp_      0E00-0FFF  11A0-11FF  35A0-35FF  59B0-59FF  7D90-7DFF
              A1A0-A1FF  C590-C9FF  E990-EBFF  10D80-10DFF  10F80-10FFF
              13190-131FF  13390-133F0 15570-155FF 15770*159FF
marble.bm_    1B80-1BFF  1D80-1DF1 (eof)
mcidea.dr_    0000-01FF
mciseq.dr_    0170*03FF  2360-23FF 2560*27FF
mciwave.dr_   0750-07FF  0980-09FF 2B20-2BFF  2D80*2FFF
midimap.cf_   0B20-0BFF  0D90*0FFF
midimap.dr_   1120-11FF  1380*15FF  3550-35FF 5960-59FF 5B90-5BFF 7D70-7DFF
mousehp.co_   1B00-1BFF  1D50*1FFF  3F00-3FFF 4140*43FF
mousehp.sy_   1110-11FF  1350*15FF  34E0-35FF 3730*39FF
mpu401.dr_    06D0-07FF  0910*0BFF
msd.exe       01560-015FF  01790*019FF  03960-039FF  03B80*03DFF  05D90-05DFF
              08190-081FF  0A590-0A5FF  0C910-0C9FF  0ED80-0EDFF  11060-1114F
              11170-111FF  13570-135FF  13790-137FF  15970-159FF  15B90-15BFF
              1A180-1A1FF
progman.ex_   B800*DE56 (eof)  extensive damage.
ramdrive.sy_  200-EB4  (eof)  extensive damage,
recorder.hl_  file shown as zero
regedit.ex_   file shown as zero
regedit.hl_   file shown as zero
shell.dl_     0200*6D40 (eof)  extensive damage.
smartdrv.ex_  file shown as zero
winfile.hl_   1CF0-1FCF [two bits, bitrot?]

[os2fan2]

The repair looks good. It matches what is already known of the disk.

It may have something to do with the recovery program. Some sectors look faulty, but an image of it was preserved by floprec, while other sectors were 'not found', and floprec placed spaces 0x20 there to keep the spacing. That's how I read. It's too unnatural for sectors parts to be mangled, but complete sectors come to spaces, unless it's because it could not find a sector-header.

progman.exe, ramdrive.sys, and shell.dll had all sectors read, but were corrupt. The four files recorder.dl_, regedit.ex_, regedit.hlp_ and smartdrv.ex_ were recorded as 'zero-size' in recovery.

I suspect that why i got an array of 0x20 for honey.bmp, is that winimage read the fat, and copied the required location of bytes from the image, the actual sector should have been entirely spaced out.

[qazmko1029]

Actually there's another copy I found on the Internet, it has just MOUSE.CO_ in disk4 different compared with this copy.
https://mega.nz/file/wlhkgTpT#dhYDgF8iS ... 56OcKOqOeI

[os2fan2]

It has the correct boot sectors. Will run it through the rollers.

The result is that the set matches the IBM set, with the exception of mouse.co_, which is the microsoft version, rather than the ibm version. The balance of the disks match the IBM set. The directory shows no deleted files, and the mouse.co_ and mouse.sy_ at the end. The microsoft release has these files in alpha order in the set, so this is a particular marker.

The file can be corrected with winimage, but then you have to drag mouse.sy_ into the image to correct it. The files and the root directory then agree with the wreckage version.