If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#31
|
|||
|
|||
Folow-up on Can't boot win98! Sectors not found Dos error, right?
Mr. PCR
I burn up my free post at aioe so I at a new IP LOOL No partitioning & resizing, Just a BOOTER! I going to plug my USB WinTV in to the Voodoo TV card on that PC and make a video of the setup of the GAG. For it is just a Boot manager, it's good for, if you copy a OS from one HDD C: to Sec. HDD D: The GRAPHICAL BOOT MANAGER will open it as if it's on C: all partitions can be C: HDD 2gb Win95, HDD 20gb win98, HDD 30gb WinME, HDD 40gb win2000, Buy a HDD 130gb, make 5 partitions copy to the OS to the partitions and it can be the 2000 first for GAG will Boot All as if on C: cool toy Hmm |
#32
|
|||
|
|||
Folow-up on Can't boot win98! Sectors not found Dos error, right?
In message , John John - MVP
writes: On 11/29/2010 9:26 PM, PCR wrote: J. P. Gilliver (John) wrote: [] 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.) -- J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf "So, I take it you've ... been with a man before?" "I'm a virgin. I'm just not very good at it." Topper Harley & Ramada Thompson (Charlie Sheen & Valeria Golino), in "Hot Shots!" (1991). |
#33
|
|||
|
|||
Folow-up on Can't boot win98! Sectors not found Dos error, right?
Hot-Text wrote:
Mr. PCR I burn up my free post at aioe so I at a new IP LOOL If you say so, but you're properties still say... Organization: Aioe.org NNTP Server No partitioning & resizing, Just a BOOTER! OK. That's what it looked like, yeah. I going to plug my USB WinTV in to the Voodoo TV card on that PC and make a video of the setup of the GAG. They showed pictures of it at the site you posted. It looked OK. For it is just a Boot manager, it's good for, if you copy a OS from one HDD C: to Sec. HDD D: The GRAPHICAL BOOT MANAGER will open it as if it's on C: Very good. BootItNG can do that too. all partitions can be C: HDD 2gb Win95, HDD 20gb win98, HDD 30gb WinME, HDD 40gb win2000, Buy a HDD 130gb, make 5 partitions copy to the OS to the partitions and it can be the 2000 first for GAG will Boot All as if on C: cool toy Hmm Very nice. Glad you found something to keep you busy & to enjoy. -- Thanks or Good Luck, There may be humor in this post, and, Naturally, you will not sue, Should things get worse after this, PCR |
#34
|
|||
|
|||
Folow-up on Can't boot win98! Sectors not found Dos error, right?
John John - MVP wrote:
On 11/29/2010 9:26 PM, PCR wrote: J. P. Gilliver (John) wrote: In , writes: mm wrote: [] 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. an OS has to know how big a partition it is on, so it knows where it can write stuff: That seems reasonable to me. There may be BIOS& onboard HDD firmware involved too, but surely the OS needs to know. 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. 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. 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). (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. 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. 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. -- Thanks or Good Luck, There may be humor in this post, and, Naturally, you will not sue, Should things get worse after this, PCR |
#35
|
|||
|
|||
Folow-up on Can't boot win98! Sectors not found Doserror, right?
On 11/28/2010 03:45, J. P. Gilliver (John) wrote:
[] 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. |
#36
|
|||
|
|||
Folow-up on Can't boot win98! Sectors not found Doserror, right?
On 12/2/2010 02:05, PCR wrote:
John John - MVP wrote: On 11/29/2010 9:26 PM, PCR wrote: J. P. Gilliver (John) wrote: In , writes: mm wrote: [] 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. an OS has to know how big a partition it is on, so it knows where it can write stuff: That seems reasonable to me. There may be BIOS& onboard HDD firmware involved too, but surely the OS needs to know. 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. 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. 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). (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. 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. 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. |
#37
|
|||
|
|||
Folow-up on Can't boot win98! Sectors not found Dos error, right?
PCR wrote:
John John - MVP wrote: On 11/29/2010 9:26 PM, PCR wrote: J. P. Gilliver (John) wrote: In , writes: mm wrote: [] 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. an OS has to know how big a partition it is on, so it knows where it can write stuff: That seems reasonable to me. There may be BIOS& onboard HDD firmware involved too, but surely the OS needs to know. 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. 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. 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). (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. 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. 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. -- Thanks or Good Luck, There may be humor in this post, and, Naturally, you will not sue, Should things get worse after this, PCR |
#38
|
|||
|
|||
Folow-up on Can't boot win98! Sectors not found Dos error, right?
Bill Blanton wrote:
On 12/2/2010 02:05, PCR wrote: John John - MVP wrote: On 11/29/2010 9:26 PM, PCR wrote: J. P. Gilliver (John) wrote: In , writes: mm wrote: [] 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. an OS has to know how big a partition it is on, so it knows where it can write stuff: That seems reasonable to me. There may be BIOS& onboard HDD firmware involved too, but surely the OS needs to know. 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. 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. 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). (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. 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. 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. -- Thanks or Good Luck, There may be humor in this post, and, Naturally, you will not sue, Should things get worse after this, PCR |
#39
|
|||
|
|||
Folow-up on Can't boot win98! Sectors not found Dos error, right?
"Bill Blanton" wrote in message ng.com... On 11/28/2010 03:45, J. P. Gilliver (John) wrote: [] 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! |
#40
|
|||
|
|||
Folow-up on Can't boot win98! Sectors not found Doserror, right?
On 12/3/2010 00:43, PCR wrote:
PCR wrote: John John - MVP wrote: 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) 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. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
HDD suddenly has bad sectors | johncandeyy | General | 2 | January 24th 09 04:16 PM |
Restore Win98 boot from dual boot | Michael Fisher | General | 2 | February 4th 07 03:48 AM |
Bad Sectors | sheppardwk | Improving Performance | 10 | November 8th 04 09:08 PM |
win98 boot up error | Phil | General | 4 | September 26th 04 10:08 PM |
bad sectors | archana | Disk Drives | 3 | September 20th 04 04:34 AM |