jumper

This can be done by changing just three bits! What you need: Oleaut32.dll 2.40.4519 (31 July 2006 6:12:40 pm GMT, checksum: 000A2534) A hex editor Dependency Walker Steps: Open Oleaut32.dll in the hex editor change 00000004: 03 to C3 (create ret opcode in unused DOS header) change 00087760: 00 to 04 (direct Ordinal 327 to above) Save and verify. Optional to adjust the checksum: also change 00000118: 34 to F8 (000A2534 to 000A25F8) Verify addition of Ordinal 327 (and checksum) with Dependency Walker.

No, that's for bi-directional parallel ports. Select your quoted text and search on Google. An HP printing support forum has the answers. Or try a standard LaserJet driver as I suggested.

The first posted version of Kexstubs825 had a bug that required a careful workaround in the ordinal definitions. A fixed version was reposted and included in later Kex22 update packs. What is the date stamp in the KernelEx tab of your copy of Kstub825.dll? I recommend trying the six OLE files discussed in this post as KernelEx helper modules. Yes, Oleaut32.dll 2.40.4519 (recommended for standard usage) can be easily patched to add an export for Ordinal 327. I'll do that now.

My color HP 656c printed quickly via USB from Windows 98 in 2002. I second the recommendation for trying the oldest available drivers. Try the default PCL5 drivers first: Back up your system Uninstall/remove all drivers and software related to printing Backup/create a new restore point Attach printer and scan for new hardware Select any Laserjet that uses PCL5 drivers If this solves the print delay problem, install updated HP drivers if you want more features.

Ideally a replacement function takes the same number of parameters so the stack (local variables and calling information) doesn't get corrupted. It should also have the same return type so it can correctly report that it couldn't perform the requested task. If the function doesn't get called, then any name that fits will do. Names are usually word-aligned, so even-length names are often followed by two zeroes instead of one. If so, the replacement name can be up to one character longer than the original. All names can also be extended another two characters by overwriting the "hint" word for the following name if there is one. If the parameter count can't be matched, fewer has a better chance of working. If the return type can't be matched, more analysis is needed to best fake it. In the past I googled the API I wanted to replace, checked my DLL for possible replacements, then researched each. Today I'd start by asking Gemini for a list of APIs in the same DLL and with the same number of parameters and return type as the API I'm trying to replace. Then ask to narrow it down to Windows 95. Use FC.EXE to compare the original and modded files. Post the results and I'll review them.

This link still works. The 72MB zip file is a compilation of many drivers.

These are Special Folders. Their locations probably depend on whether you login with a User Profile or not. Check the registry for each path string.

But no FIXINTR, FIXINTR5 or FIXEOI patches. Great! So this tweak solves two independent hardware issues. I just now Googled "Windows IRQ steering" and found this in the AI Overview: So perhaps we should only have it enabled when changing hardware, then disable it for best stability.

Probably an RF issue. Try different: Wifi channels / power levels shielding / reflectors USB ports / hubs / cables monitor refresh rates cpu and system clock speeds

Thanks for the update. Was this also before the Nvidia driver install, or after? And are any of RLoew's patches still installed?

So this is no longer the case?

I'm still working on this. I found my old Pentium 133 Windows 95 system and have downloaded some alternate builds of Pidgin and GTK+2. The rev-a version seems to be the mistake; the original GTK 2.6.10 was the last build for 95 except for a special build of 2.14.4. Google "gtk+2 win95-compatible version" AI Overview:

I'm only seeing IsDebuggerPresent in libglib-2.0-0.dll. I think the others all import from libglib-2.0-0.dll. With ImportPatcher you can patch: IsDebuggerPresent=GetCurrentProcess or IsDebuggerPresent=GetErrorMode I'm seeing (right-click on folder, Find, Containing text) InterlockedCompareExchange in libxml2.dll and nspr4.dll. Try patching with ExitProcess for now. The code will need to be patched. The instability is C Runtime Library errors upon second launch. Hopefully just my system.

I patched 6 bytes to convert the VirtualAllocEx call into a working VirtualAlloc call, 5 bytes for VirtualFreeEx to VirtualFree, and 3 bytes to update the checksum to ward off malware false-positives. Check your messages for an attachment. Pidgin 2.6.6 (unpatched) does launch on my 98 system, but isn't stable unless I enable KernelEx and set it to Win2K mode. So more patches will probably be needed.

98, SE, and ME do have VirtualAllocEx, only 95 doesn't. Use ImportPatcher or Dependency Walker to find all missing functions. If there are only a few, I can write a wrapper.