Can't boot win98! Sectors not found Dos error, right?

[mm]

Can't boot win98! Sectors not found Dos error, right?

I've posted before about the problems I've had booting to win98SE,
after I used Easeus*** to shrink the win98 partition, and I've made
progress**, and I can now boot to Win98 DOS.

But I get a DOS error if I try to do much when I'm there. If I try
to continue on to the Windows of win98, it loads a lot of the things
it is supposed to load, but eventually I get

Abort, Retry, Ignore, Fail?

If I use the Win98 boot menu and only load DOS, I get a similar sector
error when I try to Edit many but not all normally editable files in
the win98 partition. Like .txt, .bat, and .ini files.

I can provide more details if necessary, the exact text of the error
message Edit gives, the files that I can edit versus the ones I can't,
the log of my boot attempt, the error messages when trying to do a
step-by-step start of win98, whatever you want, but maybe this is
enough.

Any suggestions what is wrong?

Help is much appreciated.


**Background. I have multi-boot with win98 in partition C: and winXP
in partition D:. Everything was fine afaik until I used Easeus
partition software to shrink the win98 partition. At that point, I
could get to the multi-boot menu but couldn't reach win98 at all.

People on the XP newsgroup showed me how to SYS C:, then use DOS Debug
to copy the C: boot sector to bootsect.dos, then to use the XP
Recovery Console FIXBOOT C: to restore the C: bootsector back to what
it was, that is, so it points somehow to the boot.ini, the multi-boot
menu. After that, I could boot to winXP or to the DOS of Win98.


*** I'm 99% sure that Easeus Partition Master got me into this mess.
I also found someone else who said it caused no-start with win98. It
runs under 2000, XP and newer, but it didnt' say it couldn't handle a
winw98 partition while doing so. I"m sure it will do fine, running out
ot XP, with FAT32 etc. when the partition is empty, but it seems that
the boot sector varies with the OS, according to Partition Manager 8,
and they wrote that when there was no reason to exaggerate. That is,
I don't think there was much competition that didn't also fully
support win98.

[Hot-Text]

So you do not Run a Defragmentation first
And when you shrink the win98 partition you shrink pass the files on that
Sectors!

For your Files are all over the Free space of the Hard Drive you have the
Defrag first to move them out of the free space!

plus Remember that windows files that can not be move and shrink pass one of
those files the Same Error will come up!

And you will not be able to repair it, So I hope you back up1

[Hot-Text]

Put the partition Back as it was ... And maybe if god will you can save
it..

Restart
and if win98 runs Defrag
Afterwards resize you partition!

Post by Hot-Text
So you do not Run a Defragmentation first
And when you shrink the win98 partition you shrink pass the files on that
Sectors!
For your Files are all over the Free space of the Hard Drive you have the
Defrag first to move them out of the free space!
plus Remember that windows files that can not be move and shrink pass one
of those files the Same Error will come up!
And you will not be able to repair it, So I hope you back up1

[philo]

Post by mm
Can't boot win98! Sectors not found Dos error, right?
I've posted before about the problems I've had booting to win98SE,
after I used Easeus*** to shrink the win98 partition, and I've made
progress**, and I can now boot to Win98 DOS.
But I get a DOS error if I try to do much when I'm there. If I try
to continue on to the Windows of win98, it loads a lot of the things
it is supposed to load, but eventually I get

Abort, Retry, Ignore, Fail?

Typically due to a hard-drive failure

run the HD mfg's diagnostic

or try a different hard-drive

[mm]

Post by philo

Post by mm
Can't boot win98! Sectors not found Dos error, right?
I've posted before about the problems I've had booting to win98SE,
after I used Easeus*** to shrink the win98 partition, and I've made
progress**, and I can now boot to Win98 DOS.
But I get a DOS error if I try to do much when I'm there. If I try
to continue on to the Windows of win98, it loads a lot of the things
it is supposed to load, but eventually I get

Abort, Retry, Ignore, Fail?

Typically due to a hard-drive failure
run the HD mfg's diagnostic

Well, last time I looked about a week ago, my 80gig WD drive was
listed as healthy. Just now I ran WD Data Lifeguard Diagnostics, and
every attribute passed, by a large margin. What next?

Post by philo
or try a different hard-drive

That will take time.

Thanks.

[Hot-Text]

philo try not to give Info

Put the partition Back as it was ... And maybe if god will you can save
it..

Restart
and if win98 runs Defrag
Afterwards resize you partition!

[Todd Vargo]

Post by mm
Can't boot win98! Sectors not found Dos error, right?
I've posted before about the problems I've had booting to win98SE,
after I used Easeus*** to shrink the win98 partition, and I've made
progress**, and I can now boot to Win98 DOS.
But I get a DOS error if I try to do much when I'm there. If I try
to continue on to the Windows of win98, it loads a lot of the things
it is supposed to load, but eventually I get

Abort, Retry, Ignore, Fail?

If I use the Win98 boot menu and only load DOS, I get a similar sector
error when I try to Edit many but not all normally editable files in
the win98 partition. Like .txt, .bat, and .ini files.
I can provide more details if necessary, the exact text of the error
message Edit gives, the files that I can edit versus the ones I can't,
the log of my boot attempt, the error messages when trying to do a
step-by-step start of win98, whatever you want, but maybe this is
enough.
Any suggestions what is wrong?
Help is much appreciated.
**Background. I have multi-boot with win98 in partition C: and winXP
in partition D:. Everything was fine afaik until I used Easeus
partition software to shrink the win98 partition. At that point, I
could get to the multi-boot menu but couldn't reach win98 at all.
People on the XP newsgroup showed me how to SYS C:, then use DOS Debug
to copy the C: boot sector to bootsect.dos, then to use the XP
Recovery Console FIXBOOT C: to restore the C: bootsector back to what
it was, that is, so it points somehow to the boot.ini, the multi-boot
menu. After that, I could boot to winXP or to the DOS of Win98.
*** I'm 99% sure that Easeus Partition Master got me into this mess.
I also found someone else who said it caused no-start with win98. It
runs under 2000, XP and newer, but it didnt' say it couldn't handle a
winw98 partition while doing so. I"m sure it will do fine, running out
ot XP, with FAT32 etc. when the partition is empty, but it seems that
the boot sector varies with the OS, according to Partition Manager 8,
and they wrote that when there was no reason to exaggerate. That is,
I don't think there was much competition that didn't also fully
support win98.

Did you make a backup before changing your partition size? If not, you need
to stop making changes to it and get another HD and data recovery software
to salvage what you can to another HD. Do not boot to the XP partition as
the more you do that, then the less likely you will be able to recover
anything. If you do have a backup, then I would use the HD mfr's diagnostics
disk to requalify the HD before restoring it.

[mm]

On Tue, 19 Oct 2010 17:20:01 -0400, "Todd Vargo"

Post by Todd Vargo

Post by mm
Can't boot win98! Sectors not found Dos error, right?
I've posted before about the problems I've had booting to win98SE,
after I used Easeus*** to shrink the win98 partition, and I've made
progress**, and I can now boot to Win98 DOS.
But I get a DOS error if I try to do much when I'm there. If I try
to continue on to the Windows of win98, it loads a lot of the things
it is supposed to load, but eventually I get

Abort, Retry, Ignore, Fail?

If I use the Win98 boot menu and only load DOS, I get a similar sector
error when I try to Edit many but not all normally editable files in
the win98 partition. Like .txt, .bat, and .ini files.
I can provide more details if necessary, the exact text of the error
message Edit gives, the files that I can edit versus the ones I can't,
the log of my boot attempt, the error messages when trying to do a
step-by-step start of win98, whatever you want, but maybe this is
enough.
Any suggestions what is wrong?
Help is much appreciated.
**Background. I have multi-boot with win98 in partition C: and winXP
in partition D:. Everything was fine afaik until I used Easeus
partition software to shrink the win98 partition. At that point, I
could get to the multi-boot menu but couldn't reach win98 at all.
People on the XP newsgroup showed me how to SYS C:, then use DOS Debug
to copy the C: boot sector to bootsect.dos, then to use the XP
Recovery Console FIXBOOT C: to restore the C: bootsector back to what
it was, that is, so it points somehow to the boot.ini, the multi-boot
menu. After that, I could boot to winXP or to the DOS of Win98.
*** I'm 99% sure that Easeus Partition Master got me into this mess.
I also found someone else who said it caused no-start with win98. It
runs under 2000, XP and newer, but it didnt' say it couldn't handle a
winw98 partition while doing so. I"m sure it will do fine, running out
ot XP, with FAT32 etc. when the partition is empty, but it seems that
the boot sector varies with the OS, according to Partition Manager 8,
and they wrote that when there was no reason to exaggerate. That is,
I don't think there was much competition that didn't also fully
support win98.

Did you make a backup before changing your partition size?

Yes.

Dang, I also should have said that all those files I can't read when
the C: partition (win98) is my system partition, I can still read just
fine when I've booted to XP. That's why I'm thinking there's
something fairly simple (other than restoring the data) that I could
do to the c: (win98) partition that would make it good again.

I should have said that before any of you answered, esp. Philo, but I
didn't remember even when I read his post. Dang.

Post by Todd Vargo
If not, you need
to stop making changes to it and get another HD and data recovery software
to salvage what you can to another HD. Do not boot to the XP partition as
the more you do that, then the less likely you will be able to recover
anything. If you do have a backup, then I would use the HD mfr's diagnostics
disk to requalify the HD before restoring it.

Well, the WD DLG software says it's healthy, that it PASSes all the
SMART tests.

[Klaus Meinhard]

Post by mm
Dang, I also should have said that all those files I can't read when
the C: partition (win98) is my system partition, I can still read just
fine when I've booted to XP. That's why I'm thinking there's
something fairly simple (other than restoring the data) that I could
do to the c: (win98) partition that would make it good again.

Is your partition FAT16 or FAT32?
What's the size of your partition?

