rloew

IKB yes. 2KB yes. 4KB no. There is also the issue of Partitioning and Formatting them as well. I stand corrected. I guess MS were catering for CD-ROM support, where 2K sectors are the norm. BTW, I finally found your previous comment on this 2K limit : Joe. Apparently. You can stick a 2KB Sector FATxx Partition on a CD and it is recognized.

IKB yes. 2KB yes. 4KB no. There is also the issue of Partitioning and Formatting them as well.

My TBPLUS Package supports all of the interfaces you listed. USB support requires generic drivers such as NUSB, my free Lexar based Drivers, or Windows ME derived support.

I have written an API that supports multi-core. At present it does require that Applications be written to use the API.

That's great news! Now folks using KernelEx will soon have the option to start creating files larger than 4GB... ...errr, does this mean I have to start adding large file support to all my programs? ... Some maybe. If your Program is likely to be used with large files, and needs to handle the >4GB Virtual File, rather than the segments actually stored on the Hard Drive, it could use the upgrade. So far, I have only updated XFILE.

I set up an experimental Windows 98SE setup and installed KernelEx 4.5.2. I have analyzed the KernelEx Interface and been able to update DLLHOOK to overlay KernelEx.

When "Auto Insert Notifcation" is turned off, Windows often does not sense that a CD has been removed leaving part of it in cache. Putting a different CD in can crash as Windows wil not realize that it has been changed. I also turn off "Auto Insert Notification" to avoid unwanted Autoruns, so I have to go through extra steps when changing CDs. I am considering patching Windows to disable Autorun without disabling Auto Insert Notification.

The SYSTEM.CB settings combined with the SYSTEM.INI settings accomplishes the same result as the problematic IO.SYS Patch, for FREE, so changing IO.SYS is unnecessary. This would prevent problems for people who can afford the improved performance my "Not Free" Patch provides. They would simply not make the SYSTEM.INI or SYSTEM.CB changes. Making FREE Patches Optional would require multiple copies of IO.SYS to choose which Patches are installed if the 1GB Patch is included, since people would still want my Phantom Drive Patch whether they are using my RAM Limitation Patch or not.

They are not Phantom Drives as they have the same Drive Letter. They appear to be Phantom Volumes, where Windows sees more than one Volume for a single Drive. Did you turn off "Auto Insert Notification" for your CD/DVD Drive in Device Manager?

I didn't run any speed tests. I was using an USB Flash Drive. It runs in compatability mode using the BIOS Driver.

The 1GiB RAM Safe Mode Workaround Patch for IO.SYS has been supplanted by others on this forum by editing SYSTEM.CB In any case, the Patch would disable the functionality of my RAM Limitation Patch, which is used by a number of Forum members. The Phantom Hard Drive issue is not related to the Large HDD fixes. They are entirely different issues.

Not a problem. I would like to believe that my freely released Mods are "Core" Mods as I described previously.

I wasn't joking! But I wasn't talking about "transmitting" zeroes, I was talking about "writing" zeroes. Nobody has gotten even close yet.

You make a good point. The date I gave to backdate was just an example. I don't have to use that specific date. The actual date doesn't matter. The issue remains. Another complication is that I often release updates as Patchers rather than the files themselves, for Copyright reasons, so the date on the file is the date the Patch was applied. This would not be an issue for prepatched files in your SP but might affect the SP's installation. Conflicting Mods are always going to be a problem. People may want different combinations of Mods. A single "Core" Version having only Mods, that everyone can agree should be present , would be the basis for a SP file. Anything else would be optional addons.

More reason to backdate them. Example: If you just patched IO.SYS a year ago and I backdate all unofficial files, the service pack will not override your files because they would be considered new. Your recent files will stay untouched. Its only about 25 files I need to do this to. Another reason is everybody using different versions of Explorer.exe + other files. Me backdating modded/unoffical files is considered somewhat a safety precaution. Most unofficial files came out after support ended. The problem is that earlier non-MS mods would also be considered new. If you set my latest IO.SYS to 2006, it would not replace my earlier IO.SYS from 2010.

Well, it depends on the type of data you send. You see, 1's are slim enough, 0's are rather fat and may get slowed down by friction in the tinier electronic pipes. As long as you send lots of 1's everything seems normal but when you want to actually 00 out a stick, it will get SLOW. Though for very different reasons, the effect is not completely unlike what happens with cable connections: http://www.911cd.net/forums//index.php?showtopic=21827&st=23 though if you use 0's and 8's on those tiny USB sticks, you will actually worsen the issue jaclaz Too bad nobody posted the real reason 0's are slower than 1's when writing USB Devices.

It can be done and a floppy is not needed. The only requirement is that the BIOS must recognize the USB Device.

If the card BIOS uses AHCI and cannot be changed, it cannot be used with Windows 9X even in compatability mode.

Obviously KernelEx Patches the code that DLLHOOK verifies before installing. They both are trying to do the same thing. I haven't used or analyzed KernelEx so I am not sure what would be needed to make DLLHOOK compatable. It would probably be easier to add the functionality to KernelEx as it should already be capable to doing it. In addition, combining Commercial and Freeware Software would be problematical. I will add a note to my FILE64 Package, on the next update, advising that it is not compatable with KernelEx.

I wrote DLLHOOK long before I wrote the FILE64 Package. It can add new functions just as easily as redirecting existing ones. I was trying to run a XP program in Windows 98. The Program self-checked for modifications, so I could not Patch up the Import Table. The Demo DLLHOOK Program in the FILE64 Demo is limited to a small .INI File and only redirects KERNEL32.DLL Calls but it should be useful for your testing. Create a DLLHOOK.INI using the following example as a guide: KERNEL32 EntryPoint1 STUBFILE StubT0 KERNEL32 EntryPoint2 STUBFILE StubF0 KERNEL32 EntryPoint3 STUBFILE StubT4 KERNEL32 EntryPoint4 STUBFILE StubF4 KERNEL32 EntryPoint5 STUBFILE StubT8 KERNEL32 EntryPoint6 STUBFILE StubF8 KERNEL32 EntryPoint7 STUBFILE StubT12 KERNEL32 EntryPoint8 STUBFILE StubF12 .... Create STUBFILE.DLL using the following example: StubT0 Zero Argument Stub returning TRUE StubF0 Zero Argument Stub returning FALSE StubT4 One Argument Stub returning TRUE StubF4 One Argument Stub returning FALSE StubT8 Two Argument Stub returning TRUE StubF8 Two Argument Stub returning FALSE StubT12 Three Argument Stub returning TRUE StubF12 Three Argument Stub returning FALSE ....

Windows 98's Memory Mapper is poorly designed. It fragments Physical Memory into separate pieces losing little bits in between. This appears to cause small discrepancies as you have seen. This problem only gets worse with more memory, as occurred with the older version of my RAM Patch. The newer Versions eliminated this fragmentation and reduced the discrepancies.

The Patch is complete. It is not free, the price is stated on the web page you linked. With the Patch, CONFIG.SYS, SYSTEM.INI and SYSTEM.CB do NOT need any modifications for Normal Mode or Safe Mode. Windows will then report the full amount of RAM.

My DLLHOOK Program does something similar to what you described but may not be compatable with KernelEx. In addition to the arguments you listed above, you will need to specify the number of calling arguments to properly clean up the stack upon return.

A version of my SATA Patch should be able to handle these cards.

Win98SE will NEVER "see" more and CANNOT use ANY MORE THAN (CANNOT CHANGE THAT!) Not true. I have a Patch that allows Windows 98SE to see up to 4GB of RAM and use all of it. The workarounds in this thread ARE limited to 1.15GB of useable RAM.