rloew

Well, I meant downloading as opposed to catching, with the same frying afterwards, though you are right, fish downloaded from FTP tend to have a slight mud aftertaste .jaclaz Meant?Now it is your turn on the hot seat for inaccurate nitpicking.

You mean download jaclazFried fish are muich tastier than downloaded ones.

USB Audio works well with 98SE. Get the most basic model you can find. Find one that lists 98SE on the package.

Well, then you should also be 100% accurate when nitpicking, now hopefully everything is clear for all the readers. jaclaz I would hope so. All the nits have been picked.

I was referring to your statement that only a single executable subsection is loaded into memory. I was not referring to the DLL itself.Less than 100% accuracy is not good, especially since the OP is not the only one reading the thread.

OK, thanks. As I run my W98 at home as a hobby system without any commercial potential I don't intend to order commercial patches for it. So I sticked with alternate boot from SATA2 HDD. I just wanter to try myself all possibilities that I could try... My Patches are not specifically designed for Commercial systems. In fact most of my Customers are individuals like you. You have requested trial versions of my "Commercial" Patches in the past.

A DLL contains a number of Functions but they are not separable blocks. They are loaded and if not shared unloaded as a single block. You may be thinking of LIB Files that contain separate executable modules that can be individually compiled into a program. They can be patched to some degree and normally only the Code Segments are Read Only and then only when in memory.

OK, I did tried some attempt with TSR myself... I found an opensource program protect.com for DOS. It's simple to understand and modify. I modified it to be silent on discarded write access. The unload after Win98 boots is not so easy as I though because when a DOS window is launched and program executed again to disable it only affect environment of that one DOS window and not system in global. So as a dirty test I added a counter of dicarded writes with condition that passed all writes after reaching some count. Then I do trial-error tune of count to see how system will react. If I block more than about 300 writes it booted to GUI. Unfortunately whole write protection idea proved wrong because when write access via INT13h was reenabled Win98 hanged totally. So even after esdi_506.pdr driver takes control there still seems to be INT13h accesses that kill it. So what only could help would be to patch BIOS INT13h routine to not doing any buggy DMA operations. This task going too complicated over the discomfort of booting Win98 from slave HDD on SATA2 port (where I have smaller primary partition that I cannot easily increase because of need to keep extended partition on the same HDD below 8,4GB limit for DOS 6.22). I doubt that PROTECT.COM has the Windows 9x handoff code in it. I suspect that ESDI_506.PDR was never invoked so Windows continued using the problematic BIOS INT 13.I do have a product, called DISKBIOS, that replaces the BIOS INT 13 and properly handles DMA. It correctly hands off to Windows 9x. E-Mail me if you wish to order it.

Ok, nice, is it freely available? I just wrote it, so I have not made a product out of it, so it is not currently available.

Appasrently that Write Inhibiter does not have the code needed to tell Windows it is safe to take control. I wrote a Write Inhibiter and it ran fine with Windows 98SE.

The Odd Address problem does affect Disk Reading as well but very few things actually use Odd Addresses so you may not notice it. There could be other issues. There is no way to be sure without testing.

Yes. Just PATCHMEM with no Options.

Apparently I'm not following this discussion... The 8168 device is commented out in the Tenda package but is not commented out in the latest package available from RealTek which is newer by version and by timestamp. According to the INF in the RealTek package up to RTL8111D is supported, but rloew said previously that "D" and "E" devices don't work with it... The Tenda Driver I recommended appears to contain an abandoned attempt to support the RTL8111 Cards. The INF entry was then commented out after they chose not to continue development but never removed. I found that the Driver sort of worked if the INF was uncommented.

I'm not sure what the problem is. It sort of works on the two systems that need it.I think one of them required SPLIT8MB and the /M Option of my RAM Limitation Patch. I think that the SATA3 Port can only be set to Native Mode. In my experiments, particularly with AHCI, BIOS bugs cause it to mishandle Disk I/O Requests to Odd Addresses. DMA cannot handle Odd Starting Addresses so it corrupts.I have a product called DISKBIOS that can handle this but it is designed as a TSR to be loaded in AUTOEXEC.BAT. I also wrote a simpler Buffering program to handle Odd Addresses. The experimental version of the Odd Address Buffer Program, which was what I was referring to, was a Driver Style TSR that I could place before EMM386 which had been causing a crash.

