rloew

Version 4.10.2226 of ESDI_506.PDR is identical to Version 4.10.2225 with the addition of some Power Management commands. I have isolated the Code changes. It has been discussed on this forum years ago. No one recommended it unless they had the specific problem it was designed to fix. Otherwise it appears to work the same as the previous version. I do not know why Microsoft removed it.

That's why I said to use "ignore" to step over errors without changing anything. At some point it should report that the available space is incorrectly set. Fixing it is an entirely different issue.

Ok, how's this? I accidentally gave the number of sectors in hex. It should have been 30784 or a little less than 16MB. I looked at what you sent. It appears that the free space count in the second PBR sector is one less than it should be. Windows 9X used the value and computed the allocation. Windows XP may have scanned the Partition and determined the true allocation. Try SCANDISK again. If you don't want to make changes, use "ignore" to go to the next step after each error.

Just for the record, not on the DOS/Win9x bootsector, and should not on any apps, but the NT bootsector does use some of the CHS data, on bothe NTFS and FAT32 partition type: http://www.911cd.net/forums//index.php?sho...1702&st=129 http://www.boot-land.net/forums/index.php?...=8528&st=21 However nothing of the above seemingly "justifies" the different number of used space , at the most it can explain why the scandisk warning/error. jaclaz The partition was not bootable, so the NT Boot Sector code is not used. I did check the NT Boot Sector Code. It would have used CHS if the Partition were Bootable. The Code never checks the Partition Type. The NTLDR code in Partition Sector 12 is missing but doesn't matter in this case.

Hacking the NAS may or may not be possible. I returned the drive my original post. My point was that newer NAS drives were coming out that are no longer compatable with Windows 9X. Some other drives, such as the Coolmax CN-300 can be accessed from Windows 9X, but incorrectly handle short filenames causing potential name conflicts. I finally settled on the Coolmax CN-330 dual enclosure. So far I haven't seen a NAS drive that uses the same method of reporting Short Filenames as does DOS and Windows 9X. The two Coolmax Enclosures use the format internally but neither use it externally. The CN-330 uses a six letter hash. My old LS-160 uses a two letter hash. I would be interested in knowing what, if any, NAS enclosure uses the standard short file names externally.

The MBR is a non-bootable one. (containing the string "Pen Drive Without Operating System.Remove Pen Drive And Reboot. "). The partition is a FAT32 0C type, NOT Active, with really "weird" CHS/LBA data Entry Type Boot bCyl bHead bSect eCyl eHead eSec StartSector NumSectors #0 0C 00 0 3 4 242 121 58 192 15673152 The CHS/LBA data is NOT "balanced", AND it breaks any known "standard" or "convention". If we give as "good" the CHS, the LBA should be 192/3.895.219. If we give as good the LBA, the CHS should be 0/3/4 975/158/15. The "right" values should be: 0/1/1 974/254/63 63/15663312 The PBR it's a "normal" FAT32 bootsector invoking NTLDR, but it uses a geometry of 128/63 instead of the "usual" 255/63. It is not strange that any tool/utility reports "something wrong" in the boot DATA. jaclaz The Partition's CHS entries and Geometry are strange but have no effect since a Type "0C" Partition is a LBA Accessed FAT32 Partition. The CHS values are not used. A FAT32 PBR is 3 Sectors long repeated with an offset of 6 Sectors. You need to grab 9 Sectors to get all of it. I suspect the problem is in the FAT Table and/or Root Directory. If you can grab 7840 Sectors starting from the MBR, you should have all of the relevant data.

Checked them again, same result. I have both 98 and XP set to show all hidden/system files. Also the numbers seem too perfect... 4096 and 8192... I'm not up on this, but its almost like each OS is trying to use a different cluster size or sector size to read the filesystem. Using a different Sector or Cluster size would make the Drive unuseable. Try running SCANDISK on the Drive and repeat the tests. I had a corrupt key that reported 300K difference between XP and 98SE. An empty FAT32 Drive should only have 1 Cluster allocated for it's Root Directory, which in your case is 4KB.

Try repeating the two tests. Windows may have added a hidden file or folder in between the first two tests.

Completed DOS research. FAT16 and FAT32 Filesystems can be used, and booted from, on a 4KB per Sector Hard Drive with only a few modifications to IO.SYS. CHKDSK and SCANDISK appear to work normally. FORMAT does not. I have upgraded my RFDISK Program and am updating my RFORMAT Program.

I have done some experimenting using a DDO that simulates a 4KB Logical Sector Hard Drive. IO.SYS needs patches to increase some buffers to handle the larger Sectors and to recognize the Sector Length field in the Boot Sector's BPB. I was able to manually setup a FAT16 partition on the Drive and use it. SCANDISK and CHKDSK appear to work properly. Windows was unable to use it. Even before the GUI was loaded, I could see that it had miscomputed the FAT offset. Creating a FAT header at the miscomputed address did not help either. It appears that it would be simpler for me to create a DDO that simulates a 512B Logical Sector Hard Drive when the 4KB Sector Hard Drives become generally available. I already have tools to minimize misaligned reads and writes.

