rloew

No to all. Windows 9x may not know the difference between PATA and Legacy/SATA but a more advanced Driver as in newer Windows still can use the additional features. You kept comparing them as if they were interchangeable. Yes for conventional Controllers. There is also SCSI, USB, Firewire etc. No. It is in "IDE Mode". No. This is impossible without additional Drivers. I'm not sure about the SIL3112 or 3114 Controllers but the SIL 3512 Controller runs in IDE Mode but reports a SCSI Class Code. A SCSI to IDE Driver is required and is provided. No. The SATA-1 Controllers you refer to most likely run in IDE Mode but do not report the IDE Class Code so that the ESDI_506.PDR Driver is not used. The Drivers are Controller specific and use the PCI Device ID to match the Controller. Anyone who has a Controller specific Driver does not need my AHCI Program or my SATA Patch, but I doubt that they are getting AHCI.

Can you provide an application (runnable in true DOS) to identify that bug?There's a lot of users nowadays running in Compatability Mode. Unfortunately not at this time.I have not been able to reproduce the problem in DOS. I know it has to do with DMA Writes to odd addresses because it goes away if I guarantee even byte access. I will have to setup a special Drive to run further tests as I have to reload Windows after each attempt. The problem appears to be limited to only a few BIOSes at most as no one seems aware of it. Anyone running in Compatability Mode does not have the bug as it trashes the system immediately. I posted the warning in case someone who was running their system in IDE Mode decided to try using AHCI.

You are running in Compatability Mode. This is useable but performance is reduced.Apparently your BIOS does not have the bug that corrupted my Hard Drive.

@Nomen There is no "Emulated" Mode. SATA uses a superset of the PATA Protocols. You cannot choose between PATA and SATA. They use separate connectors and Controllers. Legacy Mode and Native Mode determine the Port assignments. It is not an interface type. The Class Code is not changed. There are two Interface types. IDE and AHCI. RAID uses a third Class Code but appears to work as either IDE or AHCI depending upon BIOS. Unmodified Windows 9x will use ESDI_506.PDR for all drives in IDE Mode. ESDI_506.PDR does not properly handle Native Mode so it can crash or hang. If you add a more specific INF File, then Windows will use that driver. I'm not familiar with the IIA Package. The IAA Package has drivers for specific Controllers. I don't know if any SATA Controllers are included. If so, read the documentation. AHCI uses Memory Mapped I/O so it technically is neither Legacy nor Native but a limited Native Mode Register set is usually present. Either Legacy or Native Mode can be used for IDE. The available combinations are as follows: PATA Drives: Legacy IDE Legacy RAID (IDE Interface) Native IDE Native RAID (IDE Interface) SATA Drives: Legacy IDE Legacy RAID (IDE Interface) Native IDE Native RAID (IDE Interface) AHCI RAID (AHCI Interface) Only one Legacy Dual Controller (4 Drives) is allowed. This can be PATA, SATA or one Channel of each. BIOSes will often limit your choices. BIOSes generally use the term "Native" to refer to Native IDE Mode usually when there is a Legacy Option. They explicitly use "AHCI" for AHCI Mode. BIOS Options are one word so the context determines the actual mode. "RAID" is ambiguous. You have to actually test to see if it uses AHCI or not. If a Controller is switchable, it is possible to write a Driver that can switch it to AHCI Mode. I have done the reverse.

The terminology used in BIOS Setup can be ambiguous. PATA vs. SATA is the Physical Interface. It cannot be changed. Legacy vs. Native is the Controller I/O Interface. Legacy Mode uses known fixed Ports and Two Interrupts, so only one can exist. Native Mode uses variable Ports and One Interrupt. IDE vs. AHCI determine the mode of access, I/O Register vs. FIS Memory Structure. RAID is an usage indicator and may be either Register or FIS based but is listed as a separate Mode. If an option is listed, it must be AHCI or possibly RAID for the AHCI FIS Structures to be used. Native Mode does not imply AHCI. I answered your Second question before. You can be in ANY Mode and still not use ESDI_506.PDR.

