jumper

The results are different: In 16 XUL does not load. In 17 it fails much later with thread 18 quitting after successfully loading WBEMSVC.dll. Were the symptoms the same? What versions of UCRTBASE.dll have you tried? Also try using KnownDLLs to redirect UCRTBASE to MSVCR140 or lower. The code at 406012 seems to just be checking for tampering in its own header, but makes no calls to UCRTBASE. 'First chance exception 0x406D1388 (Thread was named) occurred in "c:\program files\ff54_17\XUL.DLL" at address 0x0173AF59 by thread 10 "JS Helper".' -- This shows how a debugger can handle a RaiseException and continue without crashing. Mypal68 shouldn't be making that call when not running in a debugger. Try running Mypal68 in DW or Finesse.

From FF54_17.log: Shortly after XUL.dll successfully loads, Firefox.exe gets its own handle ([FIREFOX.EXE]00406012:<KERNEL32.DLL>GetModuleHandleW|400000) then makes a call into UCRTBASE.dll which tries to explicitly load another dll. That load fails ([UCRTBASE.DLL]00665edf:<KERNEL32.DLL>LoadLibraryExW|0) and so does an attempt to get a module handle (GetModuleHandleExW|0). UCRTBASE then quits by calling ExitProcess, probably after displaying the broker services error message. FF54_16.log is the same. I see no evidence of a crash--Firefox.exe appears to terminate normally. If you Profile Firefox.exe in DependencyWalker, it should show the name of the dll UCRTBASE fails to load. While the broker services error is still displayed, looking in Procwin16 at the Firefox.exe code after 00406012 might reveal what UCRTBASE api before 00669c2c was called. Also the string passed to LoadLibraryW should be findable. As for KSTUB825.log, it is full and no longer logging anything. Just delete it to start a new log.

A couple of commits in the Firefox 54.0a1 (2017-02-15) build caused crashes and were reverted in the next day or two. So try -16 and -17. And check the kexstubs log files to see which apis were called.

.

9.0.289 requires a CPU with SSE support. 9.0.47 and 10+ don't, but 10+ requires XP. FineSSE29 solves the SSE problem on Win9x, but hasn't been tested with NT4.

For FAT and NTFS drives, API wrappers could walk the path string and shorten each long folder or file name as needed. Network shares to other file systems could be a problem. Temporary environment variables and drive mappings might also be possible. I've considered these possibilities for KernelEx should the need arise, but haven't done any tests. For years I have been successfully using a function I wrote to walk a path string and lengthen each short folder or file name. Doing the opposite should be easy.

Ungoogled would be a fork, not a port. Please stay on-topic.

I'll look into it.

Haswell is not LGA775.

I replied: "Excellent. Do the same for Windows 2000."

More details from Gemini. Note at bottom: "Updates KB3034344, KB3013455, and KB2850851 specifically address critical vulnerabilities in how win32k.sys parses TrueType fonts...."

Third try by asking Google Gemini (Thinking):

Summary of first two trys asking Google Gemini (Fast): For the final updates, this number was in the high 7000s (e.g., 5.1.2600.7512 or higher). KB4500331 (May 2019): BlueKeep Remote Desktop Services vulnerability (CVE-2019-0708). KB4012598 (May 2017): Released to address the WannaCry vulnerability. Mar 2014: MS14-015 KB2939576 Critical EoP vulnerability in Win32k. (One of the final official patches) Dec 2013: MS13-101 KB2880430 Multiple EoP vulnerabilities in Windows Kernel-Mode Drivers (Win32k). Jul 2013: MS13-053 KB2850851 Remote Code Execution/EoP vulnerabilities in Win32k and TrueType Font handling. Jan 2013: MS13-005 KB2769369 EoP vulnerability in the Windows kernel-mode driver (Win32k).

Navigating from the link in post #1, FileHippo has versions 15, 12, 6 and many others.

No one suggested that change. An appropriate substitution would be FreeLibrary: it will see the parameter as invalid, set the last error, and return FALSE just as a GetNumaHighestNodeNumber stub would do. Please look up the two functions at learn.microsoft.com to see why.

Click on "Manual Update" in the left-side (Windows Update) menu Enter "intel" or "gigabit" as the Search Keyword (not "prowin") Click "Search" (scroll down if needed) Links to three versions of the Intel driver appear on the right. No, but the drivers above might work if you modify the inf file or force-install. Open a new NT4 LAN thread to report test results or for more discussion.

GetNumaHighestNodeNumber is just the tip of the iceberg. If Kernel32.dll doesn't have GetNumaHighestNodeNumber, the OS doesn't support NUMA. A GetNumaHighestNodeNumber replacement stub should SetLastError(120) and return FALSE.

Or you could copy a Psapi.dll with that API (Vista/ROS/Wine/KernelEx) to the local directory. Patching might be the best option -- this is one case where dropping the "Ex" from the end actually works (same three parameters). Using a hex editor, change "QueryWorkingSetEx" to "QueryWorkingSet" by replacing the "Ex" with two nulls.

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.