rloew

Windows 9x only has one set of Thread Management Tables and no Core level Synchronization Code so running generic Threads simultaneously is not practical. My API is not free. There is an older Demo on my website that might run and has documentation. Basically it locks and maps a programs memory to other cores, sets them up and runs code in them. Intercore synchronization Functions are provided to manage them. A core emulator is also provided so that the same code can be used to run in the original core as in the other cores or if the program is run on a single core system. Byt writing a Program that uses the first Core offered by the API, you can make an app that will by default run in another Core and not tie up Windows CPU time. If you run more of these apps then Cores, the extras will be run in the main core as before. If you run the same app in XP or later, it will allocate them to cores as always.

Windows 9x does not know about multiple cores so it will run just fine regardless of the number of cores. It will just use one. I have already written an API that can run Threads in the other cores. It is also possible to move Windows 9x to a different core.

If I may add my three cents in, I´d go directly the cab-way...I have patched the relevant files in the cabinet and so have it set already on install...and never have to think about this anymore...I am sure if you talk to Rloew, he could assist you doing it this way, if you want it more convinient.My Patches are already available in CAB form. Most users of my Patch do not Install Windows often enough to justify using CABs so no one asks for them. I also offer a tool on my website that makes slipstreaming almost anything into CAB Files easy.

It does more than simply circumventing the SYSTEM.INI entries. It gives Windows 9x full access to all of the RAM. Those entries make Windows 9x think there is only 1GiB of RAM.

Are those APIs included in KernelEx or do we need to implement them separately?No. I extracted the Kernel APIs and put them into my WDMEX product, which is like a greatly expanded version of WDMSTUB. KernelEx provides User APIs only, not Kernel APIs. I don't use KernelEx, so I don't know if it is complete with respect to ME User APIs.

I would assume that there are some Drivers that would require ME as it has a number of Kernel APIs that are not present in 98SE. I have extracted these APIs and added them to my 98SE system.

I see little reason to think that you cannot boot from the Card. It is possible that their Driver has a limitation but mine doesn't. I would give it a try. I have seen only two Cards that cannot. One was AHCI only. The other was RAID only.

There is no Driver at 60E. This error suggests a bad jump as can occur with a stack error.

I've seen this problem a number of times. I have even returned items that advertised Windows 9x support and didn't have any.

I tried the File Name Version again and it worked. Not sure what the problem was. @Drugwash: I got the Patched msdelta.dll, that I sent to you, working, so you should be able to use it.

That's good news. You may send it to me by mail if you want, for separate testing. I got mspatchc.dll and mspatcha.dll working. For some reason the File Name based routines (xxxA) gave me a problem, so I used the Handle Routines (xxxByHandles). I did not get msdelta.dll to work. It kept reporting Error 13 (Invalid Data). I have sent it to your AOL E-Mail. It uses MSVCRT so you may want to experiment with newer ones.

Network adapters, in particular Gigabit adapters, can cause problems with DMA Memory. I originally developed the /M option in my RAM Limitation Patch to address this issue.

I patched msdelta.dll so that it loads. I have not tested it yet. I do not use KernelEx.

mspatchc.dll v5.2.3760.0 does load so it should be useable. I extracted msdelta.dll 6.1.7600.16385 from Windows 7. The unsatisfied dependencies are all related to Tracing. Stubbing them with ACCESS_DENIED or NOT_IMPLEMENTED might work.

I checked the mspatcha.dll 5.2.9354.0 from a W2K Hotfix. It appears to load properly even under Windows 95. The header says Minimum OS = 6.0 so I didn't think it would work.Newer Versions may or may not work. If not, the Delta Files may have to be rebuilt with a working Version.

Some of us don't earn much...nor have good exchange rates... Maybe make it free in the next 5 years? I don't think McDonalds will ever make their hamburgers free. @Tommy You don't need to set MaxFileCache when using my Patch in most cases. You can still use MaxFileCache to lower it further as needed or use the /C option to set the maximum lower permanently. If you do a lot of writing to USB Keys, you may want to set it low. The minimum is 40MB of Cache per Gigabyte of RAM.

Does that Delta Compression API even work on 9x?The one I got from a W2K Hotfix would need Patching to work if at all. I have my own difference tool that I used to use to distribute updates. A Program and/or Script would be needed to locate, patch and place the files according to the system being updated.

Unfortunately, not even close.There are significant differences between the Windows 9x implementation and Window NT implementation that make a lot of Drivers unuseable. There are differences even within the 9x family as I found out trying to port Windows 98 Drivers to Windows 95. In addition, if a newer OS feature is used, the unsatisifed API Imports cause the Loader to reject the Driver. Stubbing may be possible but there is no guarantee that a given Function does not play an essential role in the execution of the Drivers Code. Windows 9x would ignore the Signature. The Checksum can easily be erased.

There are no working Drivers for USB Keyboards or Mice on Windows 95. LoneCrusader and I have been working on this problem for quite some time. We have come up with a way to graft Windows 98 WDM Support onto a Windows 95 System. This provides support for Keyboards, Mice, Networks and USB 2 Cards and Drives.

The original ESDI_506.PDR requires a Dual Channel Controller to be configured to use Interrupts 14 and 15 in most cases. Also some BIOSes hang the Drive Identification routine. My Patch is needed in either case.

IO.SYS is always in C:\. In some cases it may be hidden. You can unhide it by using: ATTRIB -h -s -r IO.SYS

Your links show my Patch for the Current Directory issue.I didn't see the Patch for the IO.SYS Patch required unless it is at the Website in German. Isn't it this one (viz. 3xSTART.EXE) jaclaz had already provided a link for? Yes.I use IE6 when on this forum. IE6 says his link doesn't exist so I skipped over it . K-Meleon renders it properly.

Your links show my Patch for the Current Directory issue.I didn't see the Patch for the IO.SYS Patch required unless it is at the Website in German.

There is no reason not to use IO.SYS 7.1 and FAT32 with Windows 3 even for the Boot Volume. A couple of simple Patches to IO.SYS and Windows makes it work.

And to be even pickier this can be also done in DOS/Windows9x/Me, using LetterAssigner, and this makes a nice loopback to:http://www.msfn.org/board/topic/118119-patched-iosys-for-9xme/ Taking down the pickiness a bit. you can always break this relationship with third party software but it was not intended by Microsoft. Sure , but while doing so, you named in vain the NT . jaclaz In vain? No. Normally the DOS Interrupts calls are not used. Windows replaces them with Protected Mode equivalents. When you copy a file, the following occurs:1. File Manager calls the Windows API (KERNEL32.DLL). 2. KERNEL32.DLL reformats the call and invokes INT 30H. 3. VWIN32.VXD handles the INT 30H call and converts it into an INT 21H call. 4. The INT 21H handler passes the requests to IFSMGR.VXD. 5. IFSMGR.VXD passes the request to VFAT.VXD. 6. VFAT.VXD converts the requests into raw Disk commands and passes them to IOS.VXD. 7. IOS.VXD passes ther requests to ESDI_506.PDR. 8. ESDI_506.PDR sends the requests to the Hard Drive Controller. DOS is not involved unless the drive is in compatability mode in which case the DOS code is run in Virtual Mode instead of using ESDI_506.PDR.