UEFI is out of the question. It runs in 64-Bit Mode or in 32-Bit Mode is some systems. It doesn't support Real Mode. A CSM (Compatability Support Module) is needed to run Windows 9x in a UEFI System. The other issue is GPT. It should be possible to modify DOS and Windows 9x to use GPT but CSMs generally do not support it so there is little need. The original ESDI_506.PDR only supports "Legacy Mode" which is used in Motherboard PATA Controllers and sometimes SATA Ports 4 and 5. My modified ESDI_506.PDR supports "Native Mode" using I/O Registers. SATA Controllers normally use Native Mode whether in IDE, RAID or AHCI Mode. IDE and older RAID Modes use I/O Registers so they are compatable with my modified ESDI_506.PDR. AHCI and Newer RAID Modes use FIS structures in DMA Memory. A significant Driver rewrite would be needed to support this. My new project allows me to start up in AHCI Mode, switch the Controller to use I/O Registers, and replace the BIOS Code to support the change. To not use ESDI_506.PDR, either a system is running in Compatability Mode or it is using a specific Driver. Even old IDE PATA Systems may use a specific Driver. VIA provides their own Drivers for their Chipsets. I've already found bugs in their Miniport Driver. Since the Class Code is supposed to be different for Controllers in AHCI Mode, Windows 9x will not normally detect any Drives connected to it. The warning I posted in Post #1 relates to Compatabilty Mode operation. My project includes an INF File that allows Windows 9x to recognize these Drives. I don't think the type of SATA Controller is an issue. AHCI provides enhanced performance in newer Operating Systems that support it. By providing better support in Windows 9x and avoiding crashes or corruption, I make it possible to Multi-Boot without having to switch Modes when switching OSes. There are also BIOSes that force AHCI Mode even though the Controller is switchable.

Yes.Running in Protected Mode means using a Windows Driver, in this case my Modified ESDI_506.PDR, rather than Virtualizing the BIOS or DOS Driver. @Nomen Someone using Multiple OSes or using an Add-On Card may need AHCI support even in systems with better 9x support.

I have been doing some further research on using Hard Disk Controllers in AHCI Mode with Windows 9x. First I have a warning. On at least two Computer, I observed that Disk I/O is corrupted when running on a Computer with AHCI enabled and an odd Start Address is requested while in Virtual Mode. I have not seen corruption but the risk is there. IOS.VXD does two Reads in Virtual Mode. One to check it's Safe List and one while loading DRVSPACX.VXD. These occur during Boot. EMM386 cannot be used with AHCI Enabled as COMMAND.COM will crash. I have written a small mitigation Program to correct this issue. There are a number of possible AHCI scenarios which I have listed as follows: 1. AHCI Only Controller with Direct Protected Memory Interface. The Marvell based HighPoint card, I previously posted about, falls into this category. As is, no Windows 9x recognizeable Drives can be present. Windows 9x will crash before it even has a chance to load Drivers. If the BIOS or Card can be modified to use Interrupt 15 or other supported Method then it may be more useable. See Scenario #2. The HighPoint Card had a Patchable Option ROM so I could modify it. Otherwise a compatable MBR or DOS DDO AHCI Driver is needed to allow Windows to Boot. I do not know if any exist. 2. AHCI Only Controller with Compatable Protected Memory Interface. An AHCI Controller of this type can boot Windows 9x, but see Warning above. I know of no AHCI Driver for Windows 9x so it will run in Compatability Mode at best Also, I have noticed that some of the earlier AHCI Drivers miscompute the size of the Hard Drive if it is larger than 2TiB and can lockout parts of the Drive well below the 2TiB limit. 3. Switchable AHCI Controller with Direct Protected Memory Interface. As in Scenario #1, Windows will not boot using this Mode as is. Otherwise read Scenario #4. 4. Switchable AHCI Controller with Compatable Protected Memory Interface. If the BIOS allows you to switch to Native Mode and you can do so without causing unresolvable issues with other OSes, do so, it will make things much easier and safer. Many newer Motherboards use AHCI when in RAID Mode so this may not help. If there is no BIOS Option or you will mess up another OS continue reading. This is the Scenario for my Warning above. If your Computer is not at risk, or you use my mitigation program, you may be able to run Windows 9x in Compatability Mode. I have developed a DOS DDO that switches the Controller to Native Mode and replaces the BIOS Driver. I am still running tests so I have not published it yet. In conjunction with my SATA Patch and a modified INF File, I have been able to run Windows 98SE in Protected Mode from a Motherboard started in AHCI Mode. 5. Switchable AHCI Controller with Native Mode Default. If it correctly reports the Native Mode Class Code then it can be treated like any other SATA Controller. If it reports the AHCI Class Code, as at least one JMicron PCI-E SATA Card does, a modified INF File will be needed. Either way, my SATA Patch will be needed for proper operation with Windows 9x unless a specific Driver is available. EDIT: I have reduced the severity of my Warning as the serious corruption issue I originally warned about was traced to a TeraByte Plus Patch I was using for my 6TB Test Drive. I have corrected the Patch and haven't seen corruption even without mitigation.

PCI USB Cards compatable with USB 1.1 should work with 95C. USB 2.0, USB Ethernet, Keyboards and Mice require the 95/98 hybrid setup. SO far I have not been able to use USB Audio.

