A Windows 98 & ME forum. Win98banter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » Win98banter forum » Windows 98 » Disk Drives
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

Problem with accessing a partition



 
 
Thread Tools Display Modes
  #41  
Old May 31st 10, 12:23 AM posted to microsoft.public.win98.disks.general
Andrew[_2_]
External Usenet User
 
Posts: 35
Default Problem with accessing a partition


Thanks a lot for your interesting comments and helpful ideas.
I'm sorry to bother you again with my questions, hopefully last time, but
this might lead to a breakthrough.

1. These are strange values. The hidden sector values suggest that the data is nowhere near the boot record. This could indicate how Partition Magic moves data when you resize a partition.


My logical partitions D: and E: are not system partitions. They are so to
say chained within my Extended partition. Can these strange values mean that
the boot record for E: is located just before the beginning of E: and that
these values reflect their relative distance from the beginning of the
Extended partition? Is such a description used for logical partitions?

2. As far as I know each partition has to be contiguous but the volumes in the extended partition can have spare areas between them and don't have to be in ascending order by disk address.


This is a very important info that I was unaware of. Let me return here to
the PM resizing procedure.
To resize my WinXP(* partition located in the following sequence of
partitions: [C: Win98, (* WinXP, D:, E:, Unallocated] by 7GB, PM had to go
through 5 'elementary' steps in the order displayed below:
a. Resize Extended (* by 7GB (taken from Unallocated)
b. Move E: up by 7GB
c. Move D: up by 7GB
d. Resize Extended (* down by 7GB
e. Resize WinXP (* by 7GB
Are these details somehow useful for confirmation of your idea about these
strange values?

3. It is possible to have Win98 and XP on a disk and select the one you want by changing the boot flag using something like FDISK.


You're completely right. One can easily do it, e.g. in the ptedit32.exe, by
changing the flags. 'Boot flags' 00 and 80 stand for not bootable and
bootable, and 'type flags' 0C and 1C stand for FAT32X and Hidden Fat32X
partitions, respectively. PM has also 2 additional utilities (BootDisk) for
activation and/or deactivation of a primary partition. One can easily change
them.

Regards,
Andrew


"Steven Saunderson" wrote:

On Sat, 29 May 2010 13:23:01 -0700, Andrew
wrote:

2. Just to be on a safe side, I performed the suggested by you test. This
time, I restarted the computer from Win98 to DOS and then ran pedit.exe from
a floppy). The results were the same as before.


Thanks for trying.

4. Some data listed in the Boot Record Table for the partition E: in
ptedit.exe seem to me strange, namely
- Hidden Sectors: 117852903
- First Cluster of Root: 141346
These are rather big numbers, whereas for D: they a 63 and 2, respectively.


These are strange values. The hidden sectors value suggests that the
data is nowhere near the boot record. This could indicate how Partition
Magic moves data when you resize a partition.

5. Finally, in my Extended Partition Table, there are 2 non-zero entries in
the Type column: 0B describing my D: partition (I corrected it to 0C) and 05,
which describes an Extended Partition and not the ExtendedX one, which should
have 0F entry, as in the Partition Table at sector 0. I don't understand this
either and I didn't correct it.


The 0x05 is correct. The continuation entries are always 0x05 even when
the extended partition starts with a 0x0F code.

I'm rather lost here because I don't know anything about Partition
Magic. Assume that originally your disk had two primary partitions and
then your extended one with two volumes. When you increased the size of
the second primary partition perhaps PM made space by moving the D:
volume to after the E: volume and changing the links in the extended
partition to suit. It would be easier to move 11GB than 30GB. As far
as I know each partition has to be contiguous but the volumes in the
extended partition can have spare areas between them and don't have to
be in ascending order by disk address.

It's a double-edged sword. PM is very clever in that it can resize
partitions but it might be producing layouts that confuse things like
Win98. It should be possible to determine your disk layout by using
something like Ranish Partition Manager but changing things to help
Win98 might cause problems when you later use PM to resize a partition
or select the other O/S.

Hopefully someone with ideas or knowledge of PM will chip in here. I'm
hesitant to suggest further changes due to the risk of wrecking your
setup.

It is possible to have Win98 and XP on a disk and select the one you
want by changing the boot flag using something like FDISK. This used to
be common in the old days and I still do it on some PCs.

Cheers,
--
Steven
.

  #42  
Old May 31st 10, 03:59 AM posted to microsoft.public.win98.disks.general
Hot-text
External Usenet User
 
Posts: 1,026
Default Problem with accessing a partition

All Windows system put boots on C


"Andrew" wrote in message
news
Thanks a lot for your interesting comments and helpful ideas.
I'm sorry to bother you again with my questions, hopefully last time, but
this might lead to a breakthrough.

1. These are strange values. The hidden sector values suggest that the
data is nowhere near the boot record. This could indicate how Partition
Magic moves data when you resize a partition.


My logical partitions D: and E: are not system partitions. They are so to
say chained within my Extended partition. Can these strange values mean
that
the boot record for E: is located just before the beginning of E: and that
these values reflect their relative distance from the beginning of the
Extended partition? Is such a description used for logical partitions?

2. As far as I know each partition has to be contiguous but the volumes
in the extended partition can have spare areas between them and don't
have to be in ascending order by disk address.


This is a very important info that I was unaware of. Let me return here to
the PM resizing procedure.
To resize my WinXP(* partition located in the following sequence of
partitions: [C: Win98, (* WinXP, D:, E:, Unallocated] by 7GB, PM had to
go
through 5 'elementary' steps in the order displayed below:
a. Resize Extended (* by 7GB (taken from Unallocated)
b. Move E: up by 7GB
c. Move D: up by 7GB
d. Resize Extended (* down by 7GB
e. Resize WinXP (* by 7GB
Are these details somehow useful for confirmation of your idea about these
strange values?

3. It is possible to have Win98 and XP on a disk and select the one you
want by changing the boot flag using something like FDISK.


You're completely right. One can easily do it, e.g. in the ptedit32.exe,
by
changing the flags. 'Boot flags' 00 and 80 stand for not bootable and
bootable, and 'type flags' 0C and 1C stand for FAT32X and Hidden Fat32X
partitions, respectively. PM has also 2 additional utilities (BootDisk)
for
activation and/or deactivation of a primary partition. One can easily
change
them.

Regards,
Andrew


"Steven Saunderson" wrote:

On Sat, 29 May 2010 13:23:01 -0700, Andrew
wrote:

2. Just to be on a safe side, I performed the suggested by you test.
This
time, I restarted the computer from Win98 to DOS and then ran pedit.exe
from
a floppy). The results were the same as before.


Thanks for trying.

4. Some data listed in the Boot Record Table for the partition E: in
ptedit.exe seem to me strange, namely
- Hidden Sectors: 117852903
- First Cluster of Root: 141346
These are rather big numbers, whereas for D: they a 63 and 2,
respectively.


These are strange values. The hidden sectors value suggests that the
data is nowhere near the boot record. This could indicate how Partition
Magic moves data when you resize a partition.

5. Finally, in my Extended Partition Table, there are 2 non-zero
entries in
the Type column: 0B describing my D: partition (I corrected it to 0C)
and 05,
which describes an Extended Partition and not the ExtendedX one, which
should
have 0F entry, as in the Partition Table at sector 0. I don't
understand this
either and I didn't correct it.


The 0x05 is correct. The continuation entries are always 0x05 even when
the extended partition starts with a 0x0F code.

I'm rather lost here because I don't know anything about Partition
Magic. Assume that originally your disk had two primary partitions and
then your extended one with two volumes. When you increased the size of
the second primary partition perhaps PM made space by moving the D:
volume to after the E: volume and changing the links in the extended
partition to suit. It would be easier to move 11GB than 30GB. As far
as I know each partition has to be contiguous but the volumes in the
extended partition can have spare areas between them and don't have to
be in ascending order by disk address.

It's a double-edged sword. PM is very clever in that it can resize
partitions but it might be producing layouts that confuse things like
Win98. It should be possible to determine your disk layout by using
something like Ranish Partition Manager but changing things to help
Win98 might cause problems when you later use PM to resize a partition
or select the other O/S.

Hopefully someone with ideas or knowledge of PM will chip in here. I'm
hesitant to suggest further changes due to the risk of wrecking your
setup.

It is possible to have Win98 and XP on a disk and select the one you
want by changing the boot flag using something like FDISK. This used to
be common in the old days and I still do it on some PCs.

Cheers,
--
Steven
.

  #43  
Old May 31st 10, 03:59 AM posted to microsoft.public.win98.disks.general
Hot-text
External Usenet User
 
Posts: 1,026
Default Problem with accessing a partition

All Windows system put boots on C


"Andrew" wrote in message
news
Thanks a lot for your interesting comments and helpful ideas.
I'm sorry to bother you again with my questions, hopefully last time, but
this might lead to a breakthrough.

1. These are strange values. The hidden sector values suggest that the
data is nowhere near the boot record. This could indicate how Partition
Magic moves data when you resize a partition.


My logical partitions D: and E: are not system partitions. They are so to
say chained within my Extended partition. Can these strange values mean
that
the boot record for E: is located just before the beginning of E: and that
these values reflect their relative distance from the beginning of the
Extended partition? Is such a description used for logical partitions?

2. As far as I know each partition has to be contiguous but the volumes
in the extended partition can have spare areas between them and don't
have to be in ascending order by disk address.


This is a very important info that I was unaware of. Let me return here to
the PM resizing procedure.
To resize my WinXP(* partition located in the following sequence of
partitions: [C: Win98, (* WinXP, D:, E:, Unallocated] by 7GB, PM had to
go
through 5 'elementary' steps in the order displayed below:
a. Resize Extended (* by 7GB (taken from Unallocated)
b. Move E: up by 7GB
c. Move D: up by 7GB
d. Resize Extended (* down by 7GB
e. Resize WinXP (* by 7GB
Are these details somehow useful for confirmation of your idea about these
strange values?

3. It is possible to have Win98 and XP on a disk and select the one you
want by changing the boot flag using something like FDISK.


You're completely right. One can easily do it, e.g. in the ptedit32.exe,
by
changing the flags. 'Boot flags' 00 and 80 stand for not bootable and
bootable, and 'type flags' 0C and 1C stand for FAT32X and Hidden Fat32X
partitions, respectively. PM has also 2 additional utilities (BootDisk)
for
activation and/or deactivation of a primary partition. One can easily
change
them.

Regards,
Andrew


"Steven Saunderson" wrote:

On Sat, 29 May 2010 13:23:01 -0700, Andrew
wrote:

2. Just to be on a safe side, I performed the suggested by you test.
This
time, I restarted the computer from Win98 to DOS and then ran pedit.exe
from
a floppy). The results were the same as before.


Thanks for trying.

4. Some data listed in the Boot Record Table for the partition E: in
ptedit.exe seem to me strange, namely
- Hidden Sectors: 117852903
- First Cluster of Root: 141346
These are rather big numbers, whereas for D: they a 63 and 2,
respectively.


These are strange values. The hidden sectors value suggests that the
data is nowhere near the boot record. This could indicate how Partition
Magic moves data when you resize a partition.

5. Finally, in my Extended Partition Table, there are 2 non-zero
entries in
the Type column: 0B describing my D: partition (I corrected it to 0C)
and 05,
which describes an Extended Partition and not the ExtendedX one, which
should
have 0F entry, as in the Partition Table at sector 0. I don't
understand this
either and I didn't correct it.


The 0x05 is correct. The continuation entries are always 0x05 even when
the extended partition starts with a 0x0F code.

I'm rather lost here because I don't know anything about Partition
Magic. Assume that originally your disk had two primary partitions and
then your extended one with two volumes. When you increased the size of
the second primary partition perhaps PM made space by moving the D:
volume to after the E: volume and changing the links in the extended
partition to suit. It would be easier to move 11GB than 30GB. As far
as I know each partition has to be contiguous but the volumes in the
extended partition can have spare areas between them and don't have to
be in ascending order by disk address.

It's a double-edged sword. PM is very clever in that it can resize
partitions but it might be producing layouts that confuse things like
Win98. It should be possible to determine your disk layout by using
something like Ranish Partition Manager but changing things to help
Win98 might cause problems when you later use PM to resize a partition
or select the other O/S.

Hopefully someone with ideas or knowledge of PM will chip in here. I'm
hesitant to suggest further changes due to the risk of wrecking your
setup.

It is possible to have Win98 and XP on a disk and select the one you
want by changing the boot flag using something like FDISK. This used to
be common in the old days and I still do it on some PCs.

Cheers,
--
Steven
.

  #44  
Old May 31st 10, 06:04 AM posted to microsoft.public.win98.disks.general
Steven Saunderson
External Usenet User
 
Posts: 37
Default Problem with accessing a partition

On Sun, 30 May 2010 16:23:01 -0700, Andrew
wrote:

Thanks a lot for your interesting comments and helpful ideas.
I'm sorry to bother you again with my questions, hopefully last time, but
this might lead to a breakthrough.


It's not a bother but I'm sure you will be rather irked if your system
gets trashed due to my suggestions. If you want to see the details of
your disk layout can you download and run PartInfo.exe. It is a DOS
program and you can redirect the output to a file (e.g. "partinfo
my.lst").

You mentioned changing the boot indicator (00 or 80). Why not just
leave both your primary partitions as type 0x0C and change the boot
indicator when you want to change from XP to 98 or vice versa ? This is
how I do it and the only complication in your case would be if PM has
changed your MBR code. This is unlikely but I honestly don't know.

To resize my WinXP(* partition located in the following sequence of
partitions: [C: Win98, (* WinXP, D:, E:, Unallocated] by 7GB, PM had to go
through 5 'elementary' steps in the order displayed below:
a. Resize Extended (* by 7GB (taken from Unallocated)
b. Move E: up by 7GB
c. Move D: up by 7GB
d. Resize Extended (* down by 7GB
e. Resize WinXP (* by 7GB


The overlapping copies in steps b and c could be risky but I'm sure that
PM is doing them carefully so there is no data loss if a crash (e.g.
power loss) occurs. Step d sounds a bit risky because the LBA keys in
the EPBRs are relative to the extended partition. Step d would involve
changing each EPBR and then updating the MBR and I'm not sure how PM
could recover from a crash in this short step.

Are these details somehow useful for confirmation of your idea about these
strange values?


An authoritative reference for FAT32 is an MS document called
FATGEN103.PDF which should be easy to find. "Hidden sectors" is
generally the offset of the volume from the sector containing its
partition entry. So, for primary partitions it is the absolute key and
for logical partitions it is 63. But, I've seen exceptions and the
volumes are still accessible so maybe the value isn't used.

You mentioned a high "first cluster of root" after you'd resized E:.
This suggests that PM has created new directory records and switched
over to these lists once the data copying was complete.

Expanding your E: volume could have been a major task for PM. E: was
just under 8GB which means it could have 4kB clusters. When you
increase it to over about 8.3GB the cluster size has to be increased or
the cluster count will be too high for utilities such as DeFrag. How PM
can do this safely is beyond me.

I still haven't answered your question about D: being inaccessible in
Win98. Can you setup your disk so D: is inaccessible and then run
PartInfo to get the list ? One other source of info here is the MSFN
forums (search for Win98 IO.SYS).

Cheers,
--
Steven
  #45  
Old May 31st 10, 06:04 AM posted to microsoft.public.win98.disks.general
Steven Saunderson
External Usenet User
 
Posts: 37
Default Problem with accessing a partition

On Sun, 30 May 2010 16:23:01 -0700, Andrew
wrote:

Thanks a lot for your interesting comments and helpful ideas.
I'm sorry to bother you again with my questions, hopefully last time, but
this might lead to a breakthrough.


It's not a bother but I'm sure you will be rather irked if your system
gets trashed due to my suggestions. If you want to see the details of
your disk layout can you download and run PartInfo.exe. It is a DOS
program and you can redirect the output to a file (e.g. "partinfo
my.lst").

You mentioned changing the boot indicator (00 or 80). Why not just
leave both your primary partitions as type 0x0C and change the boot
indicator when you want to change from XP to 98 or vice versa ? This is
how I do it and the only complication in your case would be if PM has
changed your MBR code. This is unlikely but I honestly don't know.

To resize my WinXP(* partition located in the following sequence of
partitions: [C: Win98, (* WinXP, D:, E:, Unallocated] by 7GB, PM had to go
through 5 'elementary' steps in the order displayed below:
a. Resize Extended (* by 7GB (taken from Unallocated)
b. Move E: up by 7GB
c. Move D: up by 7GB
d. Resize Extended (* down by 7GB
e. Resize WinXP (* by 7GB


The overlapping copies in steps b and c could be risky but I'm sure that
PM is doing them carefully so there is no data loss if a crash (e.g.
power loss) occurs. Step d sounds a bit risky because the LBA keys in
the EPBRs are relative to the extended partition. Step d would involve
changing each EPBR and then updating the MBR and I'm not sure how PM
could recover from a crash in this short step.

Are these details somehow useful for confirmation of your idea about these
strange values?


An authoritative reference for FAT32 is an MS document called
FATGEN103.PDF which should be easy to find. "Hidden sectors" is
generally the offset of the volume from the sector containing its
partition entry. So, for primary partitions it is the absolute key and
for logical partitions it is 63. But, I've seen exceptions and the
volumes are still accessible so maybe the value isn't used.

You mentioned a high "first cluster of root" after you'd resized E:.
This suggests that PM has created new directory records and switched
over to these lists once the data copying was complete.

Expanding your E: volume could have been a major task for PM. E: was
just under 8GB which means it could have 4kB clusters. When you
increase it to over about 8.3GB the cluster size has to be increased or
the cluster count will be too high for utilities such as DeFrag. How PM
can do this safely is beyond me.

I still haven't answered your question about D: being inaccessible in
Win98. Can you setup your disk so D: is inaccessible and then run
PartInfo to get the list ? One other source of info here is the MSFN
forums (search for Win98 IO.SYS).

Cheers,
--
Steven
  #46  
Old May 31st 10, 06:18 AM posted to microsoft.public.win98.disks.general
Hot-text
External Usenet User
 
Posts: 1,026
Default Problem with accessing a partition

D: maybe just FAT
win98 can not see the old FAT its a 16
Xp read all!

"Steven Saunderson" wrote in message
...
On Sun, 30 May 2010 16:23:01 -0700, Andrew
wrote:

Thanks a lot for your interesting comments and helpful ideas.
I'm sorry to bother you again with my questions, hopefully last time, but
this might lead to a breakthrough.


It's not a bother but I'm sure you will be rather irked if your system
gets trashed due to my suggestions. If you want to see the details of
your disk layout can you download and run PartInfo.exe. It is a DOS
program and you can redirect the output to a file (e.g. "partinfo
my.lst").

You mentioned changing the boot indicator (00 or 80). Why not just
leave both your primary partitions as type 0x0C and change the boot
indicator when you want to change from XP to 98 or vice versa ? This is
how I do it and the only complication in your case would be if PM has
changed your MBR code. This is unlikely but I honestly don't know.

To resize my WinXP(* partition located in the following sequence of
partitions: [C: Win98, (* WinXP, D:, E:, Unallocated] by 7GB, PM had to
go
through 5 'elementary' steps in the order displayed below:
a. Resize Extended (* by 7GB (taken from Unallocated)
b. Move E: up by 7GB
c. Move D: up by 7GB
d. Resize Extended (* down by 7GB
e. Resize WinXP (* by 7GB


The overlapping copies in steps b and c could be risky but I'm sure that
PM is doing them carefully so there is no data loss if a crash (e.g.
power loss) occurs. Step d sounds a bit risky because the LBA keys in
the EPBRs are relative to the extended partition. Step d would involve
changing each EPBR and then updating the MBR and I'm not sure how PM
could recover from a crash in this short step.

Are these details somehow useful for confirmation of your idea about
these
strange values?


An authoritative reference for FAT32 is an MS document called
FATGEN103.PDF which should be easy to find. "Hidden sectors" is
generally the offset of the volume from the sector containing its
partition entry. So, for primary partitions it is the absolute key and
for logical partitions it is 63. But, I've seen exceptions and the
volumes are still accessible so maybe the value isn't used.

You mentioned a high "first cluster of root" after you'd resized E:.
This suggests that PM has created new directory records and switched
over to these lists once the data copying was complete.

Expanding your E: volume could have been a major task for PM. E: was
just under 8GB which means it could have 4kB clusters. When you
increase it to over about 8.3GB the cluster size has to be increased or
the cluster count will be too high for utilities such as DeFrag. How PM
can do this safely is beyond me.

I still haven't answered your question about D: being inaccessible in
Win98. Can you setup your disk so D: is inaccessible and then run
PartInfo to get the list ? One other source of info here is the MSFN
forums (search for Win98 IO.SYS).

Cheers,
--
Steven


  #47  
Old May 31st 10, 06:18 AM posted to microsoft.public.win98.disks.general
Hot-text
External Usenet User
 
Posts: 1,026
Default Problem with accessing a partition

D: maybe just FAT
win98 can not see the old FAT its a 16
Xp read all!

"Steven Saunderson" wrote in message
...
On Sun, 30 May 2010 16:23:01 -0700, Andrew
wrote:

Thanks a lot for your interesting comments and helpful ideas.
I'm sorry to bother you again with my questions, hopefully last time, but
this might lead to a breakthrough.


It's not a bother but I'm sure you will be rather irked if your system
gets trashed due to my suggestions. If you want to see the details of
your disk layout can you download and run PartInfo.exe. It is a DOS
program and you can redirect the output to a file (e.g. "partinfo
my.lst").

You mentioned changing the boot indicator (00 or 80). Why not just
leave both your primary partitions as type 0x0C and change the boot
indicator when you want to change from XP to 98 or vice versa ? This is
how I do it and the only complication in your case would be if PM has
changed your MBR code. This is unlikely but I honestly don't know.

To resize my WinXP(* partition located in the following sequence of
partitions: [C: Win98, (* WinXP, D:, E:, Unallocated] by 7GB, PM had to
go
through 5 'elementary' steps in the order displayed below:
a. Resize Extended (* by 7GB (taken from Unallocated)
b. Move E: up by 7GB
c. Move D: up by 7GB
d. Resize Extended (* down by 7GB
e. Resize WinXP (* by 7GB


The overlapping copies in steps b and c could be risky but I'm sure that
PM is doing them carefully so there is no data loss if a crash (e.g.
power loss) occurs. Step d sounds a bit risky because the LBA keys in
the EPBRs are relative to the extended partition. Step d would involve
changing each EPBR and then updating the MBR and I'm not sure how PM
could recover from a crash in this short step.

Are these details somehow useful for confirmation of your idea about
these
strange values?


An authoritative reference for FAT32 is an MS document called
FATGEN103.PDF which should be easy to find. "Hidden sectors" is
generally the offset of the volume from the sector containing its
partition entry. So, for primary partitions it is the absolute key and
for logical partitions it is 63. But, I've seen exceptions and the
volumes are still accessible so maybe the value isn't used.

You mentioned a high "first cluster of root" after you'd resized E:.
This suggests that PM has created new directory records and switched
over to these lists once the data copying was complete.

Expanding your E: volume could have been a major task for PM. E: was
just under 8GB which means it could have 4kB clusters. When you
increase it to over about 8.3GB the cluster size has to be increased or
the cluster count will be too high for utilities such as DeFrag. How PM
can do this safely is beyond me.

I still haven't answered your question about D: being inaccessible in
Win98. Can you setup your disk so D: is inaccessible and then run
PartInfo to get the list ? One other source of info here is the MSFN
forums (search for Win98 IO.SYS).

Cheers,
--
Steven


  #48  
Old May 31st 10, 06:24 AM posted to microsoft.public.win98.disks.general
Steven Saunderson
External Usenet User
 
Posts: 37
Default Problem with accessing a partition

On Sun, 30 May 2010 21:59:41 -0500, "Hot-text"
wrote:

All Windows system put boots on C


Well yes but the truth is slightly reversed. DOS and Windows search a
disk for a partition with the boot indicator set before anything else.
Such a partition will always be found first and allocated the drive
letter C. Andrew is talking about changing the bootable flag in the
partition table entries and this will change which partition Windows
regards as C. The other primary partitions (if formatted acceptably)
will appear after all the logical partitions in the volume list.

Setting the boot indicator on more than one primary partition entry
normally causes the MBR code to have a hernia. I suppose one could
change this code to find the first and not worry about the rest.

Cheers,
--
Steven
  #49  
Old May 31st 10, 06:24 AM posted to microsoft.public.win98.disks.general
Steven Saunderson
External Usenet User
 
Posts: 37
Default Problem with accessing a partition

On Sun, 30 May 2010 21:59:41 -0500, "Hot-text"
wrote:

All Windows system put boots on C


Well yes but the truth is slightly reversed. DOS and Windows search a
disk for a partition with the boot indicator set before anything else.
Such a partition will always be found first and allocated the drive
letter C. Andrew is talking about changing the bootable flag in the
partition table entries and this will change which partition Windows
regards as C. The other primary partitions (if formatted acceptably)
will appear after all the logical partitions in the volume list.

Setting the boot indicator on more than one primary partition entry
normally causes the MBR code to have a hernia. I suppose one could
change this code to find the first and not worry about the rest.

Cheers,
--
Steven
  #50  
Old May 31st 10, 06:34 AM posted to microsoft.public.win98.disks.general
Hot-text
External Usenet User
 
Posts: 1,026
Default Problem with accessing a partition


Right and true Steven!

"Steven Saunderson" wrote in message
...
On Sun, 30 May 2010 21:59:41 -0500, "Hot-text"
wrote:

All Windows system put boots on C


Well yes but the truth is slightly reversed. DOS and Windows search a
disk for a partition with the boot indicator set before anything else.
Such a partition will always be found first and allocated the drive
letter C. Andrew is talking about changing the bootable flag in the
partition table entries and this will change which partition Windows
regards as C. The other primary partitions (if formatted acceptably)
will appear after all the logical partitions in the volume list.

Setting the boot indicator on more than one primary partition entry
normally causes the MBR code to have a hernia. I suppose one could
change this code to find the first and not worry about the rest.

Cheers,
--
Steven


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
problem accessing Ms-Dos oer General 2 May 15th 06 08:21 PM
Problem w/Win 98 client accessing WIn 2003 domain [email protected] Networking 0 April 7th 06 01:27 AM
Problem accessing https secure sites since Saturday Lil' Dave General 1 October 12th 04 12:28 PM
Problem accessing Websites over a secure connection Jim Internet 0 October 3rd 04 05:45 PM
Problem accessing XP printer Craig Patton Printing 1 July 20th 04 06:33 PM


All times are GMT +1. The time now is 10:09 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 Win98banter.
The comments are property of their posters.