 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Forum / Windows 98 / General Topics / April 2007ESDI_506.PDR used in boot to command prompt?
The recent threads on large hard drives in Win98SE prompt me to ask the following question: is ESDI_506.PDR used for hard drive access when one boots only to the command prompt (or exits Win98 to DOS mode)? Since this file is not present on a standard Win98 boot floppy, is there danger to data on a large hard drive if it is accessed from floppy boot? --Donald Davis  Signature--Donald Davis [To respond by e-mail, remove "blackhole." from the address.] > The recent threads on large hard drives in Win98SE prompt me to > ask the following question: is ESDI_506.PDR used for hard drive access > when one boots only to the command prompt (or exits Win98 to DOS mode)? > Since this file is not present on a standard Win98 boot floppy, is there > danger to data on a large hard drive if it is accessed from floppy boot? Dos uses BIOS calls to access the drive. So if the BIOS is LBA48 compliant (after +/- 2001) you can access the drive from Dos. (Not from a dosbox). > The recent threads on large hard drives in Win98SE prompt me to > ask the following question: is ESDI_506.PDR used for hard drive [quoted text clipped - 3 lines] > is there danger to data on a large hard drive if it is accessed > from floppy boot? You are correct. If you boot a machine with a win-98 dos boot floppy (NOT dos 6.22), and if that machine has a large hard drive (larger than 137 gb) formatted as fat-32, then you can access that drive, read and write to it no problem. The only proviso is that the bios must have 48-bit LBA support, which means any motherboard made during or after 2002 or 2003. > The recent threads on large hard drives in Win98SE prompt me to > ask the following question: is ESDI_506.PDR used for hard drive access [quoted text clipped - 7 lines] > > [To respond by e-mail, remove "blackhole." from the address.] ESDI_506.PDR is NOT used in true (boot to) DOS mode. The consensus is that with a BIOS capable of 48-bit LBA support no damage will be done accessing large drives, but you may want to look at this anyway. MS-DOS Does Not Properly Process Hard Disk Hardware Errors http://support.microsoft.com/?kbid=311561 > but you may want to look at this anyway: > > MS-DOS Does Not Properly Process Hard Disk Hardware Errors > http://support.microsoft.com/?kbid=311561 I'm thinking that "modern" hard drives perform sector monitoring and re-mapping and can take care of most read/write problems silently, so the issue being addresses by that bulletin is probably of no concern. The bulletin is referencing this, however: 311561USA8.EXE Which is basically a replacement for winboot.sys. Does anyone know what that file is, and what it's role is in win-98(se) operation? I have it in \windows\setup (04/23/99) and \windows\options\cabs (12/1/01) but nowhere else. >> but you may want to look at this anyway: >> [quoted text clipped - 10 lines] > >Which is basically a replacement for winboot.sys. AFAICT, winboot.98s replaces io.sys and winboot.sys in the root, cabs, and command directories according to the instructions in the 98SE_chk.inf file (see below). >Does anyone know what that file is, and what it's role is in >win-98(se) operation? I don't have this file anywhere on my system, but then I haven't installed the update. >I have it in \windows\setup (04/23/99) and \windows\options\cabs >(12/1/01) but nowhere else. Here is an edited excerpt form 98SE_chk.inf: [DestinationDirs] ; 10=Windows,... 13=COMMAND, ... ; ... 30=Boot drv root, ... W98.SE.Copy.Root = 30 W98.SE.Copy.Options = 10, options\cabs W98.SE.Copy.COMMAND.EBD = 13, EBD [W98.SE.Copy.COMMAND.EBD] io.SYS,winboot.98s,,32 [W98.SE.Copy.Options] winboot.SYS,winboot.98s,,32 [W98.SE.Copy.Root] io.sys,winboot.98S,,32 - Franc Zabkar SignaturePlease remove one 'i' from my address when replying by email. ***Replies inline*** >> but you may want to look at this anyway: >> [quoted text clipped - 10 lines] > > Which is basically a replacement for winboot.sys. ***No it's a replacement for io.sys and winboot.sys*** > Does anyone know what that file is, and what it's role is in > win-98(se) operation? ***IO.SYS file is automatically renamed to WINBOOT.SYS (in Win95 and Win98) if you start the computer using the boot menu option to start "Previous version of MS-DOS" (COMMAND.COM, MSDOS.SYS, AUTOEXEC.BAT and CONFIG.SYS are given the extension ".W40" after them, in that scenario). WINBOOT.SYS is also created during the installation of Win95 and Win98, but is renamed at the end of setup (see your setuplog.txt).*** > I have it in \windows\setup (04/23/99) and \windows\options\cabs > (12/1/01) but nowhere else. ***The .inf file in the update mentioned, and quoted by Franc in his reply, copies the updated file to the COMMAND\EBD folder and to the Root, renaming it to IO.SYS; and copies it to the OPTIONS\CABS folder as WINBOOT.SYS. Those are the usual locations for IO.SYS and WINBOOT.SYS, respectively.*** SignatureGlen Ventura, MS MVP Shell/User, A+ http://dts-l.org/ http://dts-l.org/goodpost.htm > ***IO.SYS file is automatically renamed to WINBOOT.SYS ... > > ***The .inf file in the update mentioned, and quoted by Franc in > his reply, copies the updated file to the COMMAND\EBD folder and > to the Root, renaming it to IO.SYS; and copies it to the OPTIONS\ > CABS folder as WINBOOT.SYS. Ok, so on my system: c:\io.sys is identical to c:\windows\setup\winboot.sys (4/23/99 from win98 cd) and c:\windows\command\ebd\io.sys is identical to c:\windows\options\cabs\winboot.sys (12/01/01) So what does all that mean? Should my C:\io.sys really be the 12/01/01 version then? >> ***IO.SYS file is automatically renamed to WINBOOT.SYS ... >> [quoted text clipped - 18 lines] > > Should my C:\io.sys really be the 12/01/01 version then? Hmmm....wonder how it got that way. If the update was installed, per the .inf file, c:\io.sys should be the same version as the one you see in the EBD and Cabs folders....unless you did something later that restored the copy in the root to the original version. Did you in fact ever install that update on the computer you are looking at? SignatureGlen Ventura, MS MVP Shell/User, A+ http://dts-l.org/ http://dts-l.org/goodpost.htm > > c:\io.sys > > is identical to [quoted text clipped - 10 lines] > original version. Did you in fact ever install that update > on the computer you are looking at? Now that you mention it, I vaguely remember encountering this update. I see that I downloaded it last July. In fact, I'm sure that I did, and after installing it, my system wouldn't boot any more, and hence I replaced the io.sys file with the original. >> > c:\io.sys >> > is identical to [quoted text clipped - 15 lines] > and after installing it, my system wouldn't boot any more, and hence I > replaced the io.sys file with the original. Aren't you one of the folks using 98Lite or whateveritsnameis? If so, that might explain the failure to boot with the updated file. SignatureGlen Ventura, MS MVP Shell/User, A+ http://dts-l.org/ http://dts-l.org/goodpost.htm > "98 Guy" <98@Guy.com> wrote in message >> [quoted text clipped - 5 lines] > Aren't you one of the folks using 98Lite or whateveritsnameis? If so, > that might explain the failure to boot with the updated file. Do you know a reason why 98lite wouldn't boot with an updated io.sys? >> "98 Guy" <98@Guy.com> wrote in message >>> [quoted text clipped - 7 lines] > > Do you know a reason why 98lite wouldn't boot with an updated io.sys? No, I don't, as I do not use 98lite. All I know about it is that it removes integrated IE from the OS, and possibly removes or changes some system files and replaces them with files from earlier or later versions of Win9x. In such a scenario, it would not be unlikely for a specific updated file from MS to run into some incompatibility. As I have no intention of running or supporting 98lite, I can't test it, and leave that to those that are. SignatureGlen Ventura, MS MVP Shell/User, A+ http://dts-l.org/ http://dts-l.org/goodpost.htm On Sun, 8 Apr 2007 19:12:15 -0400, "glee" <glee29@spamindspring.com> >"Ingeborg" <a@b.invalid> wrote in message >>> "98 Guy" <98@Guy.com> wrote in message >>> Aren't you one of the folks using 98Lite or whateveritsnameis? If so, >>> that might explain the failure to boot with the updated file. >> Do you know a reason why 98lite wouldn't boot with an updated io.sys? >No, I don't, as I do not use 98lite. Neither do I, given the scopes are unlikely to overlap. 98Lite will affect the shell, which runs the GUI, whereas my the time the GUI starts to load, IO.SYS's job is done. >--------------- ------- ----- ---- --- -- - - - - Sucess-proof your business! Tip #37 When given an NDA to sign, post it on your web site >--------------- ------- ----- ---- --- -- - - - - > On Sun, 8 Apr 2007 19:12:15 -0400, "glee" <glee29@spamindspring.com> >>"Ingeborg" <a@b.invalid> wrote in message [quoted text clipped - 10 lines] > affect the shell, which runs the GUI, whereas my the time the GUI > starts to load, IO.SYS's job is done. Ah, you're right, of course. I thought 98Lite might have made other changes at a lower level, but if it only affects the shell, then it should not be a factor. Thanks, Chris. SignatureGlen Ventura, MS MVP Shell/User, A+ http://dts-l.org/ http://dts-l.org/goodpost.htm To subject line: No, a true DOS Mode boot won't use ESDI_506.PDR Sorry to jump in late... >> > c:\io.sys >> > is identical to >> > c:\windows\setup\winboot.sys (4/23/99 from win98 cd) A Winboot.sys dropped into C:\ will replace C:\IO.SYS with itself on boot, an effect which may be coded into the Win9x PBR logic. So that is prolly what that Winboot.sys is, and why it is there; it's the future IO.SYS to be asserted during OS installation. >> > c:\windows\command\ebd\io.sys >> > is identical to >> > c:\windows\options\cabs\winboot.sys (12/01/01) OK. Is c:\windows\command\ebd\io.sys = c:\io.sys ? >> Hmmm....wonder how it got that way. If the update was installed, >> per the .inf file, c:\io.sys should be the same version as the >> one you see in the EBD and Cabs folders....unless you did >> something later that restored the copy in the root to the >> original version. Did you in fact ever install that update >> on the computer you are looking at? >Now that you mention it, I vaguely remember encountering this update. >I see that I downloaded it last July. In fact, I'm sure that I did, >and after installing it, my system wouldn't boot any more, and hence I >replaced the io.sys file with the original. I'm in catch-up mode. What's the context here? If... - a patch is applied to overcome a HD capacity limit - this patch alters IO.SYS to fix DOS mode - the existing installation has an over-limit HD - the existing installation uses HD as within-limit ...then I may expect your mileage, i.e. applying the patch causes the system not to work. You can also have problems in these sort of contexts, where the earliest part of the OS is capacity-limited, and cannot "reach" a file needed to load the OS to the point the limit no longer applies. A good way to avoid much of this BS is to ensure the OS's C: volume does not cross any capacity limits that may apply. >-------------------- ----- ---- --- -- - - - - Tip Of The Day: To disable the 'Tip of the Day' feature... >-------------------- ----- ---- --- -- - - - - > > Now that you mention it, I vaguely remember encountering this > > update. I see that I downloaded it last July. In fact, I'm [quoted text clipped - 3 lines] > > I'm in catch-up mode. What's the context here? This thread took a left turn when I raised this: 311561USA8.EXE And we started to talk about what winboot.sys is for. Last July, I ran 311561USA8.EXE (for the hell of it - not to solve any particular problem) and my system failed to boot. I replaced io.sys manually with the previous version to remedy the situation. And no, I've never run any of the third-party win-98 service packs on the system in question. > A good way to avoid much of this BS is to ensure the OS's > C: volume does not cross any capacity limits that may apply. I plan to set up a win-98se system with a couple of 500 gb Western Digital (WD5000KS) formatted with 4 kb cluster size. [I've just finished setting up an XP-pro system for multi-media and video editing. I installed XP and all the software on a 250 gb drive formatted with FAT-32 (4kb cluster size). All application software came from torrents (including serials and keygens). The system runs pretty snappy!] >> I'm in catch-up mode. What's the context here? > >This thread took a left turn when I raised this: > >311561USA8.EXE http://support.microsoft.com/kb/311561 Long thread, off this topic maybe, nice forum: http://www.msfn.org/board/lofiversion/index.php/t52189-50.html Also off-topic for this thread, but looks interesting: http://www.msfn.org/board/index.php?act=Print&client=printer&f=8&t=53392 >And we started to talk about what winboot.sys is for. I've always considered this an exploit waiting to be triggered - that any malware can grab the system simply by dropping a hostile DOS executable named WINBOOT.SYS into C:\ and forcing a reboot. The code wouldn't even have DOS services available, as it is loading instead of the DOS kernel, but that's great for low-level disk access etc. >Last July, I ran 311561USA8.EXE (for the hell of it - not to solve any >particular problem) and my system failed to boot. I replaced io.sys >manually with the previous version to remedy the situation. >> A good way to avoid much of this BS is to ensure the OS's >> C: volume does not cross any capacity limits that may apply. >I plan to set up a win-98se system with a couple of 500 gb Western >Digital (WD5000KS) formatted with 4 kb cluster size. Good luck... I wouldn't go there, or rather, I wouldn't take anything with me that I wanted to see again. Defragging will be hell... >[I've just finished setting up an XP-pro system for multi-media and >video editing. I installed XP and all the software on a 250 gb drive >formatted with FAT-32 (4kb cluster size). All application software >came from torrents (including serials and keygens). The system runs >pretty snappy!] I'm also using FAT32 with 4k clusters, but I prefer to attain these with a C: that's under 8G, rather than non-standard cluster scaling and massive FATs. Other volumes, other file systems; 2G FAT16 for the benefit of large clusters, then either huge FAT32 or NTFS, depending on whether or not I need support for files > 4G. I tested various file systems when building a Win2000-based video editing system a while back. FAT32 32G or less was fastest, followed by FAT32 at max size (45G HDs), followed by NTFS. The tests were orientated to streaming video. Results may be different in other contexts, e.g. > 10 000 files in one directory, where FATxx's linear lookup may hurt more than NTFS's permissions and other metadata navel-gazing. Er... the volume that this patch crashed on; was it using non-standard cluster sizes via a "special" format, by some chance? Was it > 137G? >------------ ----- ---- --- -- - - - - The most accurate diagnostic instrument in medicine is the Retrospectoscope >------------ ----- ---- --- -- - - - - > > Last July, I ran 311561USA8.EXE (for the hell of it - not to > > solve any particular problem) and my system failed to boot. [quoted text clipped - 4 lines] > standard cluster sizes via a "special" format, by some chance? > Was it > 137G? The volume in question is a standard fat32 volume (40 gb) on an 80 gb drive (the remainder of the drive space is unallocated). >> > Last July, I ran 311561USA8.EXE (for the hell of it - not to >> > solve any particular problem) and my system failed to boot. >> > I replaced io.sys manually with the previous version to remedy >> > the situation. >> Er... the volume that this patch crashed on; was it using non- >> standard cluster sizes via a "special" format, by some chance? >> Was it > 137G? >The volume in question is a standard fat32 volume (40 gb) on an 80 gb >drive (the remainder of the drive space is unallocated). OK. Default or "special" cluster size? At 40G, the default cluster size would most likely be 16k. >---------- ----- ---- --- -- - - - - Do it once, properly >---------- ----- ---- --- -- - - - - >>>>Last July, I ran 311561USA8.EXE (for the hell of it - not to >>>>solve any particular problem) and my system failed to boot. [quoted text clipped - 10 lines] > OK. Default or "special" cluster size? At 40G, the default cluster > size would most likely be 16k. I think default 32K clusters start at 32GB. John > > > The volume in question is a standard fat32 volume (40 gb) on > > > an 80 gb drive (the remainder of the drive space is > > > unallocated). > > > > OK. Default or "special" cluster size? At 40G, the default > > cluster size would most likely be 16k. Yes, default cluster size. > I think default 32K clusters start at 32GB. Yes, 32k cluster size. >> cquirke: >> > OK. Default or "special" cluster size? At 40G, the default >> > cluster size would most likely be 16k. > >Yes, default cluster size. >> I think default 32K clusters start at 32GB. >Yes, 32k cluster size. Yep - my bad, I forgot the 16G rollover point! This is interesting... http://support.microsoft.com/kb/314878 ...as it mentions FAT16 with 128k and 256k clusters (supported by NT4 only) for FAT16 volumes up to 8G and 16G, respectively. Prior to this article, I was aware of 64k clusters for 2G to 4G FAT16 volumes that worked only with NT, but this was new news! >--------------- ----- ---- --- -- - - - Tech Support: The guys who follow the 'Parade of New Products' with a shovel. >--------------- ----- ---- --- -- - - - >>>cquirke: > [quoted text clipped - 18 lines] > Prior to this article, I was aware of 64k clusters for 2G to 4G FAT16 > volumes that worked only with NT, but this was new news! News to me too. I didn't think you could format a FAT16 disk larger than 4GB. I don't know what the point of it is, especially the 256KB clusters. Due to the BIOS Int-13 limitations NT4 cannot boot off a disk larger than 7.8GB and data volumes are usually formated NTFS, I really don't see the use of FAT volumes of 8 or 16GB! I think that these large clusters might be meant for disks with non standard 512-byte sector sizes. In the Windows NT Server Resource Kit the following information is given: "However, the maximum cluster size that you can use for FAT volumes when running Windows NT is 64K, when using a 512 byte sector size. Therefore, the maximum size for a FAT volume is 4 GB." Windows NT Server Resource Kit Chapter 3 - Disk Management Basics http://www.microsoft.com/resources/documentation/windowsnt/4/server/reskit/en-us /resguide/diskover.mspx?mfr=true John >>>>cquirke: >>>>>OK. Default or "special" cluster size? At 40G, the default >>>>>cluster size would most likely be 16k. [quoted text clipped - 22 lines] > > I think that these large clusters might be meant for disks with non standard 512-byte sector sizes. If you look below the table in http://support.microsoft.com/kb/314878 it does confirm that.. " To support FAT partitions that are greater than 4 GB using 128- or 256-KB clusters, the drives must use sectors that are greater than 512 bytes. " News to me too. However, to support 256K clusters, the drive would have to use greater than 1K clusters. (there exists a one byte field in the BPB of a FAT volume that defines "Sectors per cluster", and 256 (100h) just won't fit.). But then why stop at 256K? If for example, your storage media has 4K sectors. 512K should be easy. > In the Windows NT Server Resource Kit the following information is given: > "However, the maximum cluster size that you can use for FAT volumes when running Windows NT is 64K, when using a 512 byte sector > size. Therefore, the maximum size for a FAT volume is 4 GB." > > Windows NT Server Resource Kit > Chapter 3 - Disk Management Basics > http://www.microsoft.com/resources/documentation/windowsnt/4/server/reskit/en-us /resguide/diskover.mspx?mfr=true On Thu, 12 Apr 2007 11:04:11 -0300, John John <audetweld@nbnet.nb.ca> >> http://support.microsoft.com/kb/314878 >> [quoted text clipped - 3 lines] >> Prior to this article, I was aware of 64k clusters for 2G to 4G FAT16 >> volumes that worked only with NT, but this was new news! >News to me too. I didn't think you could format a FAT16 disk larger >than 4GB. I don't know what the point of it is, especially the 256KB >clusters. Due to the BIOS Int-13 limitations NT4 cannot boot off a disk >larger than 7.8GB and data volumes are usually formated NTFS, I really >don't see the use of FAT volumes of 8 or 16GB! Oh, I dunno - I'd rather do the opposite; keep data OFF NTFS so that it's more recoverable if something goes wrong, and use NTFS for the OS (if I have to), perhaps as an attempt to control code behavior. As the only user of a physically-secured PC, I'm far less interested in blocking data visibility than enhancing data survivability, and clusters large enough to swallow data files whole could be good there, in that the files will survive even if both FATs are lost. >------------ ----- ---- --- -- - - - - The most accurate diagnostic instrument in medicine is the Retrospectoscope >------------ ----- ---- --- -- - - - - > Oh, I dunno - I'd rather do the opposite; keep data OFF NTFS so > that it's more recoverable if something goes wrong, Exactly. As well, fat-32 performance is just as good as, if not slightly better, than NTFS. > and use NTFS for the OS (if I have to) You don't have too. Not for 2K or XP anyways... > and clusters large enough to swallow data files whole could be > good there, in that the files will survive even if both FATs > are lost. Well, you don't have to go that far. Files can be reconstructed from their chains. As well, you can format huge partitions with fat-32 using small cluster size (4kb) using third-party drive tools and OS's like XP install and run just fine. I've done it with a recent install of XP on a 250 gb SATA drive. >> Oh, I dunno - I'd rather do the opposite; keep data OFF NTFS so >> that it's more recoverable if something goes wrong, >Exactly. As well, fat-32 performance is just as good as, if not >slightly better, than NTFS. It depends. NTFS is faster than FATxx if there are a large number of files in a directory, thanks to the more efficient indexed directory structure. Other factors tend to favor FATxx. >> and use NTFS for the OS (if I have to) >You don't have too. Not for 2K or XP anyways... You do in Vista. You can end up with Vista installed and running on FATxx, e.g. if you apply a Vista installation image via ImageX onto a FAT32 volume, but it won't work properly; various things break. I found this out by accident, by doing this... - BING; create a FAT32 C: - WinPE; use Convert to convert C: to NTFS - WinPE; apply installation image via ImageX - boot HD into Vista The reason the problem arises, is because Convert silently does nothing, i.e. appears to convert to NTFS successfully, but the volume is still left as FAT32. So now I Format C: /FS:NTFS instead. My policy is to use NTFS for Vista C: and FAT32 for XP C: >> and clusters large enough to swallow data files whole could be >> good there, in that the files will survive even if both FATs >> are lost. >Well, you don't have to go that far. Files can be reconstructed from >their chains. That presupposes survival of the FATs, or at least survival of enough sectors from FAT1 and FAT2 to rebuild a complete FAT. Else you can assume unfragmented chains and apply a flat FAT, but if everything fits in one cluster, you don't have to rely on that assumption. >As well, you can format huge partitions with fat-32 using small >cluster size (4kb) using third-party drive tools and OS's like XP >install and run just fine. I've done it with a recent install of XP >on a 250 gb SATA drive. Yep, but I like that approach considerably less. You may well find that what you save in slack space, you lose in huge FATs, plus those huge FATs may impact memory usage. I usually use a 2G FAT16 volume for small data that is to enjoy maximum survivability. The data that lives there is usually < 1G in size, and in the context of a 320G HD, using a 1G FAT16 for less cluster bloat and shorter head travel past the volume isn't a biggie. >---------- ----- ---- --- -- - - - - Proverbs Unscrolled #37 "Build it and they will come and break it" >---------- ----- ---- --- -- - - - - |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.