Maybe not everywhere but here I think it applies.North Korea is a well known exception to the rule. Of course. Name a case where the Code was released with no strings attached and not part of or usedin some other Code or Product. Google uses their code in commercial products and claims ownership over the overall packages. We are not talking about chipping away at rights. We are talking about basic principles. Interesting that you are the one pressuring him to release "full" sources, containing the GPLCode rather than "diff" files that do not. Neither.I said he would violate my Copyright if he distributed my DLLHOOK Program itself. Anyone can write a package that calls my Program and distribute it without my consent but someone would need to buy DLLHOOK from me for the Package to work. Since DLLHOOK is independent of KernelEx, he could write routines to add to or replace KernelEx functions without being subject to the GPL either. It is not my problem. It is clearly a work in progress so technically it has not even been "released". He already statedan intent to provide Source Code when he is done. Also he is free to provide it in a form of his own choosing. If he did not, someone who "distributes" it as part of some work could potentially have a problem, but simply hosting it is not. Also deleting virtually anything from the Internet is next to impossible regardless of legality. "Viral" is right. Like many other kinds of "viruses" it has led to the death of a lot of businessesthat tried to embrace it. Demands like yours only make prople less willing to put in the effort, especially when they are not getting paid for it directly or indirectly.

Since Jumper is not claiming ownership rights or controls over the mods, they are basically free speech on his part. No trade secrets are involved and by offering "diff" files instead of full builds he isn't even copying anything. He could have developed Libraries and Linkage files based on my proprietary and non-GPL DLLHOOK Program instead and even I would have no claim against him unless he actually distributed DLLHOOK itself. So, no payment stub, no standing for a lawsuit.

K-Meleon still shows a blank page. Now they deliberately blocked IE6.

IE6 works but K-Meleon still shows a blank page.

For a couple of days I have seen the blank white page using K-Meleon 1.5.4.

Some PCI-E Video Cards do work with Windows 98SE. If the card is not recognzed, it's Device ID may need to be added to the list in the NVAGP.INF File. In 7.7.7.2 only the 6600 and 6600 GT are listed.

You are welcome, I am sure , knowing that you have a program that can do that is something that I had really missed, maybe in a next stage of awareness I might be able to learn what is the name of the program and what is the that it can do.jaclaz I was assessing the OP's interest before going into more detail. I'm sure you could have figured it out by looking at my website.The program is called DLLHOOK and it can satisfy the missing entry point the OP specified.

Thanks a lot for this exceptionally useful piece of news .jaclaz Thanks. Awareness of a solution is important.

I already have a program that can do that.

That is why I wrote my own DDO. It does not prevent the HDD from being used in any Computer that can support the HDD as a Boot Drive or otherwise.

If I remember correctly, OnTrack offsets the Sectors. If so the Drive is unreadable elsewhere. I would not recommend that one.

If you have a custom Driver, you are subject to the limits imposed by the Driver. The generic VIA Driver has a bug in it so I would not recommend it. The original ESDI_506.PDR Driver only supports 28-Bit Addressing so it is limited to 137GB so it needs to be Patched to go higher. VFAT.VXD has a bug that MAY cause problems with Partitions larger than 1TiB. This is not a Hard Drive size limitation. The bug relates to Partition alignment so it may appear or it may not appear, but it won't show until there is more than 1TiB of data in the Partition. Ignore at your own risk. The MBR structure and a number of Driver Files limit addressing to 2TiB. I have a workaround to go higher. All of the above limits apply to Windows 9x. BIOS Limits also apply. Although it may seem that you can get away with using a larger Hard Drive than the BIOS supports as long as you boot quickly into Windows there are some operations that occur before the Driver is loaded or in Safe Mode that can corrupt your system if the involved data ends up above the BIOS limit. This is where a DDO is needed. BIOS caused corruption is often catastrophic as it tends to wrap around to zero. The ESDI_506.PDR Driver often returns an error rather than access the wrong sector and it does not wrap to zero so the risk is less.

I wouldn't hold my breath waiting for a BIOS mod. I did one myself and it took a fair amount of work. Your only solution is a DDO.

If you entered Cylinders then you are definitely setting things up as CHS. FDISK will allow either Percentage or MegaBytes as input for LBA.

The board documentation describes the LBA Mode as a BIOS mediated translation from CHS to LBA. There is no mention of Interrupt 13 Extensions for full LBA use. Since you used FDISK in percentage mode, it probably created two 4GB Partitions. A DDO is mandatory for proper operation of a larger drive with this BIOS. I have a number of DDOs suitable for this purpose. Windows 95 is NOT limited to 32GB. I am running it with 2TiB with my Hard Disk Patch. Otherwise it is limited to 137GB.

It's getting even worse. Now they give you little or no documentation on even their brand new stuff. I bought a brand new Laptop. No manual comes with it. I found the online Manual. There was no description of the BIOS Setup. After finding that the SATA Mode had exactly one choice, namely AHCI, and "Secuire Boot" could not be disabled without killing UEFI, I returned it. A decent manual would have prevented this.