OS/2, eCS & ArcaOS - Technical > Utilities

XDF disk extractor

<< < (18/19) > >>

Valery Sedletski:
2Gregg Young: Oh, nice. So, you added the "WINDOW" keyword to wrc.exe? (Or it's Steven's fixes?)
IIRC, the version from OW 1.9 didn't supported adding resources to OS/2 binaries during the linking,
though, it did support that for windows binaries. But supported adding resources to existing OS/2
binaries (after they are linked). So, it's good to know if newer versions of wrc from OW 2.0 support
adding resources to OS/2 binaries during linking?

Gregg Young:

--- Quote from: Valery Sedletski on November 06, 2018, 03:49:21 pm ---2Gregg Young: Oh, nice. So, you added the "WINDOW" keyword to wrc.exe? (Or it's Steven's fixes?)
IIRC, the version from OW 1.9 didn't supported adding resources to OS/2 binaries during the linking,
though, it did support that for windows binaries. But supported adding resources to existing OS/2
binaries (after they are linked). So, it's good to know if newer versions of wrc from OW 2.0 support
adding resources to OS/2 binaries during linking?

--- End quote ---

2Valery Sedletski I added the "WINDOW" support. Steven did the high memory stuff for the linker. I also fixed some issues with wipfc.exe which is in the netlabs version but should also be in Frank's snapshot version since all the code was committed.

You said that the snapshot 2.0 linker worked for vbox. Did you use wlink? I didn't see wl in the package. I built wl from the latest code if you would like to try it I can send it to you. Contact me at ygk at qwest dot net.

Valery Sedletski:
2Gregg Young: Is not wl.exe just a renamed wlink.exe? The only difference, it seems, is that wl.exe is built statically. wlink.exe is linked to wlinkd.dll. And wrc.exe from Watcom is linked with wrcd.dll. Wrc.exe from yum repository is built statically too. I just took wlink.exe from OW 2.0 (Frank's build) and renamed it to wl.exe, and relpaced the previous version of wl.exe with it. So yes, I built VBox successfully with these versions of wlink.exe and wrc.exe from Frank's site. The only parts built with OW 1.9 are BIOS and Video BIOS ROMs. They fail to link with wl.exe from OW 2.0. The error from linker is:


--- Quote ---Error! E2011: file L:\src\vbox\prev\out\os2.x86\release\obj\VBoxPcBios32\VBoxPcBios32.lib(L:\src\vbox\prev\src\VBox\Devices\PC\BIOS\pci32.c): invalid object file attribute

--- End quote ---

RickCHodgin:

--- Quote from: Rick C. Hodgin on November 05, 2018, 02:11:45 pm ---I don't have an easy way right now to do that.  My desktop machine blew out a capacitor (!!) this weekend.  Scared the whole family.  Popped.  Caught fire for a few seconds.  Really freaky.  Probably the dangers of using a 10+ year old desktop machine.  But, I'll try to get it setup so I can check.  I am able to borrow a desktop machine from my work and will set it up there.
--- End quote ---

As of last night, I have my developer environment restored.  Someone at work gave me a 2004 desktop machibe with a 1.5 GHz Athlon XP. :-)  It's working wonderfully.  I have OS/2 4.52 installed, 106 kernel, IBM PC DOS 7, all my old folders and developer tools.

Need to get a green monochrome monitor now.

RickCHodgin:
The XDF disk extractor has been posted on Hobbes (xdflibsf.zip):
http://hobbes.nmsu.edu/h-browse.php?dir=/pub/os2/util/disk

Source code:
http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/es2

I also realized something today.  The inner-most track on a standard 3.5" floppy disk is about 6.5" in circumference, going out to the outer-most track being about 20.5" in circumference, resulting in about 1096 inches of continuous double-sided data.  A standard 3.5" 1.44MB floppy disk has 12,500 bytes per track per side unformatted.  Formatting to 1.44MB results in 18*512 = 9216 bytes per track per side, a slack of about 182(!!) bytes per sector.  XDF gained its larger space savings by reclaiming 14 of those 182 byte blocks by only using four sectors (one 8KB, one 2KB, one 1KB, and one 512B), or about 3650 bytes per inch.

If, however, the floppy drive itself were modified and used a spiral track like a CD/DVD, and employed variable RPM and kept the sector length consistent throughout the disk to that seen in the inner-most track, and switched to 8KB sectors, it would result in 1096 inches of 3650 bytes per inch with formatting overhead ... it would be about 3.75MB per disk formatted on the same 1.44MB floppies we used today.  The only variable is the speed it rotates keeping the sector length the same as that found on the inner tracks, but throughout the entire disk, and using 470 8KB sectors to reclaim the extra wasted space by sector markers.

I wonder why nobody ever created a drive like that?  Even if they used a wider format and only got 3MB per disk, it would still be better than even the 2.88MB disks they had, and all still using the same density media as the 1.44MB floppies.  It would've been a little slower to access, but I don't think people would've minded because it would've held that much more, requiring 1/2 to 1/3rd fewer disk changes during installation.  Imagine, OS/2 Warp 4 from IBM could've booted off one floppy disk rather than three.

OS/2 could've shipped on 1/3rd to 1/2 the number of floppies for machines with floppy drive support for a spiral track mode and variable RPM.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version