Linked by Thom Holwerda on Fri 4th Jan 2008 20:35 UTC, submitted by koki
Thread beginning with comment 294466
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
Linked by Thom Holwerda on 05/16/13 21:41 UTC
Linked by Thom Holwerda on 05/16/13 17:04 UTC
Linked by Thom Holwerda on 05/16/13 13:17 UTC
Linked by Thom Holwerda on 05/16/13 12:06 UTC
More News »
Sponsored Links



Member since:
2006-05-26
ISO does NOT contain a FAT32/FAT16 compliant filesystem anymore than it contains a Mac HFS/HFS+ compliant filesystem: ISO 9660 (perhaps that's what you're doing a shortcut for) actually, to some extent, supports extended attributes, and there are extensions to ISO 9660 (Rockridge extensions) that support longer filenames than the old lowest common denominator mutation, file version numbers, etc. but it isn't enough of extended attribute support for the richness that BFS supports. Sure, you could do the wrapper, but why, when the El Torito boot specification exists for x86 machines, and works well? There's no reason not to use it, and to use some bastardized ISO 9660 extension. Hybrid CD's have been made for longer than BeOS existed: I distinctly remember such titles going through the premastering department I worked in, that were commonly combination of standard PC ISO 9660 titles with Mac OS volume images on the same disc.
Booting BeOS from DOS definitely doesn't at all work the way you would seem to imply: it can most accurately be thought of as using a BIOS boot loader to load a bootsector from a file, and has absolutely nothing to do with being able to read BeOS formatted images and interpret them from within DOS. From there, it was a translation layer of BeOS itself that was essentially using a FAT16/FAT32 abstraction layer below the BFS driver level such that the BFS driver when it requested a block, got back a relative offset block returned from a lower level FAT filesystem driver.
Until Haiku is out of the pre-alpha state where it can't (at this time) build itself due to an incomplete VM subsystem, it's probably wisest to leave it at a state where the common user like yourself won't find it easy to install, but whine when it doesn't do this, that, or the other thing, etc. because if it's too easy to install, those without enough motivation and knowledge and diligence will only whine, as opposed to providing useful bug reports. Whether that theory is most correct entirely depends on the users, but at this point, with the holes that still need to be plugged, if you can't install it as-is, you're honestly not technically competent enough to be of any real value in the development and testing.