rloew

Wonderful, RLoew! Let me get technical... You mean: set the word at offset 0x13 in the BPB to 0x0000 and use the dword at offset 0x20 to hold the sector count? Simple as that? Wow! I always suspected this should be possible, but never actually tried it... And you say DOS 7.0, 7.1 and 8.0 support it natively. Great! Did you test it with DOS 6.xx? It may also support it. Besides images, it can mean an oldish 128 MB pendrive or a Zip100 formatted to true FAT-12!!! And 128 MB would use 96 sectors per FAT, right? Haven't tried DOS 6.xx but I am pretty sure it would. FAT12 is limited to 4086 Clusters so it never uses more than 12 Sectors per FAT. Any more Clusters would be recognized as FAT16. 128MB FAT12 Partitions need to use 32K Clusters.

I wonder how did you format FAT12 disk to 36 MB size instead of well known 32 MB limit. Early implementations of DOS may have had a 32MB limit, namely the 16 bit sector count. With the newer 32-Bit Sector Count, FAT12 can easily handle 128GB. DOS 7 and Windows 9x have no problem with it. My modded IO.SYS raises the FAT12 limit to 512MB, 16GB with larger Sectors. The limiting factor is the CD Boot Floppy emulation.

It is possible to create a Bootable Floppy Image on a CD/DVD of up to 36MB. The required geometry is 1024 Cylinders 2 Heads 36 Sectors. I use my own CD/DVD burner. I do not know if any other CD writer will support this.

I would use "provide support for" rather than "simulate". I think DDO's got such a bad reputation because some early versions protected their own code by shifting the sectors on the entire Hard Drive. This made the Hard Drive unreadable if the DDO wasn't active, and all data was lost if the DDO was damaged. My BOOTMAN DDO and other DDO's I have written for other purposes, do not alter the Disk Layout, so they are safe.

I ran the tests using a 2TB Hard Drive so I was not limited to 1TB. I tested the original Windows 98SE FORMAT using 1018.83GiB = 1,093,962,207,744 Bytes which is more than Marius' Raid System. BIOS support, if run from DOS, or Windows support, if run from Windows, is mandatory for any Partitioner using Motherboard INT 13 Calls. The only exception is if the Partitioner supports raw Disk I/O itself, such as my RFDISK, or if you use a PCI card that has it's own BIOS. Without 48-Bit LBA support, FDISK and other Partitioners will correctly create the MBR but any Logical Partition or Next Extended Partition Record will be placed in the first 128GiB even if the Partitioner thinks it is placing it above the limit. Reading back the record is affected in the same way, so everything will seem OK. You can reload the Partitioner and it will show you exactly what Partitions you thought you created. If you use such a Partitioned Disk in the orignal system, everything will seem fine until data written in one 128GiB Block overwrites data in another 128Gib Block. If you move the Hard Drive to a 48-Bit LBA aware setup, the Partitions starting above 128GiB will disappear.

I ran some tests on the following versions: 98SE FDISK Original 98SE FDISK Q263044 Update ME FDISK Original 98SE FORMAT original ME FORMAT Original FDISK itself is limited to ~512GiB. Above 512GiB it wraps around, so a 600GiB drive would only be partitioned to 88GiB. FORMAT will work with Partititons up to ~1TB. Above 1TB a divide error occurs. All versions behaved similarly.

The Patches can easily be combined so they can be done in a single sequence. Add the PATCHMEM.EXE file from my RAM Limitation Patch package to the FIX95CPU Floppy, and run the RAM Patch after the FIX95CPU script completes.

I don't work for Microsoft, so I cannot give an official answer, but I gave my interpretation of why Microsoft said items #1 thru #3 in my last post. FDISK cannot provide support for 48-Bit LBA limitations elsewhere (BIOS and/or ESDI_506.PDR) even if it can handle larger drives, such as USB.

If you can install a driver for the card and the Computer crashes or runs out of memory when opening DOS boxes, try my Demo RAM Limitation Patch using the /A option. It will run for 10 minutes which should be enough time to verify if it works. It will also let you use the full 2GB of RAM you have.

Neither FDISK, FORMAT nor SCANDISK know or care about 48-Bit LBA. Older BIOSes and unpatched Windows 9X do not support 48-Bit LBA. I believe Microsoft set the limit to 128GB so that people wouldn't get a false sense of security by thinking that they could use a 512GB Hard Drive solely by using FDISK. I wrote my own version of FORMAT that allows all parameters to be set and supports 2TB Partitions.

Between your prodding and a considerable amount of help in testing on your part, it is done. As far as slipsteaming the AMDK6CPU fix, only the updated VFBACKUP.VXD cannot be combined into VMM32.VXD. Removing or commenting out the appropriate line from WININIT.INI will allow slipstreaming.

ESDI_506.PDR is not compatable with additional IDE Controllers even if the Default INF installs it, as occurs on some motherboards. I have written a Patch and an INF File to correct this issue.

I wrote a Patch to support SATA Drives on Windows 9X. It uses the original Microsoft Driver so it will not work with IAA.

If you use HIMEMX.EXE and XMSDSK you can create a RAM Disk of any size but you cannot use all of it if it is very large. Windows will manage all memory allocated by any XMS RAMDisk. When the total of the allocated RAMDisk memory and the designated File Cache exceed approximately 700MB problems will occur. If you have 2GB or more of RAM you will not be able to use all of it with this method.