Windows 9x VFAT.VXD recognizes 512B, 1KB, 2KB and 4KB Sector sizes. How well it supports them will have to be tested. I may rewrite my BOOTMAN and High Capacity Disk Patch (HCDP) to simulate 4KB Sectors to find out. If Windows 9x does not support 4KB Sectors then I will develop a BOOTMAN and HCDP Package that will simulate 512B Sectors.

There are a number of problems with this idea. 1. My RAMDISKs do not currently support 8GB individually although this is not an issue here (see #2). 2. You cannot use a separate RAMDISK with any standard DEFRAG Program. You wil need a customized driver that substitutes RAM space for additional Hard Drive space above the end of the Partition being Defragged. 3. Extending the Partition is even more problematical if the Partition is not the last one. You will need Filesystem Patches similar to my experimental Patch for drives larger than 2TB. 4. The FATs need to be extended also. There would not be enough room for them. 5. The Partition size would also have to be modified before Defragging and restored afterwards. 6. You would put a lot more data at risk if a power failure or crash occurs as RAM based data would be lost.

Limiting the size of the Swap file will not fix any of the large RAM issues.

Booting Windows 9X from USB is not very hard. The following procedure will install Windows 9X on a USB Drive. 1. Set your BIOS to disable other Hard Drives and boot from CD. 2. Attach USB Drive or Key. 3. Insert Windows CD. 4. Boot. 5. Install Windows to the USB Drive. 6. When Disk Access Error Messages appear, press RESET. 7. Boot into Safe Mode. 8. Disable all USB drivers. 9. Reboot. 10. Continue installation.

Windows 98, 98SE and ME does work with 3GB of RAM but you will need the Patch I wrote to support it. The only alternative is to limit the amount of memory that Windows 9X sees.

MSCDEX.EXE is an IFS only. It is not a CD-ROM Device Driver. A CD-ROM Device driver needs to be loaded first.

No problem. "Stupid" is when you ask a question and there is no excuse for you not knowing better. If you claimed experience with Kernel Programming then it might have been a stupid question.

I have done some further testing and code analysis, and determined that there are multiple problems with trying to support files larger than 4GB in Windows 9X besides the FileSystem. Installing a new FileSystem will not solve these problems since the FileSystem will never even see File Offsets greater that 4GB. The following are two issues I have found so far. SetFilePointer allows 64-Bit Offsets but the Windows 9X Version blocks values outside +/- 4GB within the first few instructions. Bypassing the check shows that only the lower 32-Bits of the Offset ever reach VFAT.VXD. IFSMgr_Ring0_FileIO performs File I/O from Ring 0 Code. It uses EDX to pass a File Offset, so the interface would have to be changed to support larger files. This would require Patching all Software that call this function, including an unknown amount of Vendor Software. I suspect there are many more problems I have not identified. The only approach I am thinking about at this time, is to hook the User APIs so that a set of smaller Files will appear as one large File to Applications that want to use more than 4GB.

Whenever I'm finished with my flash drive at college this week I think I may just reformat it, from what you all are telling me it seems to have some bizarre settings. @rloew - While you're here I'd appreciate your input on the question I asked jaclaz in the other thread. You didn't say which question. I assume you are referring to your question about FileSystems that only Dencorso has replied to so far. I have thought about Patching the FAT32 FileSystem to support >4GB files but have not run yet run the tests or done the analysis to see if it is feasible. There may be limitations at higher levels, such as the 2GB Copy limit others have found. I haven't found a source for documentation on Installable File Systems for Win 9X. So far the only Patches I have written for VFAT.VXD are for the 1TB Partition Limit and support for 128KB Clusters. An experimental Patch is wating for Hard Drives larger than 2TB to become available.

The Geometry of 32 Heads and 63 Sectors is not unusual for USB Flash Drives. I have seen 16 Heads as well. The most important fix for this Pendrive is changing the Partition ID, at offset 1C2H, from 1BH to 0CH. To avoid potential partitioning problems in the future, the CHS entries should be corrected. The CHS End Cylinder High 2 Bits and Sector, at offset 1C4H, should be changed from 3FH to 0FFH. The CHS End Cylinder Low Byte, at offset 1C5H, should be changed from 8CH to 0FFH

Aren't that to be expected? They're being much more gentle than HP, that one day yanked all 9x/ME drivers from download all of a sudden. I don't remember if HP gave any warning on their website. I only knew about it in advance because I was on the phone with Tech Support about a couple of months before they removed the drivers. So I had a chance to download most of them.

A CD can be setup to boot as A:. My setup program edits all relevant registry paths before building the initial registry. I agree. The CD I mentioned is for my use only. A distributable version would require access to a licensed Windows CD.

I have written a Patch and .INF file that support the JMicron PCI-E SATA Card using the standard Hard Disk Controller, so it is possible. I cannot guarantee my Product would work with any other card, and I don't have a Demo Version for you to try.

I have already done something similar. I installed Windows 98SE up to the first reboot. Retrieved the files. Added my Patches and Updates. Wrote an installer that allows me to place Windows in any Directory and sets the Computer and Network names. Burned all of it to a Bootable CD.

I don't think any of the suggested reading material directly speaks to that question - which is: does Windows 98 actually utilize more than the first 256 mb of installed memory? If someone can compentently answer that question, please do. I have tested Windows 98 with as much as 3.6GiB of RAM and was able to utilize all of it simultaneously.