Uninstall and then Repatch without the /C:128 Option. Send me the following files: WINDOWS\SYSTEM\VMM32.VXD WINDOWS\SYSTEM\VMM32.BAK WINDOWS\SYSTEM\VMM32\VMM.VXD WINDOWS\SYSTEM\VMM32\VMM.BAK 1. Go to the WINDOWS\SYSTEM\VMM32 Folder. 2. Rename VMM.VXD to VMM.XXX 3. Rename VMM.BAK to VMM.VXD 4. Reboot 5. Test Outlook. 6. Go to the WINDOWS\SYSTEM\VMM32 Folder. 7. Rename VMM.VXD to VMM.BAK 8. Reboot 9. Test Outlook. 10. Go to the WINDOWS\SYSTEM\VMM32 Folder. 11. Rename VMM.XXX to VMM.VXD 12. Go to the WINDOWS\SYSTEM Folder 13. Rename VMM32.VXD to VMM32.XXX 14. Rename VMM32.BAK to VMM32.VXD 15. Reboot 16. Test Outlook. 17. Go to the WINDOWS\SYSTEM Folder 18. Rename VMM32.VXD to VMM32.BAK 19. Rename VMM32.XXX to VMM32.VXD Send me the results of the three Outlook Tests. Depending on what you find, I will send you more test files.

If the problem is still noticeable with my previous suggestions, and you have time for a fair amount of experimentation, we can try to pin it down. You don't need more RAM. The 512MB RAM System is actually better for debugging as it shows the problem and is not dependent upon the Patch. I can break my Patch down into it's component parts and have you test them individually.

OK, and could you be a bit more detailed what the SATA patch do or what's aimed to fix? I'm not sure if it's targetted to this specific Issue as my SATA2 ports run fine. From the short description "SATA Patch and INF File for Windows 9x." I cannot Imagine. The SATA Patch provides support for Native Mode Controllers and Shared Interrupts. It also disables a problematic Drive Identification routine. Many Motherboards can run SATA Ports as Legacy or Native. In Legacy Mode my Patch is not needed. Only four Drives can be in Legacy Mode so the enhanced mode needs to use Native Mode to support more. I have done this experimentally. As long as it doesn't crash in virtual mode or have special requirements, it should be possible to let Windows take over control and use it's own Driver during Boot. I have tools that can switch Drive Letters in DOS. The assignments carry over into Windows.

So then is this not so much a bug but rather a configuration problem? See, this is the same problem I was having on my machine with 2GBs of RAM and so I didn't know what exactly was going on there.It's hard to say for sure. Something could be running close to the limit already and get pushed over the edge by my Patch. It would be necessary for you and I to run a series of tests to try to isolate it further. You can try reducing the File Cache on your 2GB RAM system to see if it helps.

No direct relationship. Both can affect memory usage.

The /C:### Option changes the default File Cache Maximum. You can also try PATCHMEM /C:128 to reduce the File Cache further. You can also set "MaxFileCache" in your SYSTEM.INI to do this.

Uninstall and then reinstall using PATCHMEM /C:256 Then reboot.

The Tenda Driver shares INT 11 with Standard VGA and the USB 2 Drivers (no USB 1) on my Z87. On my M5A97 it shares INT 11 with the USB 1 (OHCI) Drivers not USB 2. I don't have a Demo of my SATA Patch. I would have to significantly obfuscate the Patch Demo to avoid piracy problems. It may be possible to create a TSR to make Windows think the Driver is compatable.

Run PATCHMEM again to uninstall the Patch and reboot. See if the problem goes away. If it does, reinstall the Patch without /M and reboot. See if the problem returns.

So, I discovered by accident...that installed RLoew's RAM patch causes this problem to happen. Since the machine I was using only had 512MBs of RAM, I went without using it but I remember once he said that even if you don't have over 1gig of RAM that it was still beneficial to use the patch. So I installed it and opened up Outlook, and bam, very low system resources. This hasn't happened at all until I installed the patch. The patch is 7.1 and I don't know if it is the latest or not but I used it in conjunction with USP3, the latest version. So I don't know if the RAM patch itself is flawed here or if it's just not playing nicely with something in USP3. All I know is installing the RAM patch caused this problem to happen. What options did you set?Did you install it before or after U98SESP3?

INT0800 and ATK0110 are specific devices built into some Motherboards. They are not relevant to Windows 9x so a Null Driver INF is needed to get rid of the unknowns. The ISA Enumerator Port has been supplanted by LPC. It reports a different configuration that conflicts with other devices. Apparently this is allowed so it reports no error and no Resources.