Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #1194 > unrolled thread

Building a multiboot system!

Back to article view | Back to comp.os.msdos.programmer

Contents

  Building a multiboot system! Patrick Rockwell <prockwell@thegrid.net> - 2013-12-18 20:25 -0800
    Re: Building a multiboot system! JJ <duh@nah.meh> - 2013-12-19 13:01 +0700
      Re: Building a multiboot system! Patrick Rockwell <prockwell@thegrid.net> - 2013-12-19 17:37 -0800
        Re: Building a multiboot system! "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-20 02:16 -0500
          Re: Building a multiboot system! "Stanley Daniel de Liver" <admin@127.0.0.1> - 2013-12-20 11:30 +0000
            Re: Building a multiboot system! dg1261 <dgREMOVE-THIS1261@cs.com> - 2013-12-21 00:59 +0000
              Re: Building a multiboot system! "James Harris" <james.harris.1@gmail.com> - 2013-12-21 12:18 +0000
                Re: Building a multiboot system! "Stanley Daniel de Liver" <admin@127.0.0.1> - 2013-12-21 15:11 +0000
                Re: Building a multiboot system! "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-21 17:35 -0500
                  Re: Building a multiboot system! "James Harris" <james.harris.1@gmail.com> - 2013-12-21 23:33 +0000
              Re: Building a multiboot system! "Stanley Daniel de Liver" <admin@127.0.0.1> - 2013-12-21 14:47 +0000
          Re: Building a multiboot system! Ross Ridge <rridge@csclub.uwaterloo.ca> - 2013-12-22 15:31 -0500
    Re: Building a multiboot system! dg1261 <dgREMOVE-THIS1261@cs.com> - 2013-12-19 11:29 +0000
      Re: Building a multiboot system! Harry Potter <rose.joseph12@yahoo.com> - 2013-12-19 08:10 -0800
        Re: Building a multiboot system! Patrick Rockwell <prockwell@thegrid.net> - 2013-12-19 13:37 -0800
        Re: Building a multiboot system! dg1261 <dgREMOVE-THIS1261@cs.com> - 2013-12-20 06:22 +0000
          Re: Building a multiboot system! "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-20 02:16 -0500
            Re: Building a multiboot system! "Stanley Daniel de Liver" <admin@127.0.0.1> - 2013-12-20 11:15 +0000
            Re: Building a multiboot system! dg1261 <dgREMOVE-THIS1261@cs.com> - 2013-12-21 00:56 +0000
              Re: Building a multiboot system! "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-21 01:51 -0500
                Re: Building a multiboot system! dg1261 <dgREMOVE-THIS1261@cs.com> - 2013-12-21 08:54 +0000
                  Re: Building a multiboot system! "James Harris" <james.harris.1@gmail.com> - 2013-12-21 12:26 +0000
                Re: Building a multiboot system! Steph <pas.de.mail@serveur.invalid> - 2013-12-21 15:11 +0000
      Re: Building a multiboot system! Patrick Rockwell <prockwell@thegrid.net> - 2014-02-07 14:15 -0800
        Re: Building a multiboot system! dg1261 <dgREMOVE-THIS1261@cs.com> - 2014-02-08 09:41 +0000
    Re: Building a multiboot system! miepbart@gmail.com - 2014-08-17 00:02 -0700

Page 2 of 2 — ← Prev page 1 [2]

#1211

"Rod Pemberton" <dont_use_email@xnohavenotit.cnm> wrote in 
news:op.w8fjz9wg5zc71u@localhost:

>> the FATs would need to be expanded so they have
>> room to record the extra clusters.
> 
> ... "has" to be adjusted or "may need" to be adjusted?
> 
> I would think both the BPB and FAT sizes would be valid for a
> certain range of partition sizes.  So, if the change is outside
> that range, above or below, then they'd have to be adjusted.
> If within, they shouldn't.  Assuming they're already set to the
> maximums, it's even more likely they shouldn't need adjustment.

IME, FATs have always occupied no more sectors than the absolute minimum 
necessary to represent the capacity of the partition.  So if you increase 
the size of the partition the FATs will always have to be increased.  
Larger FATs will always entail adding at least one more sector to each 
FAT if more than 512/2 clusters are being added (since each cluster entry 
takes two bytes).  On a medium-sized FAT16 partition with clusters of 
4KB, 256 clusters are only 1MB, so increasing the partition size by more 
than 1MB will always require adding more sectors for the FATs.


>  From the RBIL BPB and extended BPB, I only see two fields that
> would appear to need adjustment sometimes: "sectors per cluster"
> and "sectors per FAT".

