Jump to content

phelum

Member
  • Posts

    5
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Australia

Everything posted by phelum

  1. Your suggestion of patching NT4 so it recognises type 0F partitions sounds good but I don't know where I'd start. The good thing about my workaround is that I can have a type 05 partition and that CHS only systems (e.g. DOS) can access volumes before cylinder 1024. NT4 and above and the 32-bit disk code in Win9x can access the entire partition. So, there seems to be good support for type 05 partitions that exceed cylinder 1024. The only problem with this non-standard and yet very accessible arrangement is the Win9x IO.SYS. I don't think it's fair to talk about an NT problem. NT has always used LBA addressing even for type 05 partitions. Perhaps type 0F wasn't defined back in those days. I think the NT developers did well sticking to type 05 for backwards compatibility and letting it exceed 8.4GB so we could use the new larger drives. Cheers,
  2. My hard drive contained an extended partition (type 05) that was about 30GB. This partition contained CHS accessible volumes before cylinder 1023 and others (NTFS and FAT32) from cylinder 1024 onwards. There was a FAT32 volume before cylinder 1023 and I would get a phantom drive in Win98 if I set this volume's type to 0C. A simple test to show the problem is to create an extended partition (type 05) on a drive and add a type 0C (FAT32 LBA) volume. IO.SYS will double the start key whereas the 32-bit disk code in Win98 gets it right. I realise that type 05 partitions shouldn't exceed cylinder 1023 but I had to use 05 not 0F for NT4 compatibility. Also, all LBA keys must be correct. I didn't see this as a problem because NT always uses LBA keys and my partitioning program ensured they were correct. But, this might cause problems in setups that rely/use CHS only. The recent comment that an LBA extended partition should contain only LBA volumes might explain why IO.SYS works the way it does. Cheers, Steven Saunderson
  3. I can see that my patch has had an unwanted side-effect. I didn't hit a problem because my extended partitions are all type 05 whether CHS or LBA. I need this type because NT4 doesn't recognise type 0F. I put a dummy partition at cylinder 1023 so systems that use CHS don't see anything after. NT systems always use LBA so they continue down the chain and find subsequent partitions. Win98SE does find FAT32 partitons after cylinder 1023. Thanks for the update to my patch and the interest in it. Cheers, Steven Saunderson
  4. Thanks for the update and the welcome. Yes, misunderstanding is one of my acquired skills. I'm glad that the patch has helped someone. I can't see why the key calcs were wrong in the first place but I did worry that the patch might break some existing disk setups. I'm still using this IO.SYS in multi-boot (DOS, W98, W2k) systems that I support. Cheers,
  5. It might be identical but I doubt it. KB 311561 talks about hard error detection whereas my change fixes a software error that doubled the start key of a partition. The patched IO.SYS relies totally on the LBA keys in the partition records even for CHS partitions. Perhaps this break from the specifications caused the drive letter problem reported above. I can't really add any mention for Win98FE in my page because I've never tested it. Cheers,
×
×
  • Create New...