(see http://support.microsoft.com/kb/118335)

What's the type of your partition (primary or extended)?
How many partitons of which type are in your system?

(see http://support.microsoft.com/kb/69912)

It _is_ a FAT partition, not NTFS?

[mm]

On Wed, 20 Oct 2010 17:02:12 +0200, "Klaus Meinhard"

Post by Klaus Meinhard

Post by mm
Dang, I also should have said that all those files I can't read when
the C: partition (win98) is my system partition, I can still read just
fine when I've booted to XP. That's why I'm thinking there's
something fairly simple (other than restoring the data) that I could
do to the c: (win98) partition that would make it good again.

I thought I posted this last night. ;( Still no go. Third try!

Post by Klaus Meinhard
Is your partition FAT16 or FAT32?
What's the size of your partition?

FAT32 28 gigs

Post by Klaus Meinhard
(see http://support.microsoft.com/kb/118335)
What's the type of your partition (primary or extended)?
How many partitons of which type are in your system?

C:(win98) is primary and active.
I have two primary partitions on the internal harddrive.

There is a valid MBR. It's set up for multiboot starting at the C:
partition, and related to this, C: contains a valid boot sector, valid
boot.ini, valid bootsect.dos. Those files are seen and read. Other
files in the C: partition are also and others aren't, even though they
are all listed by DOS DIR command.

Post by Klaus Meinhard
(see http://support.microsoft.com/kb/69912)
It _is_ a FAT partition, not NTFS?

Yes, FAT32. So is the winXP partition, so I can read the files in XP
when I'm in 98. And that still works. All the files I can't read or
edit when I'm in the dos of win98, I can read and edit when I'm
running winXP!

[Klaus Meinhard]

Post by mm

Post by Klaus Meinhard
Is your partition FAT16 or FAT32?
What's the size of your partition?

FAT32 28 gigs

See http://support.microsoft.com/kb/184006/en-us . especially this
sector:

<quote>
The ScanDisk tool included with Microsoft Windows 95 and Microsoft
Windows 98 is a 16-bit program. Such programs have a single memory
block maximum allocation size of 16 MB less 64 KB. Therefore, The
Windows 95 or Windows 98 ScanDisk tool cannot process volumes using
the FAT32 file system that have a FAT larger than 16 MB less 64 KB in
size. A FAT entry on a volume using the FAT32 file system uses 4
bytes, so ScanDisk cannot process the FAT on a volume using the FAT32
file system that defines more than 4,177,920 clusters (including the
two reserved clusters). Including the FATs themselves, this works out,
at the maximum of 32 KB per cluster, to a volume size of 127.53
gigabytes (GB).
<unquote>

DOS is a 16bit programm, so other plain DOS tools and DOS itself might
have the same limitation.

[98 Guy]

Post by Klaus Meinhard
<quote>
The ScanDisk tool included with Microsoft Windows 95 and Microsoft
Windows 98 is a 16-bit program. Such programs have a single memory
block maximum allocation size of 16 MB less 64 KB. Therefore, The
Windows 95 or Windows 98 ScanDisk tool cannot process volumes using
the FAT32 file system that have a FAT larger than 16 MB less 64 KB in
size. A FAT entry on a volume using the FAT32 file system uses 4
bytes, so ScanDisk cannot process the FAT on a volume using the FAT32
file system that defines more than 4,177,920 clusters (including the
two reserved clusters). Including the FATs themselves, this works out,
at the maximum of 32 KB per cluster, to a volume size of 127.53
gigabytes (GB).
<unquote>

I have been aware of that MicroShit KB article for several years, and
the information it contains is an absolute LIE.

I have myself created large fat32 partitions (larger than 127 gb, and in
some cases up to 700 gb) with up to 120 MILLION clusters and DOS
scandisk can process those FAT's with no trouble (but it can take many
hours, even 1 or 2 days of continuous processing if doing a surface
scan).

If booting directly into DOS to run scandisk, you must make sure that
himem.sys is in your config.sys, because contrary to what microsoft says
above, scandisk will use extended memory if it's available via
himem.sys. If it's not, scandisk will throw up a message advising you
to use himem.sys.

As long as your motherboard is LBA-48 aware (which means - if your
motherboard was made in 2002 or later) then DOS is fully compatible with
very large hard drives and volumes - far exceeding 128 gb in size.

Windows 98/me is not compatible with drives larger than 128 gb because
of it's protected mode driver (ESDI_506.PDR). But that only applies to
IDE drives. SATA drives don't have that limitation, so Win-9x/me
systems with SATA controllers and drivers can be used with very large
SATA hard drives (the largest I've tested was 750 gb).

DOS fdisk is compable with drives up to 512 gb (there are other fdisk
programs that can exceed that). DOS format.com is compatible with
volumes up to 1024 gb (1 tb) in size.

[Klaus Meinhard]

Hi, "98 Guy",

your words relate to mm's problem in what way?
--
Best Regards,

* Klaus Meinhard *
<www.4dos.info>

Post by 98 Guy
I have been aware of that MicroShit KB article for several years, and
the information it contains is an absolute LIE.
I have myself created large fat32 partitions (larger than 127 gb, and in
some cases up to 700 gb) with up to 120 MILLION clusters and DOS
scandisk can process those FAT's with no trouble (but it can take many
hours, even 1 or 2 days of continuous processing if doing a surface
scan).
If booting directly into DOS to run scandisk, you must make sure that
himem.sys is in your config.sys, because contrary to what microsoft says
above, scandisk will use extended memory if it's available via
himem.sys. If it's not, scandisk will throw up a message advising you
to use himem.sys.
As long as your motherboard is LBA-48 aware (which means - if your
motherboard was made in 2002 or later) then DOS is fully compatible with
very large hard drives and volumes - far exceeding 128 gb in size.
Windows 98/me is not compatible with drives larger than 128 gb
because
of it's protected mode driver (ESDI_506.PDR). But that only applies to
IDE drives. SATA drives don't have that limitation, so Win-9x/me
systems with SATA controllers and drivers can be used with very large
SATA hard drives (the largest I've tested was 750 gb).
DOS fdisk is compable with drives up to 512 gb (there are other fdisk
programs that can exceed that). DOS format.com is compatible with
volumes up to 1024 gb (1 tb) in size.

[98 Guy]

Post by Klaus Meinhard
Hi, "98 Guy",
your words relate to mm's problem in what way?

My words relate to what you posted, which was the Microshit KB article
about FAT having a 16-mb size limitation. That's what I was responding
to, and because I properly quoted and bottom-posted my response, it
should have been obvious.

If the KB article about FAT size does not relate to mm's problem, then
why did *you* post it?

[Klaus Meinhard]

Post by 98 Guy
My words relate to what you posted, which was the Microshit KB
article
about FAT having a 16-mb size limitation. That's what I was
responding
to, and because I properly quoted and bottom-posted my response, it
should have been obvious.

My response to mm's problem (where some files cannot be read in Win98,
but are okay in XP) pointed out that some of the plain DOS progs in
Win98 might have some problems with FAT32 on partitions greater than
16 GB.

I said nothing about FAT (which one?) having any limitations,
especially not the 16mb (!) one you inserted. You should learn the
definition of FAT, DOS, Mega- and GigaBytes and probably a few things
more.

Name-slinging and playing nntp-police may be the prerogative of the
mindless young. But I don't have to read this or answer it. So don't
bother to reply, since I won't see it any more.

[FromTheRafters]

My response to mm's problem (where some files cannot be read in Win98, but
are okay in XP) pointed out that some of the plain DOS progs in Win98
might have some problems with FAT32 on partitions greater than 16 GB.
I said nothing about FAT (which one?) having any limitations, especially
not the 16mb (!) one you inserted. You should learn the definition of FAT,
DOS, Mega- and GigaBytes and probably a few things more.

Just in case anybody's interested:

http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a672f11cf/LocFileSys.doc

[Hot-Text]

Good Info

Post by FromTheRafters

Post by Klaus Meinhard
My response to mm's problem (where some files cannot be read in Win98,
but are okay in XP) pointed out that some of the plain DOS progs in Win98
might have some problems with FAT32 on partitions greater than 16 GB.
I said nothing about FAT (which one?) having any limitations, especially
not the 16mb (!) one you inserted. You should learn the definition of
FAT, DOS, Mega- and GigaBytes and probably a few things more.

http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a672f11cf/LocFileSys.doc

[mm]

On Wed, 20 Oct 2010 17:02:12 +0200, "Klaus Meinhard"

Post by Klaus Meinhard

Post by mm
Dang, I also should have said that all those files I can't read when
the C: partition (win98) is my system partition, I can still read just
fine when I've booted to XP. That's why I'm thinking there's
something fairly simple (other than restoring the data) that I could
do to the c: (win98) partition that would make it good again.

I thought I posted this last night. ;(

Post by Klaus Meinhard
Is your partition FAT16 or FAT32?
What's the size of your partition?

FAT32 28 gigs

Post by Klaus Meinhard
(see http://support.microsoft.com/kb/118335)
What's the type of your partition (primary or extended)?
How many partitons of which type are in your system?

C:(win98) is primary and active.
I have two primary partitions on the internal harddrive.

There is a valid MBR. It's set up for multiboot starting at the C:
partition, and related to this, C: contains a valid boot sector, valid
boot.ini, valid bootsect.dos. Those files are seen and read. Other
files in the C: partition are also and others aren't, even though they
are all listed by DOS DIR command.

Post by Klaus Meinhard
(see http://support.microsoft.com/kb/69912)
It _is_ a FAT partition, not NTFS?

Yes, FAT32. So is the winXP partition, so I can read the files in XP
when I'm in 98. And that still works. All the files I can't read or
edit when I'm in the dos of win98, I can read and edit when I'm
running winXP!

[Todd Vargo]

mm wrote:
...

Post by mm
Well, the WD DLG software says it's healthy, that it PASSes all the
SMART tests.

Those tests only check the condition of the disk. They do not, and are not
capable of, testing the FAT tables pointers.

[dadiOH]

Post by mm
Can't boot win98! Sectors not found Dos error, right?
I've posted before about the problems I've had booting to win98SE,
after I used Easeus*** to shrink the win98 partition, and I've made
progress**, and I can now boot to Win98 DOS.
But I get a DOS error if I try to do much when I'm there. If I try
to continue on to the Windows of win98, it loads a lot of the things
it is supposed to load, but eventually I get

Abort, Retry, Ignore, Fail?

If I use the Win98 boot menu and only load DOS, I get a similar sector
error when I try to Edit many but not all normally editable files in
the win98 partition. Like .txt, .bat, and .ini files.
I can provide more details if necessary, the exact text of the error
message Edit gives, the files that I can edit versus the ones I can't,
the log of my boot attempt, the error messages when trying to do a
step-by-step start of win98, whatever you want, but maybe this is
enough.
Any suggestions what is wrong?
Help is much appreciated.
**Background. I have multi-boot with win98 in partition C: and winXP
in partition D:. Everything was fine afaik until I used Easeus
partition software to shrink the win98 partition. At that point, I
could get to the multi-boot menu but couldn't reach win98 at all.
People on the XP newsgroup showed me how to SYS C:, then use DOS Debug
to copy the C: boot sector to bootsect.dos, then to use the XP
Recovery Console FIXBOOT C: to restore the C: bootsector back to what
it was, that is, so it points somehow to the boot.ini, the multi-boot
menu. After that, I could boot to winXP or to the DOS of Win98.

So what did you do after that to screw stuff up? If nothing, perhaps the
hard disk is failing. Have you tried chkdsk?

[mm]

I think I brought parts of this up in
microsoft.public.windowsxp.general so I've included them in the
follow-up, now that everything works.

In short, Sector errors in win98 partition and inability to start
win98 solved by running MS Windows Defrag from within XP partition.

Post by mm
Can't boot win98! Sectors not found Dos error, right?
I've posted before about the problems I've had booting to win98SE,
after I used Easeus*** to shrink the win98 partition, and I've made
progress**, and I can now boot to Win98 DOS.

To recap, I have dual boot, 98 and XP and my first step in fixing the
problle is explained fairly far below in the quoted text with four
asterisks****.

I was always able to access every file in the win98 partition C from
within XP, which is in its own partition D.

Post by mm
But I get a DOS error if I try to do much when I'm there. If I try
to continue on to the Windows of win98, it loads a lot of the things
it is supposed to load, but eventually I get

Abort, Retry, Ignore, Fail?

Since the problem started when I used Easeus Partition Master** to
make a win98 partition smaller, after I moved data to its own
partition, I thought maybe I could just readjust the partition size,
even just a little bit, with a partition program that wouldn't screw
up win98, for example, Partition Manager 8, which was written when
win98 was king.

But before I did that, I wanted to put all the empty space at the rear
of the partition, so I thought I would use winXP defrag.

After I ran Defrag, I tried to boot to win98 again, just to be sure
which step fixed it, and voila, it worked fine after the defrag. I
guess the files I couldn't access in win98 DOS were all moved around,
to good addresses, or something like that. Maybe you DOS people know
what fixed it?


IIRC, some people suggested that the harddrive was going bad, because
of the sector errors, but I've seen no sign of that in the ensuing
weeks, and the drive is still listed as healthy by SMART.


**I think the System Requirements and what little other documentation
there is for Easeus PM is cryptic and misleading. It says that it
runs on winXP, and doesn't list win98, but it doesn't say that one
can't change the size of a fat32 partition that happens to hold win98
without screwing up the win98. I've learned that I'm not the only one
whose computer has been screwed up by this. I don't think most people
know that the contents of a partition would complicate resizing,
especially when a partition is being shortened at the end, not the
beginning where some important files are. So be warned that Easeus PM
won't work with win98.

Thank you all for your help.

Post by mm
If I use the Win98 boot menu and only load DOS, I get a similar sector
error when I try to Edit many but not all normally editable files in
the win98 partition. Like .txt, .bat, and .ini files.
I can provide more details if necessary, the exact text of the error
message Edit gives, the files that I can edit versus the ones I can't,
the log of my boot attempt, the error messages when trying to do a
step-by-step start of win98, whatever you want, but maybe this is
enough.
Any suggestions what is wrong?
Help is much appreciated.
**Background. I have multi-boot with win98 in partition C: and winXP
in partition D:. Everything was fine afaik until I used Easeus
partition software to shrink the win98 partition. At that point, I
could get to the multi-boot menu but couldn't reach win98 at all.

****

Post by mm
People on the XP newsgroup showed me how to SYS C:, then use DOS Debug
to copy the C: boot sector to bootsect.dos, then to use the XP
Recovery Console FIXBOOT C: to restore the C: bootsector back to what
it was, that is, so it points somehow to the boot.ini, the multi-boot
menu. After that, I could boot to winXP or to the DOS of Win98.
*** I'm 99% sure that Easeus Partition Master got me into this mess.
I also found someone else who said it caused no-start with win98. It
runs under 2000, XP and newer, but it didnt' say it couldn't handle a
winw98 partition while doing so. I"m sure it will do fine, running out
ot XP, with FAT32 etc. when the partition is empty, but it seems that
the boot sector varies with the OS, according to Partition Manager 8,
and they wrote that when there was no reason to exaggerate. That is,
I don't think there was much competition that didn't also fully
support win98.

[PCR]

Post by mm
I think I brought parts of this up in
microsoft.public.windowsxp.general so I've included them in the
follow-up, now that everything works.
In short, Sector errors in win98 partition and inability to start
win98 solved by running MS Windows Defrag from within XP partition.

Like Hot-text, I'm glad you got it fixed. It's a mystery to me how XP
was always able to read files that presumably were in unreadable
clusters (as you posit below), even before the Defrag was run. That's
why I think it must be something else that fixed it -- but glad you got
it working. And thanks for the warning about Easeus. It does sound to be
the troublemaker, all right, as you posted elsewhere...

http://www.partition-tool.com/easeus-partition-manager/help/faq.htm
EASEUS Partition Master FAQ
====Quote=====
6. Both Windows XP and Windows 98 are installed, after resize/move the
partition of Windows 98 under Windows XP, and restarting the computer, I
cannot enter Windows 98 normally. Why?

Cause:
Moving or resizing the partition of the system cannot be allowed by
leading ways of Windows 9X.

Advice:
1. Please do not move or resize the partitions of Windows 9X, ME.
2. Please do not create or delete the partition in front of the system
partition of Windows 9X , ME.
====EOQ=======

That is sufficiently decipherable to mean it isn't for use with Win9x --
but I do understand your decision (before reading that) to try it,
thinking a 9x partition couldn't be different than an XP partition in
structure. I guess I would have made the same decision, if I had to.
Terabyte's BootItNG is obviously the superior product, as it works no
matter what OS is installed.

Post by mm

Post by mm
Can't boot win98! Sectors not found Dos error, right?
I've posted before about the problems I've had booting to win98SE,
after I used Easeus*** to shrink the win98 partition, and I've made
progress**, and I can now boot to Win98 DOS.

To recap, I have dual boot, 98 and XP and my first step in fixing the
problle is explained fairly far below in the quoted text with four
asterisks****.
I was always able to access every file in the win98 partition C from
within XP, which is in its own partition D.

Post by mm
But I get a DOS error if I try to do much when I'm there. If I try
to continue on to the Windows of win98, it loads a lot of the things
it is supposed to load, but eventually I get

Abort, Retry, Ignore, Fail?

That's one of the scariest! And yet XP was able to access the files --
very mysterious! Good going on finding that solution!

Post by mm
Since the problem started when I used Easeus Partition Master** to
make a win98 partition smaller, after I moved data to its own
partition, I thought maybe I could just readjust the partition size,
even just a little bit, with a partition program that wouldn't screw
up win98, for example, Partition Manager 8, which was written when
win98 was king.
But before I did that, I wanted to put all the empty space at the rear
of the partition, so I thought I would use winXP defrag.
After I ran Defrag, I tried to boot to win98 again, just to be sure
which step fixed it, and voila, it worked fine after the defrag. I
guess the files I couldn't access in win98 DOS were all moved around,
to good addresses, or something like that. Maybe you DOS people know
what fixed it?

I believe Defrag rewrites the FAT tables -- but why would XP be able to
read the files even before it did the Defrag & Win98/DOS only afterward?

Post by mm
IIRC, some people suggested that the harddrive was going bad, because
of the sector errors, but I've seen no sign of that in the ensuing
weeks, and the drive is still listed as healthy by SMART.

I guess that most horrible of error messages you got was a false
alarm -- very lucky!

Post by mm
**I think the System Requirements and what little other documentation
there is for Easeus PM is cryptic and misleading. It says that it
runs on winXP, and doesn't list win98, but it doesn't say that one
can't change the size of a fat32 partition that happens to hold win98
without screwing up the win98.

I would have made the same assumption -- it seems reasonable!

Post by mm
I've learned that I'm not the only one
whose computer has been screwed up by this. I don't think most people
know that the contents of a partition would complicate resizing,
especially when a partition is being shortened at the end, not the
beginning where some important files are. So be warned that Easeus PM
won't work with win98.

Thanks for the warning.

Post by mm
Thank you all for your help.

Post by mm
If I use the Win98 boot menu and only load DOS, I get a similar sector
error when I try to Edit many but not all normally editable files in
the win98 partition. Like .txt, .bat, and .ini files.
I can provide more details if necessary, the exact text of the error
message Edit gives, the files that I can edit versus the ones I can't,
the log of my boot attempt, the error messages when trying to do a
step-by-step start of win98, whatever you want, but maybe this is
enough.
Any suggestions what is wrong?
Help is much appreciated.
**Background. I have multi-boot with win98 in partition C: and winXP
in partition D:. Everything was fine afaik until I used Easeus
partition software to shrink the win98 partition. At that point, I
could get to the multi-boot menu but couldn't reach win98 at all.

****

Post by mm
People on the XP newsgroup showed me how to SYS C:, then use DOS Debug
to copy the C: boot sector to bootsect.dos, then to use the XP
Recovery Console FIXBOOT C: to restore the C: bootsector back to what
it was, that is, so it points somehow to the boot.ini, the multi-boot
menu. After that, I could boot to winXP or to the DOS of Win98.
*** I'm 99% sure that Easeus Partition Master got me into this mess.
I also found someone else who said it caused no-start with win98. It
runs under 2000, XP and newer, but it didnt' say it couldn't handle a
winw98 partition while doing so. I"m sure it will do fine, running out
ot XP, with FAT32 etc. when the partition is empty, but it seems that
the boot sector varies with the OS, according to Partition Manager 8,
and they wrote that when there was no reason to exaggerate. That is,
I don't think there was much competition that didn't also fully
support win98.

[Hot-Text]

Mr. PCR

Now I'll MM of The GAG, THE GRAPHICAL BOOT MANAGER

http://gag.sourceforge.net/

Allows boot of up to 9 different operating systems.
It can boot operating systems installed in primary and extended partitions
on any available hard disk.
Can be installed from nearly all operating systems.

it only with I can boot to ME for it's on C: just like 98
With GAG I can Hide the Primary 98 Partition and run ME on C: cool <Hmm!

[PCR]

Post by Hot-Text
Mr. PCR
Now I'll MM of The GAG, THE GRAPHICAL BOOT MANAGER
http://gag.sourceforge.net/
Allows boot of up to 9 different operating systems.
It can boot operating systems installed in primary and extended
partitions on any available hard disk.
Can be installed from nearly all operating systems.
it only with I can boot to ME for it's on C: just like 98
With GAG I can Hide the Primary 98 Partition and run ME on C: cool <Hmm!

It looks interesting. It doesn't claim to do as much as BootItNG,
though, such as partitioning & resizing.

[J. P. Gilliver (John)]

[]

Post by mm
I've learned that I'm not the only one
whose computer has been screwed up by this. I don't think most people
know that the contents of a partition would complicate resizing,
especially when a partition is being shortened at the end, not the
beginning where some important files are. So be warned that Easeus PM
won't work with win98.

[]
I suppose there could be some aspects of an OS (98 in this case) that
have absolute addresses on the disc of where some things are, which
could confuse it if suddenly they aren't at those places any more, but
even if they don't ...

an OS has to know how big a partition it is on, so it knows where it can
write stuff: 98's own defrag, for example, puts a lot of stuff near the
end of the "disc" while it's operating, and presumably other aspects of
the OS need to know the size available too (for example whatever it is
that tells you you've run out of disc space when you try to create, or
copy in, a very large file). There are two ways this information (size
of space available) can be obtained: either the OS keeps a note,
somewhere in itself, of how much space is available, or it goes to look
every time it needs to know, either by testing or by interrogating the
partition table. If it uses the first method (a note of the size within
itself), then if someone reduces the size "without telling it",
something will break. (Thinking about it, it cold even write outside its
own partition and corrupt what is now in the next partition.) Both
methods have their disadvantages: storing the information locally is
prone to changes external to the OS breaking it, but having to check
externally (potentially at every disc write) cold have a significant
performance hit.

I don't know which method '9x uses to "know" how big a partition it's
operating in; if it does use an "internal note" (and if it uses internal
notes of absolute disc positions of anything), then any partition
managing software that is going to be able to safely relocate/resize it
is going to have to have internal knowledge of the OS, and adjust those
internal notes.

[PCR]

Post by J. P. Gilliver (John)
[]

Post by mm
I've learned that I'm not the only one
whose computer has been screwed up by this. I don't think most
people know that the contents of a partition would complicate
resizing, especially when a partition is being shortened at the
end, not the beginning where some important files are. So be
warned that Easeus PM won't work with win98.

[]
I suppose there could be some aspects of an OS (98 in this case) that
have absolute addresses on the disc of where some things are, which
could confuse it if suddenly they aren't at those places any more, but
even if they don't ...

I know Defrag will not move files with both the system & hidden
attribute on. The reason for that could be to protect an absolute
location for a file that some 3rd party software has deposited for copy
protection reasons. But I don't know of anything specific. And I've used
the /p switch of Defrag (that moves the unmoveables) to no ill effect
that I've detected.

Post by J. P. Gilliver (John)
an OS has to know how big a partition it is on, so it knows where it

That seems reasonable to me. There may be BIOS & onboard HDD firmware
involved too, but surely the OS needs to know.

Post by J. P. Gilliver (John)
98's own defrag, for example, puts a lot of stuff
near the end of the "disc" while it's operating,

Right. I've watched that more than a few times. I believe Defrag has
gotten its information from the FAT table, but I'm not sure where that
table is kept. It depicts all the available clusters & whether they are
currently in use or not, IIRC.

Post by J. P. Gilliver (John)
and presumably other
aspects of the OS need to know the size available too (for example
whatever it is that tells you you've run out of disc space when you
try to create, or copy in, a very large file). There are two ways
this information (size of space available) can be obtained: either
the OS keeps a note, somewhere in itself, of how much space is
available, or it goes to look every time it needs to know, either by
testing or by interrogating the partition table.

The partition table can tell the size of the partition, but not how much
of it is used. But there is a note kept of free space somewhere -- I
think in the PBR (Partition Boot Record), an area in front of the
partition. However, the most up-to-date source of space used is the FAT.

Post by J. P. Gilliver (John)
If it uses the first
method (a note of the size within itself), then if someone reduces
the size "without telling it", something will break.

I guess you are right. Easeus had somehow screwed Win98's knowledge of
the partition size after resizing it (possibly not updating the FAT),
but somehow not WinXP's knowledge. MM was able to read files with XP
that were unreadable through Win98, until a Defrag was run. The Defrag
fixed the FAT for Win98 (& possibly even the free space note in the
PBR).

Post by J. P. Gilliver (John)
(Thinking about
it, it cold even write outside its own partition and corrupt what is
storing the information locally is prone to changes external to the
OS breaking it, but having to check externally (potentially at every
disc write) cold have a significant performance hit.

That is a conundrum -- speed or precision.

Post by J. P. Gilliver (John)
I don't know which method '9x uses to "know" how big a partition it's
operating in;

And it needs to know how much of that is free as well. It's in the FAT
tables.

Post by J. P. Gilliver (John)
if it does use an "internal note" (and if it uses
internal notes of absolute disc positions of anything), then any
partition managing software that is going to be able to safely
relocate/resize it is going to have to have internal knowledge of the
OS, and adjust those internal notes.

Yep. I think you've got it. That's what Easeus got wrong for Win98.

[John John - MVP]

Post by J. P. Gilliver (John)
[]

Post by mm
I've learned that I'm not the only one
whose computer has been screwed up by this. I don't think most
people know that the contents of a partition would complicate
resizing, especially when a partition is being shortened at the
end, not the beginning where some important files are. So be
warned that Easeus PM won't work with win98.

[]
I suppose there could be some aspects of an OS (98 in this case) that
have absolute addresses on the disc of where some things are, which
could confuse it if suddenly they aren't at those places any more, but
even if they don't ...

I know Defrag will not move files with both the system& hidden
attribute on. The reason for that could be to protect an absolute
location for a file that some 3rd party software has deposited for copy
protection reasons. But I don't know of anything specific. And I've used
the /p switch of Defrag (that moves the unmoveables) to no ill effect
that I've detected.

Post by J. P. Gilliver (John)
an OS has to know how big a partition it is on, so it knows where it

That seems reasonable to me. There may be BIOS& onboard HDD firmware
involved too, but surely the OS needs to know.

Post by J. P. Gilliver (John)
98's own defrag, for example, puts a lot of stuff
near the end of the "disc" while it's operating,

Right. I've watched that more than a few times. I believe Defrag has
gotten its information from the FAT table, but I'm not sure where that
table is kept. It depicts all the available clusters& whether they are
currently in use or not, IIRC.

Post by J. P. Gilliver (John)
and presumably other
aspects of the OS need to know the size available too (for example
whatever it is that tells you you've run out of disc space when you
try to create, or copy in, a very large file). There are two ways
this information (size of space available) can be obtained: either
the OS keeps a note, somewhere in itself, of how much space is
available, or it goes to look every time it needs to know, either by
testing or by interrogating the partition table.

The partition table can tell the size of the partition, but not how much
of it is used. But there is a note kept of free space somewhere -- I
think in the PBR (Partition Boot Record), an area in front of the
partition. However, the most up-to-date source of space used is the FAT.

Post by J. P. Gilliver (John)
If it uses the first
method (a note of the size within itself), then if someone reduces
the size "without telling it", something will break.

I guess you are right. Easeus had somehow screwed Win98's knowledge of
the partition size after resizing it (possibly not updating the FAT),
but somehow not WinXP's knowledge. MM was able to read files with XP
that were unreadable through Win98, until a Defrag was run. The Defrag
fixed the FAT for Win98 (& possibly even the free space note in the
PBR).

Post by J. P. Gilliver (John)
(Thinking about
it, it cold even write outside its own partition and corrupt what is
storing the information locally is prone to changes external to the
OS breaking it, but having to check externally (potentially at every
disc write) cold have a significant performance hit.

That is a conundrum -- speed or precision.

Post by J. P. Gilliver (John)
I don't know which method '9x uses to "know" how big a partition it's
operating in;

And it needs to know how much of that is free as well. It's in the FAT
tables.

Post by J. P. Gilliver (John)
if it does use an "internal note" (and if it uses
internal notes of absolute disc positions of anything), then any
partition managing software that is going to be able to safely
relocate/resize it is going to have to have internal knowledge of the
OS, and adjust those internal notes.

Yep. I think you've got it. That's what Easeus got wrong for Win98.

When Windows 98 is in a dual boot configuration with NT operating
systems you will run in the same problem if you resize the W9x partition
with just about any partition tool. This was pointed out at the start
of the other discussion thread, the problem is with the Bootsect.dos
file, this file becomes invalid if the DOS/W9x partition is resized and
it will then fail to boot properly.

When arranged in a dual boot configuration with NT operating systems the
W9x boot sector is copied to the Bootsect.dos file then the NT boot
sector is written to the partition. When you boot the computer you boot
using the NT boot sector which then launches the Ntldr boot loader, if
you select to boot Windows 98 ntldr will load the bootsect.dos file,
which is a copy of the W9x boot sector, being that the file was not
updated when the partition was resized it will fail, you need to rebuild
this file to reflect the changes in the partition.

John

[John John - MVP]

Post by J. P. Gilliver (John)
[]

Post by mm
I've learned that I'm not the only one
whose computer has been screwed up by this. I don't think most
people know that the contents of a partition would complicate
resizing, especially when a partition is being shortened at the
end, not the beginning where some important files are. So be
warned that Easeus PM won't work with win98.

[]
I suppose there could be some aspects of an OS (98 in this case) that
have absolute addresses on the disc of where some things are, which
could confuse it if suddenly they aren't at those places any more, but
even if they don't ...

I know Defrag will not move files with both the system& hidden
attribute on. The reason for that could be to protect an absolute
location for a file that some 3rd party software has deposited for copy
protection reasons. But I don't know of anything specific. And I've used
the /p switch of Defrag (that moves the unmoveables) to no ill effect
that I've detected.

Post by J. P. Gilliver (John)
an OS has to know how big a partition it is on, so it knows where it

That seems reasonable to me. There may be BIOS& onboard HDD firmware
involved too, but surely the OS needs to know.

Post by J. P. Gilliver (John)
98's own defrag, for example, puts a lot of stuff
near the end of the "disc" while it's operating,

Right. I've watched that more than a few times. I believe Defrag has
gotten its information from the FAT table, but I'm not sure where that
table is kept. It depicts all the available clusters& whether they are
currently in use or not, IIRC.

Post by J. P. Gilliver (John)
and presumably other
aspects of the OS need to know the size available too (for example
whatever it is that tells you you've run out of disc space when you
try to create, or copy in, a very large file). There are two ways
this information (size of space available) can be obtained: either
the OS keeps a note, somewhere in itself, of how much space is
available, or it goes to look every time it needs to know, either by
testing or by interrogating the partition table.

The partition table can tell the size of the partition, but not how much
of it is used. But there is a note kept of free space somewhere -- I
think in the PBR (Partition Boot Record), an area in front of the
partition. However, the most up-to-date source of space used is the FAT.

Post by J. P. Gilliver (John)
If it uses the first
method (a note of the size within itself), then if someone reduces
the size "without telling it", something will break.

I guess you are right. Easeus had somehow screwed Win98's knowledge of
the partition size after resizing it (possibly not updating the FAT),
but somehow not WinXP's knowledge. MM was able to read files with XP
that were unreadable through Win98, until a Defrag was run. The Defrag
fixed the FAT for Win98 (& possibly even the free space note in the
PBR).

Post by J. P. Gilliver (John)
(Thinking about
it, it cold even write outside its own partition and corrupt what is
storing the information locally is prone to changes external to the
OS breaking it, but having to check externally (potentially at every
disc write) cold have a significant performance hit.

That is a conundrum -- speed or precision.

Post by J. P. Gilliver (John)
I don't know which method '9x uses to "know" how big a partition it's
operating in;

And it needs to know how much of that is free as well. It's in the FAT
tables.

Post by J. P. Gilliver (John)
if it does use an "internal note" (and if it uses
internal notes of absolute disc positions of anything), then any
partition managing software that is going to be able to safely
relocate/resize it is going to have to have internal knowledge of the
OS, and adjust those internal notes.

Yep. I think you've got it. That's what Easeus got wrong for Win98.

When Windows 98 is in a dual boot configuration with NT operating
systems you will run in the same problem if you resize the W9x partition
with just about any partition tool. This was pointed out at the start
of the other discussion thread, the problem is with the Bootsect.dos
file, this file becomes invalid if the DOS/W9x partition is resized and
it will then fail to boot properly.

When arranged in a dual boot configuration with NT operating systems the
W9x boot sector is copied to the Bootsect.dos file then the NT boot
sector is written to the partition. When you boot the computer you boot
using the NT boot sector which then launches the Ntldr boot loader, if
you select to boot Windows 98 ntldr will load the bootsect.dos file,
which is a copy of the W9x boot sector, being that the file was not
updated when the partition was resized it will fail, you need to rebuild
this file to reflect the changes in the partition.

John

[John John - MVP]

Post by J. P. Gilliver (John)
[]

Post by mm
I've learned that I'm not the only one
whose computer has been screwed up by this. I don't think most
people know that the contents of a partition would complicate
resizing, especially when a partition is being shortened at the
end, not the beginning where some important files are. So be
warned that Easeus PM won't work with win98.

[]
I suppose there could be some aspects of an OS (98 in this case) that
have absolute addresses on the disc of where some things are, which
could confuse it if suddenly they aren't at those places any more, but
even if they don't ...

I know Defrag will not move files with both the system& hidden
attribute on. The reason for that could be to protect an absolute
location for a file that some 3rd party software has deposited for copy
protection reasons. But I don't know of anything specific. And I've used
the /p switch of Defrag (that moves the unmoveables) to no ill effect
that I've detected.

Post by J. P. Gilliver (John)
an OS has to know how big a partition it is on, so it knows where it

That seems reasonable to me. There may be BIOS& onboard HDD firmware
involved too, but surely the OS needs to know.

Post by J. P. Gilliver (John)
98's own defrag, for example, puts a lot of stuff
near the end of the "disc" while it's operating,

Right. I've watched that more than a few times. I believe Defrag has
gotten its information from the FAT table, but I'm not sure where that
table is kept. It depicts all the available clusters& whether they are
currently in use or not, IIRC.

Post by J. P. Gilliver (John)
and presumably other
aspects of the OS need to know the size available too (for example
whatever it is that tells you you've run out of disc space when you
try to create, or copy in, a very large file). There are two ways
this information (size of space available) can be obtained: either
the OS keeps a note, somewhere in itself, of how much space is
available, or it goes to look every time it needs to know, either by
testing or by interrogating the partition table.

The partition table can tell the size of the partition, but not how much
of it is used. But there is a note kept of free space somewhere -- I
think in the PBR (Partition Boot Record), an area in front of the
partition. However, the most up-to-date source of space used is the FAT.

Post by J. P. Gilliver (John)
If it uses the first
method (a note of the size within itself), then if someone reduces
the size "without telling it", something will break.

I guess you are right. Easeus had somehow screwed Win98's knowledge of
the partition size after resizing it (possibly not updating the FAT),
but somehow not WinXP's knowledge. MM was able to read files with XP
that were unreadable through Win98, until a Defrag was run. The Defrag
fixed the FAT for Win98 (& possibly even the free space note in the
PBR).

Post by J. P. Gilliver (John)
(Thinking about
it, it cold even write outside its own partition and corrupt what is
storing the information locally is prone to changes external to the
OS breaking it, but having to check externally (potentially at every
disc write) cold have a significant performance hit.

That is a conundrum -- speed or precision.

Post by J. P. Gilliver (John)
I don't know which method '9x uses to "know" how big a partition it's
operating in;

And it needs to know how much of that is free as well. It's in the FAT
tables.

Post by J. P. Gilliver (John)
if it does use an "internal note" (and if it uses
internal notes of absolute disc positions of anything), then any
partition managing software that is going to be able to safely
relocate/resize it is going to have to have internal knowledge of the
OS, and adjust those internal notes.

Yep. I think you've got it. That's what Easeus got wrong for Win98.

When Windows 98 is in a dual boot configuration with NT operating
systems you will run in the same problem if you resize the W9x partition
with just about any partition tool. This was pointed out at the start
of the other discussion thread, the problem is with the Bootsect.dos
file, this file becomes invalid if the DOS/W9x partition is resized and
it will then fail to boot properly.

When arranged in a dual boot configuration with NT operating systems the
W9x boot sector is copied to the Bootsect.dos file then the NT boot
sector is written to the partition. When you boot the computer you boot
using the NT boot sector which then launches the Ntldr boot loader, if
you select to boot Windows 98 ntldr will load the bootsect.dos file,
which is a copy of the W9x boot sector, being that the file was not
updated when the partition was resized it will fail, you need to rebuild
this file to reflect the changes in the partition.

John

[J. P. Gilliver (John)]

[]

Post by John John - MVP

Post by PCR

Post by J. P. Gilliver (John)
if it does use an "internal note" (and if it uses
internal notes of absolute disc positions of anything), then any
partition managing software that is going to be able to safely
relocate/resize it is going to have to have internal knowledge of the
OS, and adjust those internal notes.

Yep. I think you've got it. That's what Easeus got wrong for Win98.

When Windows 98 is in a dual boot configuration with NT operating
systems you will run in the same problem if you resize the W9x
partition with just about any partition tool. This was pointed out at
the start of the other discussion thread, the problem is with the
Bootsect.dos file, this file becomes invalid if the DOS/W9x partition
is resized and it will then fail to boot properly.
When arranged in a dual boot configuration with NT operating systems
the W9x boot sector is copied to the Bootsect.dos file then the NT boot
sector is written to the partition. When you boot the computer you
boot using the NT boot sector which then launches the Ntldr boot
loader, if you select to boot Windows 98 ntldr will load the
bootsect.dos file, which is a copy of the W9x boot sector, being that
the file was not updated when the partition was resized it will fail,
you need to rebuild this file to reflect the changes in the partition.

[]
And the FAT table, if that stores either absolute size or any absolute
addresses?

In case I should ever need to resize a '98 partition, what's the easiest
way to rebuild this file, and the FAT if necessary?

(If it _isn't_ a multiboot system, presumably only the FAT would need
rebuilding.)

[PCR]

Post by John John - MVP

Post by J. P. Gilliver (John)
[]

Post by mm
I've learned that I'm not the only one
whose computer has been screwed up by this. I don't think most
people know that the contents of a partition would complicate
resizing, especially when a partition is being shortened at the
end, not the beginning where some important files are. So be
warned that Easeus PM won't work with win98.

[]
I suppose there could be some aspects of an OS (98 in this case)
that have absolute addresses on the disc of where some things are,
which could confuse it if suddenly they aren't at those places any
more, but even if they don't ...

I know Defrag will not move files with both the system& hidden
attribute on. The reason for that could be to protect an absolute
location for a file that some 3rd party software has deposited for
copy protection reasons. But I don't know of anything specific. And
I've used the /p switch of Defrag (that moves the unmoveables) to no
ill effect that I've detected.

Post by J. P. Gilliver (John)
an OS has to know how big a partition it is on, so it knows where it

That seems reasonable to me. There may be BIOS& onboard HDD firmware
involved too, but surely the OS needs to know.

Post by J. P. Gilliver (John)
98's own defrag, for example, puts a lot of stuff
near the end of the "disc" while it's operating,

Right. I've watched that more than a few times. I believe Defrag has
gotten its information from the FAT table, but I'm not sure where
that table is kept. It depicts all the available clusters& whether
they are currently in use or not, IIRC.

Post by J. P. Gilliver (John)
and presumably other
aspects of the OS need to know the size available too (for example
whatever it is that tells you you've run out of disc space when you
try to create, or copy in, a very large file). There are two ways
this information (size of space available) can be obtained: either
the OS keeps a note, somewhere in itself, of how much space is
available, or it goes to look every time it needs to know, either by
testing or by interrogating the partition table.

The partition table can tell the size of the partition, but not how
much of it is used. But there is a note kept of free space somewhere
-- I think in the PBR (Partition Boot Record), an area in front of
the partition. However, the most up-to-date source of space used is
the FAT.

Post by J. P. Gilliver (John)
If it uses the first
method (a note of the size within itself), then if someone reduces
the size "without telling it", something will break.

I guess you are right. Easeus had somehow screwed Win98's knowledge
of the partition size after resizing it (possibly not updating the
FAT), but somehow not WinXP's knowledge. MM was able to read files
with XP that were unreadable through Win98, until a Defrag was run.
The Defrag fixed the FAT for Win98 (& possibly even the free space
note in the PBR).

Post by J. P. Gilliver (John)
(Thinking about
it, it cold even write outside its own partition and corrupt what is
storing the information locally is prone to changes external to the
OS breaking it, but having to check externally (potentially at every
disc write) cold have a significant performance hit.

That is a conundrum -- speed or precision.

Post by J. P. Gilliver (John)
I don't know which method '9x uses to "know" how big a partition
it's operating in;

And it needs to know how much of that is free as well. It's in the
FAT tables.

Post by J. P. Gilliver (John)
if it does use an "internal note" (and if it uses
internal notes of absolute disc positions of anything), then any
partition managing software that is going to be able to safely
relocate/resize it is going to have to have internal knowledge of
the OS, and adjust those internal notes.

Yep. I think you've got it. That's what Easeus got wrong for Win98.

When Windows 98 is in a dual boot configuration with NT operating
systems you will run in the same problem if you resize the W9x
partition with just about any partition tool. This was pointed out
at the start of the other discussion thread, the problem is with the
Bootsect.dos file, this file becomes invalid if the DOS/W9x partition
is resized and it will then fail to boot properly.
When arranged in a dual boot configuration with NT operating systems
the W9x boot sector is copied to the Bootsect.dos file then the NT
boot sector is written to the partition. When you boot the computer
you boot using the NT boot sector which then launches the Ntldr boot
loader, if you select to boot Windows 98 ntldr will load the
bootsect.dos file, which is a copy of the W9x boot sector, being that
the file was not updated when the partition was resized it will fail,
you need to rebuild this file to reflect the changes in the partition.
John

What is it about Bootsect.dos that needs adjusting over a resize? Has it
grabbed the free space notation? A quick Google search shows
Bootsect.dos is mainly about IO.sys (to boot Win98), & that SYS will
restore it.

[Bill Blanton]

Post by PCR

Post by John John - MVP

Post by J. P. Gilliver (John)
[]

Post by mm
I've learned that I'm not the only one
whose computer has been screwed up by this. I don't think most
people know that the contents of a partition would complicate
resizing, especially when a partition is being shortened at the
end, not the beginning where some important files are. So be
warned that Easeus PM won't work with win98.

[]
I suppose there could be some aspects of an OS (98 in this case)
that have absolute addresses on the disc of where some things are,
which could confuse it if suddenly they aren't at those places any
more, but even if they don't ...

I know Defrag will not move files with both the system& hidden
attribute on. The reason for that could be to protect an absolute
location for a file that some 3rd party software has deposited for
copy protection reasons. But I don't know of anything specific. And
I've used the /p switch of Defrag (that moves the unmoveables) to no
ill effect that I've detected.

Post by J. P. Gilliver (John)
an OS has to know how big a partition it is on, so it knows where it

That seems reasonable to me. There may be BIOS& onboard HDD firmware
involved too, but surely the OS needs to know.

Post by J. P. Gilliver (John)
98's own defrag, for example, puts a lot of stuff
near the end of the "disc" while it's operating,

Right. I've watched that more than a few times. I believe Defrag has
gotten its information from the FAT table, but I'm not sure where
that table is kept. It depicts all the available clusters& whether
they are currently in use or not, IIRC.

Post by J. P. Gilliver (John)
and presumably other
aspects of the OS need to know the size available too (for example
whatever it is that tells you you've run out of disc space when you
try to create, or copy in, a very large file). There are two ways
this information (size of space available) can be obtained: either
the OS keeps a note, somewhere in itself, of how much space is
available, or it goes to look every time it needs to know, either by
testing or by interrogating the partition table.

The partition table can tell the size of the partition, but not how
much of it is used. But there is a note kept of free space somewhere
-- I think in the PBR (Partition Boot Record), an area in front of
the partition. However, the most up-to-date source of space used is
the FAT.

Post by J. P. Gilliver (John)
If it uses the first
method (a note of the size within itself), then if someone reduces
the size "without telling it", something will break.

I guess you are right. Easeus had somehow screwed Win98's knowledge
of the partition size after resizing it (possibly not updating the
FAT), but somehow not WinXP's knowledge. MM was able to read files
with XP that were unreadable through Win98, until a Defrag was run.
The Defrag fixed the FAT for Win98 (& possibly even the free space
note in the PBR).

Post by J. P. Gilliver (John)
(Thinking about
it, it cold even write outside its own partition and corrupt what is
storing the information locally is prone to changes external to the
OS breaking it, but having to check externally (potentially at every
disc write) cold have a significant performance hit.

That is a conundrum -- speed or precision.

Post by J. P. Gilliver (John)
I don't know which method '9x uses to "know" how big a partition
it's operating in;

And it needs to know how much of that is free as well. It's in the
FAT tables.

Post by J. P. Gilliver (John)
if it does use an "internal note" (and if it uses
internal notes of absolute disc positions of anything), then any
partition managing software that is going to be able to safely
relocate/resize it is going to have to have internal knowledge of
the OS, and adjust those internal notes.

Yep. I think you've got it. That's what Easeus got wrong for Win98.

When Windows 98 is in a dual boot configuration with NT operating
systems you will run in the same problem if you resize the W9x
partition with just about any partition tool. This was pointed out
at the start of the other discussion thread, the problem is with the
Bootsect.dos file, this file becomes invalid if the DOS/W9x partition
is resized and it will then fail to boot properly.
When arranged in a dual boot configuration with NT operating systems
the W9x boot sector is copied to the Bootsect.dos file then the NT
boot sector is written to the partition. When you boot the computer
you boot using the NT boot sector which then launches the Ntldr boot
loader, if you select to boot Windows 98 ntldr will load the
bootsect.dos file, which is a copy of the W9x boot sector, being that
the file was not updated when the partition was resized it will fail,
you need to rebuild this file to reflect the changes in the partition.
John

What is it about Bootsect.dos that needs adjusting over a resize? Has it
grabbed the free space notation? A quick Google search shows
Bootsect.dos is mainly about IO.sys (to boot Win98),& that SYS will
restore it.

Total sectors in the volume.
FAT size.

Those are the biggest factors. The data region's starting location,
where a cluster's "relative" value points to, is computed from the FAT
size,, as it immediately follows the FATs.

[PCR]

Post by Bill Blanton

Post by PCR

Post by John John - MVP

Post by J. P. Gilliver (John)
[]

Post by mm
I've learned that I'm not the only one
whose computer has been screwed up by this. I don't think most
people know that the contents of a partition would complicate
resizing, especially when a partition is being shortened at the
end, not the beginning where some important files are. So be
warned that Easeus PM won't work with win98.

[]
I suppose there could be some aspects of an OS (98 in this case)
that have absolute addresses on the disc of where some things are,
which could confuse it if suddenly they aren't at those places any
more, but even if they don't ...

I know Defrag will not move files with both the system& hidden
attribute on. The reason for that could be to protect an absolute
location for a file that some 3rd party software has deposited for
copy protection reasons. But I don't know of anything specific. And
I've used the /p switch of Defrag (that moves the unmoveables) to
no ill effect that I've detected.

Post by J. P. Gilliver (John)
an OS has to know how big a partition it is on, so it knows where

That seems reasonable to me. There may be BIOS& onboard HDD
firmware involved too, but surely the OS needs to know.

Post by J. P. Gilliver (John)
98's own defrag, for example, puts a lot of stuff
near the end of the "disc" while it's operating,

Right. I've watched that more than a few times. I believe Defrag
has gotten its information from the FAT table, but I'm not sure
where that table is kept. It depicts all the available clusters&
whether they are currently in use or not, IIRC.

Post by J. P. Gilliver (John)
and presumably other
aspects of the OS need to know the size available too (for example
whatever it is that tells you you've run out of disc space when
you try to create, or copy in, a very large file). There are two
either the OS keeps a note, somewhere in itself, of how much
space is available, or it goes to look every time it needs to
know, either by testing or by interrogating the partition table.

The partition table can tell the size of the partition, but not how
much of it is used. But there is a note kept of free space
somewhere -- I think in the PBR (Partition Boot Record), an area
in front of the partition. However, the most up-to-date source of
space used is the FAT.

Post by J. P. Gilliver (John)
If it uses the first
method (a note of the size within itself), then if someone reduces
the size "without telling it", something will break.

I guess you are right. Easeus had somehow screwed Win98's knowledge
of the partition size after resizing it (possibly not updating the
FAT), but somehow not WinXP's knowledge. MM was able to read files
with XP that were unreadable through Win98, until a Defrag was run.
The Defrag fixed the FAT for Win98 (& possibly even the free
space note in the PBR).

Post by J. P. Gilliver (John)
(Thinking about
it, it cold even write outside its own partition and corrupt what
is now in the next partition.) Both methods have their
disadvantages: storing the information locally is prone to
changes external to the OS breaking it, but having to check
externally (potentially at every disc write) cold have a
significant performance hit.

That is a conundrum -- speed or precision.

Post by J. P. Gilliver (John)
I don't know which method '9x uses to "know" how big a partition
it's operating in;

And it needs to know how much of that is free as well. It's in the
FAT tables.

Post by J. P. Gilliver (John)
if it does use an "internal note" (and if it uses
internal notes of absolute disc positions of anything), then any
partition managing software that is going to be able to safely
relocate/resize it is going to have to have internal knowledge of
the OS, and adjust those internal notes.

Yep. I think you've got it. That's what Easeus got wrong for Win98.

When Windows 98 is in a dual boot configuration with NT operating
systems you will run in the same problem if you resize the W9x
partition with just about any partition tool. This was pointed out
at the start of the other discussion thread, the problem is with the
Bootsect.dos file, this file becomes invalid if the DOS/W9x
partition is resized and it will then fail to boot properly.
When arranged in a dual boot configuration with NT operating systems
the W9x boot sector is copied to the Bootsect.dos file then the NT
boot sector is written to the partition. When you boot the computer
you boot using the NT boot sector which then launches the Ntldr boot
loader, if you select to boot Windows 98 ntldr will load the
bootsect.dos file, which is a copy of the W9x boot sector, being
that the file was not updated when the partition was resized it
will fail, you need to rebuild this file to reflect the changes in
the partition.
John

What is it about Bootsect.dos that needs adjusting over a resize?
Has it grabbed the free space notation? A quick Google search shows
Bootsect.dos is mainly about IO.sys (to boot Win98),& that SYS will
restore it.

Total sectors in the volume.
FAT size.
Those are the biggest factors. The data region's starting location,
where a cluster's "relative" value points to, is computed from the FAT
size,, as it immediately follows the FATs.

I've since discovered that, reading...

http://thpc.info/dual/bootsequence.html
Boot Sequence in a Windows Dual-Boot Explained

..., as I've posted elsewhere in this thread. But, it doesn't sound like
that data is used in the dual boot process. Hasn't the partition already
booted by then, & Bootsect.dos been loaded (to memory - not written to
the HDD) only to start IO.sys (which is even in the same partition)? I
think it's more likely the FAT hasn't been updated by Easeus, which is
why DOS couldn't read the files & Win98 wouldn't boot. But I still don't
know why XP could read files on the resized partition even before it
Defragged it.

[PCR]

Post by PCR

Post by John John - MVP

Post by J. P. Gilliver (John)
[]

Post by mm
I've learned that I'm not the only one
whose computer has been screwed up by this. I don't think most
people know that the contents of a partition would complicate
resizing, especially when a partition is being shortened at the
end, not the beginning where some important files are. So be
warned that Easeus PM won't work with win98.

[]
I suppose there could be some aspects of an OS (98 in this case)
that have absolute addresses on the disc of where some things are,
which could confuse it if suddenly they aren't at those places any
more, but even if they don't ...

I know Defrag will not move files with both the system& hidden
attribute on. The reason for that could be to protect an absolute
location for a file that some 3rd party software has deposited for
copy protection reasons. But I don't know of anything specific. And
I've used the /p switch of Defrag (that moves the unmoveables) to no
ill effect that I've detected.

Post by J. P. Gilliver (John)
an OS has to know how big a partition it is on, so it knows where

That seems reasonable to me. There may be BIOS& onboard HDD
firmware involved too, but surely the OS needs to know.

Post by J. P. Gilliver (John)
98's own defrag, for example, puts a lot of stuff
near the end of the "disc" while it's operating,

Right. I've watched that more than a few times. I believe Defrag has
gotten its information from the FAT table, but I'm not sure where
that table is kept. It depicts all the available clusters& whether
they are currently in use or not, IIRC.

Post by J. P. Gilliver (John)
and presumably other
aspects of the OS need to know the size available too (for example
whatever it is that tells you you've run out of disc space when you
try to create, or copy in, a very large file). There are two ways
this information (size of space available) can be obtained: either
the OS keeps a note, somewhere in itself, of how much space is
available, or it goes to look every time it needs to know, either
by testing or by interrogating the partition table.

The partition table can tell the size of the partition, but not how
much of it is used. But there is a note kept of free space somewhere
-- I think in the PBR (Partition Boot Record), an area in front of
the partition. However, the most up-to-date source of space used is
the FAT.

Post by J. P. Gilliver (John)
If it uses the first
method (a note of the size within itself), then if someone reduces
the size "without telling it", something will break.

I guess you are right. Easeus had somehow screwed Win98's knowledge
of the partition size after resizing it (possibly not updating the
FAT), but somehow not WinXP's knowledge. MM was able to read files
with XP that were unreadable through Win98, until a Defrag was run.
The Defrag fixed the FAT for Win98 (& possibly even the free space
note in the PBR).

Post by J. P. Gilliver (John)
(Thinking about
it, it cold even write outside its own partition and corrupt what
is now in the next partition.) Both methods have their
disadvantages: storing the information locally is prone to changes
external to the OS breaking it, but having to check externally
(potentially at every disc write) cold have a significant
performance hit.

That is a conundrum -- speed or precision.

Post by J. P. Gilliver (John)
I don't know which method '9x uses to "know" how big a partition
it's operating in;

And it needs to know how much of that is free as well. It's in the
FAT tables.

Post by J. P. Gilliver (John)
if it does use an "internal note" (and if it uses
internal notes of absolute disc positions of anything), then any
partition managing software that is going to be able to safely
relocate/resize it is going to have to have internal knowledge of
the OS, and adjust those internal notes.

Yep. I think you've got it. That's what Easeus got wrong for Win98.

When Windows 98 is in a dual boot configuration with NT operating
systems you will run in the same problem if you resize the W9x
partition with just about any partition tool. This was pointed out
at the start of the other discussion thread, the problem is with the
Bootsect.dos file, this file becomes invalid if the DOS/W9x partition
is resized and it will then fail to boot properly.
When arranged in a dual boot configuration with NT operating systems
the W9x boot sector is copied to the Bootsect.dos file then the NT
boot sector is written to the partition. When you boot the computer
you boot using the NT boot sector which then launches the Ntldr boot
loader, if you select to boot Windows 98 ntldr will load the
bootsect.dos file, which is a copy of the W9x boot sector, being that
the file was not updated when the partition was resized it will fail,
you need to rebuild this file to reflect the changes in the
partition.
John

What is it about Bootsect.dos that needs adjusting over a resize? Has
it grabbed the free space notation? A quick Google search shows
Bootsect.dos is mainly about IO.sys (to boot Win98), & that SYS will
restore it.

OK. This site...
http://thpc.info/dual/bootsequence.html
Boot Sequence in a Windows Dual-Boot Explained

...appears to have many answers. Everyone puzzling over a dual boot
should read it. It does state Bootsect.dos is "an image of the OS Boot
Sector Code for an OS other than XP/2K/NT", which is a PBR, &...

"A PBR, on a partition's first sector, contains a Parameter Block (or
Table) and some boot code.
The Parameter Block defines the characteristics of the partition (size,
sectors, file system, name, etc)."

So, size & number of sectors is in Bootsect.dos, which likely won't get
updated by resize. If those fields are used instead of information that
can be gleaned from the MBR or from the FAT (which also I guess might
not get updated by a resize) -- that does sound like a problem with
resize in a dual boot system. But I haven't seen anyone run into the
problem with BootItNG, that I can recall.

That site goes on to say...

"NTLDR loads the Bootsect file into memory and uses its OS Boot Sector
Code ... to boot the associated OS"

..., & not that it gets written back to the hard drive. I think it's
mainly looking for IO.sys & not for partition dimensions at this point
in the boot process. Earlier, the FAT must have gotten involved;
therefore, I still tend to think that's what Easeus missed.

[Bill Blanton]

Post by PCR

Post by PCR

Post by John John - MVP
When Windows 98 is in a dual boot configuration with NT operating
systems you will run in the same problem if you resize the W9x
partition with just about any partition tool. This was pointed out
at the start of the other discussion thread, the problem is with the
Bootsect.dos file, this file becomes invalid if the DOS/W9x partition
is resized and it will then fail to boot properly.
When arranged in a dual boot configuration with NT operating systems
the W9x boot sector is copied to the Bootsect.dos file then the NT
boot sector is written to the partition. When you boot the computer
you boot using the NT boot sector which then launches the Ntldr boot
loader, if you select to boot Windows 98 ntldr will load the
bootsect.dos file, which is a copy of the W9x boot sector, being that
the file was not updated when the partition was resized it will fail,
you need to rebuild this file to reflect the changes in the
partition.

What is it about Bootsect.dos that needs adjusting over a resize? Has
it grabbed the free space notation? A quick Google search shows
Bootsect.dos is mainly about IO.sys (to boot Win98),& that SYS will
restore it.

OK. This site...
http://thpc.info/dual/bootsequence.html
Boot Sequence in a Windows Dual-Boot Explained
...appears to have many answers. Everyone puzzling over a dual boot
should read it. It does state Bootsect.dos is "an image of the OS Boot
Sector Code for an OS other than XP/2K/NT", which is a PBR,&...
"A PBR, on a partition's first sector, contains a Parameter Block (or
Table) and some boot code.
The Parameter Block defines the characteristics of the partition (size,
sectors, file system, name, etc)."
So, size& number of sectors is in Bootsect.dos, which likely won't get
updated by resize. If those fields are used instead of information that
can be gleaned from the MBR or from the FAT (which also I guess might
not get updated by a resize) -- that does sound like a problem with
resize in a dual boot system. But I haven't seen anyone run into the
problem with BootItNG, that I can recall.

BootitNG has basic file edit capability inside its partition manager, so
it would have capability to update bootsect.dos. (if that's what it
does.. don't know)

Post by PCR
That site goes on to say...
"NTLDR loads the Bootsect file into memory and uses its OS Boot Sector
Code ... to boot the associated OS"
...,& not that it gets written back to the hard drive. I think it's
mainly looking for IO.sys& not for partition dimensions at this point
in the boot process. Earlier, the FAT must have gotten involved;
therefore, I still tend to think that's what Easeus missed.

The NT code in the volume boot sector will be loaded and those
"dimensions" used to ultimately find bootsect.dos. When bootsect.dos
loads it's pretty much a boot sector reset. The BPB inside bootsect.dos
is now used. There's no provision for the 9x code (located inside
bootsect.dos) to take into consideration any parameters that NT may have
set up.

The file is just poked into memory and jumped into just as if it was in
the boot sector. NT is finished at that point.

[PCR]

Post by Bill Blanton

Post by PCR

Post by PCR

Post by John John - MVP
When Windows 98 is in a dual boot configuration with NT operating
systems you will run in the same problem if you resize the W9x
partition with just about any partition tool. This was pointed out
at the start of the other discussion thread, the problem is with
the Bootsect.dos file, this file becomes invalid if the DOS/W9x
partition is resized and it will then fail to boot properly.
When arranged in a dual boot configuration with NT operating
systems the W9x boot sector is copied to the Bootsect.dos file
then the NT boot sector is written to the partition. When you
boot the computer you boot using the NT boot sector which then
launches the Ntldr boot loader, if you select to boot Windows 98
ntldr will load the bootsect.dos file, which is a copy of the W9x
boot sector, being that the file was not updated when the
partition was resized it will fail, you need to rebuild this file
to reflect the changes in the partition.

What is it about Bootsect.dos that needs adjusting over a resize?
Has it grabbed the free space notation? A quick Google search shows
Bootsect.dos is mainly about IO.sys (to boot Win98),& that SYS will
restore it.

OK. This site...
http://thpc.info/dual/bootsequence.html
Boot Sequence in a Windows Dual-Boot Explained
...appears to have many answers. Everyone puzzling over a dual boot
should read it. It does state Bootsect.dos is "an image of the OS
Boot Sector Code for an OS other than XP/2K/NT", which is a PBR,&...
"A PBR, on a partition's first sector, contains a Parameter Block (or
Table) and some boot code.
The Parameter Block defines the characteristics of the partition
(size, sectors, file system, name, etc)."
So, size& number of sectors is in Bootsect.dos, which likely won't
get updated by resize. If those fields are used instead of
information that can be gleaned from the MBR or from the FAT (which
also I guess might not get updated by a resize) -- that does sound
like a problem with resize in a dual boot system. But I haven't seen
anyone run into the problem with BootItNG, that I can recall.

BootitNG has basic file edit capability inside its partition manager,
so it would have capability to update bootsect.dos. (if that's what it
does.. don't know)

Now, I've done a search. Looks like David &/or Pfeifer at BootItNG
solved the problem many versions ago...

http://www.terabyteunlimited.com/kb/article.php?id=088
Cannot Boot DOS/Win9x/Me After Resizing/Converting/Sliding/Copying a
FAT/FAT32 Partition that Uses WinNT/2K/XP Boot Manager
===Quote======
Starting with version 1.26e, the BOOTSECT.DOS file will be updated.
Other files which you may have (manually) captured and (manually) setup
to work with the ntldr will not be updated.
===EOQ=======

Post by Bill Blanton

Post by PCR
That site goes on to say...
"NTLDR loads the Bootsect file into memory and uses its OS Boot
Sector Code ... to boot the associated OS"
...,& not that it gets written back to the hard drive. I think it's
mainly looking for IO.sys& not for partition dimensions at this
point in the boot process. Earlier, the FAT must have gotten
involved; therefore, I still tend to think that's what Easeus missed.

The NT code in the volume boot sector will be loaded and those
"dimensions" used to ultimately find bootsect.dos. When bootsect.dos
loads it's pretty much a boot sector reset. The BPB inside
bootsect.dos is now used. There's no provision for the 9x code
(located inside bootsect.dos) to take into consideration any
parameters that NT may have set up.
The file is just poked into memory and jumped into just as if it was
in the boot sector. NT is finished at that point.

OK. I'll accept that now, & John was right too -- seeing as BootItNG
also had a problem with that once & Easeus still does -- that the size
values in Bootsect.dos are used; it isn't just needed for IO.sys! OK,
thanks.

[Bill Blanton]

Post by J. P. Gilliver (John)
[]
I suppose there could be some aspects of an OS (98 in this case) that
have absolute addresses on the disc of where some things are, which
could confuse it if suddenly they aren't at those places any more, but
even if they don't ...
an OS has to know how big a partition it is on, so it knows where it can
write stuff: 98's own defrag, for example, puts a lot of stuff near the
end of the "disc" while it's operating, and presumably other aspects of
the OS need to know the size available too (for example whatever it is
that tells you you've run out of disc space when you try to create, or
copy in, a very large file). There are two ways this information (size
of space available) can be obtained: either the OS keeps a note,
somewhere in itself, of how much space is available, or it goes to look
every time it needs to know, either by testing or by interrogating the
partition table. If it uses the first method (a note of the size within
itself), then if someone reduces the size "without telling it",
something will break. (Thinking about it, it cold even write outside its
own partition and corrupt what is now in the next partition.) Both
methods have their disadvantages: storing the information locally is
prone to changes external to the OS breaking it, but having to check
externally (potentially at every disc write) cold have a significant
performance hit.
I don't know which method '9x uses to "know" how big a partition it's
operating in; if it does use an "internal note" (and if it uses internal
notes of absolute disc positions of anything), then any partition
managing software that is going to be able to safely relocate/resize it
is going to have to have internal knowledge of the OS, and adjust those
internal notes.

FAT32 keeps a record of the free cluster count and the next free cluster
on disk in the FSInfo sector. FAT and FAT12 don't keep this record on disk.

The partition size and location are kept in the partition table as
absolute values. The volume size (which should match the partition table
size value) is kept in the volume boot sector as a sector count. There's
no location value in the boot sector to say where itself is. Volume boot
sector pointers to the FAT, root dir cluster, and the backup boot sector
are all relative to the start of the partition/volume.

Moving a FAT partition should be easy. Just adjust the values in the
partition table and move the bytes.

If you resize, you have to adjust the FAT size. If FAT"16" then also
take into consideration the relative fixed location of the root dir and
move that. "In the way" file and dir clusters, immediately following
the FATs, have to be moved.,, You need to keep track of the data
clusters that are being moved so you can update the FAT's cluster
pointers. If your partition manager offers, and you accept to change the
cluster size along with everything else, then pray ;-)

It's not impossible of course, but whenever I want to resize a volume I
prefer to create a new empty volume and copy the files over, and/or
clone the volume before the resize. Of course many times you don't have
the luxury of that much space.

[Hot-Text]

Post by Bill Blanton

Post by J. P. Gilliver (John)
[]
I suppose there could be some aspects of an OS (98 in this case) that
have absolute addresses on the disc of where some things are, which
could confuse it if suddenly they aren't at those places any more, but
even if they don't ...
an OS has to know how big a partition it is on, so it knows where it can
write stuff: 98's own defrag, for example, puts a lot of stuff near the
end of the "disc" while it's operating, and presumably other aspects of
the OS need to know the size available too (for example whatever it is
that tells you you've run out of disc space when you try to create, or
copy in, a very large file). There are two ways this information (size
of space available) can be obtained: either the OS keeps a note,
somewhere in itself, of how much space is available, or it goes to look
every time it needs to know, either by testing or by interrogating the
partition table. If it uses the first method (a note of the size within
itself), then if someone reduces the size "without telling it",
something will break. (Thinking about it, it cold even write outside its
own partition and corrupt what is now in the next partition.) Both
methods have their disadvantages: storing the information locally is
prone to changes external to the OS breaking it, but having to check
externally (potentially at every disc write) cold have a significant
performance hit.
I don't know which method '9x uses to "know" how big a partition it's
operating in; if it does use an "internal note" (and if it uses internal
notes of absolute disc positions of anything), then any partition
managing software that is going to be able to safely relocate/resize it
is going to have to have internal knowledge of the OS, and adjust those
internal notes.

FAT32 keeps a record of the free cluster count and the next free cluster
on disk in the FSInfo sector. FAT and FAT12 don't keep this record on disk.
The partition size and location are kept in the partition table as
absolute values. The volume size (which should match the partition table
size value) is kept in the volume boot sector as a sector count. There's
no location value in the boot sector to say where itself is. Volume boot
sector pointers to the FAT, root dir cluster, and the backup boot sector
are all relative to the start of the partition/volume.
Moving a FAT partition should be easy. Just adjust the values in the
partition table and move the bytes.
If you resize, you have to adjust the FAT size. If FAT"16" then also take
into consideration the relative fixed location of the root dir and move
that. "In the way" file and dir clusters, immediately following the FATs,
have to be moved.,, You need to keep track of the data clusters that are
being moved so you can update the FAT's cluster pointers. If your
partition manager offers, and you accept to change the cluster size along
with everything else, then pray ;-)
It's not impossible of course, but whenever I want to resize a volume I
prefer to create a new empty volume and copy the files over, and/or clone
the volume before the resize. Of course many times you don't have the
luxury of that much space.

But create a new empty volume and clone the old volume to the new empty
volume is the Right Way to do it Always for Win98!