...which bring up another point: if a partition resize is drastic enough 
that it also requires a change in the cluster size (e.g., from 2KB 
clusters to 4KB or 8KB), that will additionally require rewriting every 
single FAT entry, as well as moving any occupied data sector that doesn't 
line up properly with the new cluster boundaries.

[toc] | [prev] | [next] | [standalone]

#1213

"dg1261" <dgREMOVE-THIS1261@cs.com> wrote in message 
news:XnsA29D9450C299dgREMOVETHIS1261csco@78.46.70.116...
> "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> wrote in
> news:op.w8fjz9wg5zc71u@localhost:
>
>>> the FATs would need to be expanded so they have
>>> room to record the extra clusters.
>>
>> ... "has" to be adjusted or "may need" to be adjusted?
>>
>> I would think both the BPB and FAT sizes would be valid for a
>> certain range of partition sizes.  So, if the change is outside
>> that range, above or below, then they'd have to be adjusted.
>> If within, they shouldn't.  Assuming they're already set to the
>> maximums, it's even more likely they shouldn't need adjustment.
>
> IME, FATs have always occupied no more sectors than the absolute minimum
> necessary to represent the capacity of the partition.  So if you increase
> the size of the partition the FATs will always have to be increased.

The basic FAT type is officially based on the number of clusters, not the 
number of sectors. Microsoft OSes use their own official calculation. They 
explain the details in a document called fatgen103 - copies abound.

> Larger FATs will always entail adding at least one more sector to each
> FAT if more than 512/2 clusters are being added (since each cluster entry
> takes two bytes).  On a medium-sized FAT16 partition with clusters of
> 4KB, 256 clusters are only 1MB, so increasing the partition size by more
> than 1MB will always require adding more sectors for the FATs.
>
>
>>  From the RBIL BPB and extended BPB, I only see two fields that
>> would appear to need adjustment sometimes: "sectors per cluster"
>> and "sectors per FAT".
>
> ...which bring up another point: if a partition resize is drastic enough
> that it also requires a change in the cluster size (e.g., from 2KB
> clusters to 4KB or 8KB), that will additionally require rewriting every
> single FAT entry, as well as moving any occupied data sector that doesn't
> line up properly with the new cluster boundaries.

One more field may need adjustment: if the location of the partition changes 
a field needs to be updated. It might be called Reserved Sectors or 
something like that but is a field in the BPB which says where the FAT 
partition starts on the disk or, equivalently, how many sectors precede it.

James

[toc] | [prev] | [next] | [standalone]

#1215

"Rod Pemberton" wrote :

>> There's more to it than that.  The boot parameter block (BPB)
 
> That's a common mistake, it's:
>   BIOS Parameter Block

Correct, and for being pedantic, il should be stressed that "BIOS" as in 
BPB is NOT a reference to what we have come to be used to calling 'the' 
BIOS, i.e. the (IBM) PC-BIOS, but instead it refers to the "BIOS" 
component of (QDOS, PCDOS, MSDOS) - i.e. the basic I/O adaptation layer 
comprising the system file variously called BIOS.SYS , IO.SYS, IBMBIO.SYS 
... in as many incarnations.

Happy X-mas or whatever you are going to celebrate...


-- 
Steph

[toc] | [prev] | [next] | [standalone]

#1276