Microsoft added code to Version 2225 to attempt to read a hard drive using LBA before using CHS. Most BIOSes automatically process CHS requests using LBA commands to the hard drive, if supported, so the older version generally worked. Some BIOSes, as noted above, use other methods when handling CHS requests. This caused the older version to assume that the drive was CHS only. Cylinder numbers overflow after 31GB when using CHS. LLXX patched all of the available versions to add 48-Bit LBA support. At a later date she bumped the version numbers to distinguish the modified versions. Version 2230 is her modified 2225.

Actually "Stretch" is an inaccurate term. It was sort of OK when most pictures were smaller than the Screen Size and needed to be "Stretched" to fill the screen. A more accurate term would have been "Fit To Screen". You probably didn't notice because you were adjusting the size of your images before using them.

I looked at the 1217 Version of Windows 95 VMM.VXD. Making a Version of my Patch for Windows 95 looks doable, but requies more extensive modifications, since it was designed for even less Memory than Windows 98. I do not have a Windows 95 Test Setup.

Sorry, wrong one. The old RAMDSK3S and the method you are using is the SYSENTER Method. The Trap Handler method is described as the INT30 Method in my Documentation and is enabled by the "/I" option in HIMEMEX. The old RAMDSK30 used it. It was the second method I developed. SYSENTER was the third. So it is actually older than the SYSENTER Method. It is the only method of the three that stands alone, not needing setup in DOS or a support VXD. The oldest file I could find was a test Program dated 07/06/08. The RAMDisk came two days later.

I missed the link to Full Disclosure. So many website use in-line links like this one for either useless information or advertising that I ignored it. My method is basically the same in principle, but I get into Ring 0 from which I can do anything I want including what they did. Despite the multiple pages documenting the IRET Instruction, creating a Stack Frame to return to User Mode is pretty straightforward.

There isn't enough information in the linked article for me to determine if the vulnerability mentioned in the article is the one that I found. I use the Trap Handler as one of three methods for gaining Ring 0 access from a 16-Bit Application such as my Non-EMS RAMDisks.

It has been my experience that as you go from DOS to Windows 3, 95, 98, 98SE, ME, XP, Vista and finally 7 the following happens: 1. New features and capabilites are added. 2. Some older capabilites are removed, often useful ones. 3. Size and resource usage increase. 4. Speed tends to decrease. 5. Portability is reduced. 6. DRM and licensing hassles increase. Generally the oldest system that does what you want it to do is the best. There is no best system. So arguing about 95 versus 98 is a waste of time. I still use DOS for a number of things that Windows does not do well such as Disk Management. With a few mods, DOS can handle over a PetaByte of Hard Disk space.

My experience has been that new Flash Drives are not bootable and often unrecognizeable by the BIOSes in my Computers. So I repartition and reformat them before putting data on them, using Programs I have written. Some Flash Drives come with software already on them so people may want to check and retrieve the files before repartitioning. I have not tried RPM but I wrote my Partitioning Program to be able to rebuild Partitions without losing existing data on the Drive. This would be a solution for people who already have data on their Flash Drives.

Only win-2K advanced server and datacenter server are mentioned here: http://support.microsoft.com/kb/283037/ http://msdn.microsoft.com/en-us/library/aa366796(VS.85).aspx http://support.microsoft.com/default.aspx?...kb;EN-US;268363 Note that win-2k is not mentioned in the following: ----------- http://www.microsoft.com/whdc/system/platf...PAE/PAEdrv.mspx Although support for PAE memory is typically associated with support for more than 4 GB of RAM, PAE can be enabled on Windows XP SP2, Windows Server 2003, and later 32-bit versions of Windows to support hardware enforced Data Execution Prevention (DEP). ----------- If DEP requires PAE on 32-bit OS's (which seems to be the case) and if the plain vanilla versions of win-2k do not support PAE, then they also can't support DEP - unless Microsoft releases some sort of appropriate (and rather sophisticated) patch for win-2K? The page pointed to by your last link mentions Windows 2000 more than once. They just didn't include it in their list of Maximum RAM capabilities. They also say that DEP automatically activates PAE. The only alternative to DEP is limiting the Code Segment, but this would make DLLs not executable. So it is not a solution.

Ran ScanDisk again, got same error, chose to Ignore. After that, ScanDisk finishes normally: It seems that ScanDisk is seeing the correct amount of used space, however, the exact same incorrect value is still displayed in the "Properties" tab in Explorer. Do you need me to image the first 16mb of the disk? Don't worry, the drive we're working on now is brand new and blank. This one's all for science, haha So maybe we can get to the bottom of these bizarre flash drive errors. I'm beginning to think that the first thing to do afte buying a new one is to repartition it and reformat it, so that way you know it will have "normal" settings I deliberately changed the available space setting in a FAT32 Partition and let SCANDISK run. It reported the same Error as you have seen. I don't think SCANDISK is looking at your MBR which has it's own problems. If you can Hexedit your image and write it back to your Flash Drive, the following should fix the problem: Offset 183E8H change F7 to F8 Offset 18FE8H change F7 to F8 These offsets are relative to the MBR. You only need a 128K Image starting from the MBR.

DEP requires PAE (Page Address Extensions) which is not available for Windows 9X.