On Thursday, December 19, 2013 3:29:31 AM UTC-8, dg1261 wrote:
> Patrick Rockwell <prockwell@thegrid.net> wrote in
> 
> news:bb6443dc-adbc-4fa6-8b9f-f8855b916e9a@googlegroups.com: 
> 
> 
> 
> Wow, I gave up on Vcom System Commander more than 10 years ago!  (But I 
> 
> really liked it before then! <g>)
> 
> 
> 
> In the past 10 years I've tested a lot of boot managers but have whittled 
> 
> my recommendations down to just two: Terabyte Unlimited's "Boot It Bare 
> 
> Metal" (aka, BIBM) and XOSL.  These are the only two I ever bother 
> 
> recommending anymore.
> 
> 
> 
> BIBM is simply the best boot manager I've ever come across, and comes 
> 
> with a built-in partition manager and cloning/imaging tool--three tools 
> 
> in one.  It's $40 shareware and a relative bargain for three first-rate 
> 
> utilities.  It's got a fully functional free trial period, so you can try 
> 
> it out (really, not just a few limited functions) before deciding if you 
> 
> want to pay for it.
> 
> 
> 
> XOSL is the best free boot manager, so is what I recommend to people for 
> 
> whom $40 is still too much.  Its GUI is much easier to configure and use 
> 
> than grub or lilo.  It still multiboots most OSs--even Win8--just fine, 
> 
> even though development ceased 10 years ago.  (A MBR is still a MBR, 
> 

So, even when new OS's come out, it should be able to handle them? 

> after all, so it hasn't really needed any changes.)
> 
> 
> 
> If you're building a multiboot system you may find some helpful insights 
> 
> from my webpage at www.goodells.net/multiboot.  The tools have changed 
> 
> over the years, but I still use the same basic methodology when building 
> 
> multiboot systems today.
> 
> 
> 
> Note all of the above considers MBR disks only.  I haven't setup nor 
> 
> explored multibooting GPT disks.
> 



Dan, I bookmarked your site.  Thanks.

So, if I use BIBM, I can make a data partition that can be seen and accesed for read/write by Any OS that I boot from? So that if I have an OS which can't use the modem,
I just boot an OS that can and then download a file to
the data partition, and move it from there to any OS partition that I desire? Thanks again.

[toc] | [prev] | [next] | [standalone]

#1277

Patrick Rockwell <prockwell@thegrid.net> wrote in
news:892fa0c5-947d-49b8-8c59-b5807287dc29@googlegroups.com: 

>> It still multiboots most OSs--even Win8--just fine, even though 
>> development ceased 10 years ago.  (A MBR is still a MBR, after 
>> all, so it hasn't really needed any changes.)
>> 
> 
> So, even when new OS's come out, it should be able to handle them?

Yes, as long as you're using a MBR disk.  The MBR simply loads the boot 
sector of the "active" partition designated by your partition table.  
Like a true boot manager (which doesn't include Microsoft's kludgy 
boot.ini for XP or BCD method for Vista/7/8), XOSL simply allows you to 
control which partition you want to make "active" for that particular 
session.  XOSL doesn't need to know what OS is on the partition, it just 
launches it and assumes the partition's boot sector put there when the OS 
was installed will know what to do.  I have used XOSL to multiboot Win7 
and 8, even though XOSL has no idea what those OS's are.

That said, it's important to qualify what you mean by, "when new OS's 
come out."  By default, when installed on a blank (unpartitioned) hard 
disk, Win8 will create GPT partitions, not MBR partitions.  XOSL does not 
understand GPT partitions, so is of no use on such a disk.  But that's a 
MBR-vs-GPT issue, not an issue with Win8, per se.  Win8 can be installed 
on either a MBR partition or a GPT partition, but you can only use XOSL 
with Win8 if it is in a MBR partition.  All OEM Win8 systems I have seen 
come from the factory with GPT partitions, so if you want to multiboot 
Win8 with XOSL you'll have to convert the GPT partitions to MBR--or 
better, start over with a clean install of Win8 using MBR partitions.



> So, if I use BIBM, I can make a data partition that can be seen and
> accesed for read/write by Any OS that I boot from? So that if I have
> an OS which can't use the modem, I just boot an OS that can and then
> download a file to the data partition, and move it from there to any
> OS partition that I desire?

Yes.  That's how I setup all my multiboot systems.

[toc] | [prev] | [next] | [standalone]

#1515

Op donderdag 19 december 2013 05:25:23 UTC+1 schreef Patrick Rockwell:
> I'm planning to have a multi boot computer with as many operating systems as I can find. I'd like Dos 6.22
> 
> to be one of them. My old PC is in a closet and I did put an earlier version of system commander on it.
> 
> 
> 
> I did call a local computer store and they said that they
> 
> Could custom build a system for me and port all my dos stuff onto the new computer.
> 
> 
> 
> One problem that I have is that system commander is
> 
> no longer made or supported and so, sooner or later
> 
> there will be a new OS that the latest version can't handle. There are other alternatives such as lilo or grub though.
> 
> 
> 
> I was thinking of using grub. Now here is my dilemma.
> 
> I've heard that you can download usb drivers for dos.!
> 
> Does grub have the ability to let you see the dos partition from whatever windows you've booted? I ask
> 
> this because I heard that the latest version of system commander wouldn't even work unless you hid the OS's from each other. Does anyone know? I don't think
> 
> I can just download it into my dos partition because
> 
> I don't think there are any serial port modems anymore.  Are there any serial to usb cables?
> 
> 
> 
> If you have an answer or knowledge about multiboot
> 
> alternatives to system commander, please reply, and
> 
> thanks in advance.

If you have a win7 or win8 box try easybcd for your OS selection , ik will allow you to "see" the other partitions 

regards , bart

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.msdos.programmer

csiph-web