jumper

I think this was discussed in Printing with KernelEx 4.5.1. Try seaching the forums for "print to pdf". It may now be possible to run dopdf or tinypdf in 9x with the help of KernelEx and Kexstubs.

> The MSVCR100.DLL file is linked to missing export Kernal32.dll:InterlockedPopEntrySList On my system, this api is provided via Kexstubs. Before Kexstubs, it was sometimes possible to just use KnownDLLs to forward MSVCR100 to MSVCR90 (try searching the forums for MSVCR100.dll).

Shame on µTorrent 3.0. NTAllocateVirtualMemory is a Windows Native System Services routine; apps should be calling VirtualAlloc instead. You can try using some of the other return codes as documented at MSDN, but I think this function will require a full Wine implementation.

In W2K and later, many NTDLL.DLL apis are made available in Kernel32.dll via export forwarders. I know exactly how export forwards are implemented, but it's not a small change for Import Patcher to support them. IP is architectured to patch Imports, not Exports. "It's impossible. But doable." KernelEx 4.52 runs as an MPR service, thus it loads after MPR. I assume this is why you're trying to patch MPR instead of using Kexstubs. NTDLL.DLL interfaces directly to drivers and the OS, so it really is an impossible substitution. Kernel32.dll is also extremely OS-centric and off-limits for substitution. Also Kernel32.dll is non-relocatable, so two versions can't be loaded at the same time. The best solution I see is to rebuild the Wine or ReactOS sources for MPR.dll and static link the necessary functions from the other librarys.

Good news: I'm posting this from K-Meleon 1.6.0 Beta2 using new Method 2 definitions. Obstacles: 1. FindActCtxSectionStringW To avoid the R6034 error, previously this function needed to be undefined. I found that declaring success also works: FindActCtxSectionStringW=o5e0 2. CreateActCtxW Neither T nor F worked, but returning the first parameter (pointer to ACTCTX struct) works: CreateActCtxW=p1e0 3. ActivateActCtx Once again, declaring success instead of failure was the key: ActivateActCtx=t2e0 After redefining each function, I relaunched KM and then checked Kstub822.log to monitor the progress. In all three cases, the 'e0' (ERROR_SUCCESS) is probably not needed, but MSDN states "This function sets errors that can be retrieved by calling GetLastError" without limiting the scope to failure cases. Additionally, I've deleted the two ANSI functions as they don't seem to be needed. In summary, the new ActCtx definition set is: [Kernel32.dll] ActivateActCtx=t2e0 CreateActCtxW=p1e0 DeactivateActCtx=f2e FindActCtxSectionStringW=o5e0 ReleaseActCtx=f1 I haven't exit KM yet, but will update if DeactivateActCtx or ReleaseActCtx also need to report success.

I was pretty sure I could bait you into tackling Method 3 by using the verb "hex"! Now that we have one method that we know works, I'll continue pursuing the other three. I'm sure Method 4 works, but it's proving difficult to set up reliably; I think a profile that enables ActCtx rather than disabling it will work better. I'm still hoping for a Method 2 solution (e120 or e127, perhaps) that will make the other methods unnecessary. I didn't have any apps that look for ActCtx functions, so hadn't been able to test myself. Now I've downloaded K-Meleon 1.6 and will begin testing. Thanks you, loblo, for providing us with the first working solution to the ActCtx conundrum!

> > If you have an NT2K mode that sticks [...] > All the attempts don't work. All the specfic compatibility modes don't stick! If you are saying NT2K mode won't stick, and that even Win95 mode won't stick, check that the Kstub822 module names match: [DCFG1] contents=Kstub822,std,kexbases,kexbasen [WIN95.names] ComDlg32.PrintDlgExA=Kstub822.0 ComDlg32.PrintDlgExW=Kstub822.0

If you have an NT2K mode that sticks and supports KERNEL32.FindActCtxSectionStringW, NOFACSS should also stick--those are the only two dependencies: [NOFACSS] inherit=NT2K desc=Win2000 SP4 (for OpenOffice) [NOFACSS.names] KERNEL32.FindActCtxSectionStringW=none Perhaps the KernelEx bug that limits the number of modes that stick to 11 (0..10) limits ME to something even lower. Try renumbering the modes like this: [ApiConfigurations] default=0 0=DCFG1 1=WIN95 2=WIN98 3=WINME 4=NT40 5=NT2K 6=NOFACSS 7=NOAC 8=WINXP 9=VISTA 10=NOHEAP If this works, check to see if NOHEAP and VISTA will stick. You can also drop from the numbering sequence any modes you don't use (e.g. NOHEAP, NT40, etc.), just make sure to leave the sections for inheritance purposes.

>The seven ActCtx api's in Kstub822.ini Good. Make sure you reboot after adding (including uncommenting!) definitions. >Now Ktree lists the stubs for the KERNEL32:*ActCtx* functions. Only valid if you rebooted after adding definitions. >The Explorer is unusable: => Runtime Error.... Program: C:....Explorer => later a message "Explorer caused an error in WEBVW.dll" As I recall, you use an extension that requires KernelEx. Find that extension and set it to "no ActCtx". Or try setting Explorer.exe. >Can't run OpenOffice: default mode KernelEX enabled => Runtime Error.... Program: C:....swriter.exe ... R6034...and then "Error starting program - The msvcr90.dll file cannot start" We keep referring to "OpenOffice" but it is actually a suite and individual apps/dll's might need to have their modes set individually. >Mode Win 2000 SP4 (for OpenOffice) => doesn't persist If your Core.ini contains all the following and "Win2000 SP4 (for OpenOffice)" won't stick, Kexstubs isn't providing KERNEL32.FindActCtxSectionStringW. Make sure the definition is enabled in Kstub822.ini and you reboot after enabling it. [ApiConfigurations] default=0 0=DCFG1 1=WIN95 2=WIN98 3=WINME 4=NT40 5=NT2K 6=NOAC 7=WINXP 8=VISTA 9=NOHEAP 10=NOFACSS [NOFACSS] inherit=NT2K desc=Win2000 SP4 (for OpenOffice) [NOFACSS.names] KERNEL32.FindActCtxSectionStringW=none Reminder to everyone: Kexstubs allows for modifying existing definitions with just an app restart, but additions and/or deletions of definitions requires an Immediate reboot! Changes to Core.ini don't take effect until after the next reboot, but it does not have to happen immediately.

>Hi Jumper, using Method 4 I could activate 6 of the 7 ActCtx and Open Office worked as it should. After activating FindActCtxSectionStringW=f5e it crashes on start. What version of OO and what all ActCtx functions does it use? Please test return codes other than false for FindActCtxSectionStringW [edit]such as f5e120 and t5[/edit]. [Edit] Here's a custom profile for Core.ini to disable just FindActCtxSectionStringW: [ApiConfigurations] 10=NOFACSS [NOFACSS] inherit=NT2K desc=Win2000 SP4 (for OpenOffice) [NOFACSS.names] KERNEL32.FindActCtxSectionStringW=none [/Edit] >But unfortunately with even one ActCtx running MultiPlayerClassic6491 do not start at all. So I again had to take these out. Did you try the new "no ActCtx" mode?

Excellent feedback, schwups! It has highlighted several problems that I need to fix.... >Renamed both files ini and dll to Kexstubs Oops, please undo that! In a number of posts I have incorrectly referred to "stubs.ini" as "Kexstubs.ini" and this has probably caused many of our testing problems. "Kexstubs" has become in practice just the family name. + Each version of Kstubnnn.dll (e.g. Kstub822.dll) should be used as is, without renaming. + The stable definitions file should be named stubs.ini. + The test definitions file(s) should be named Kstubnnn.ini (e.g. Kstub822.ini, Kstub626.ini, etc.) and will override stubs.ini. This allows overriding of the stable definitions while testing. This also allows the use of multiple versions of Kexstubs simultaneously with different definitions/logging options. I will edit the erroneous posts, but will also need to release a new version of Kexstubs that makes the search order: Kstubnnn.ini, Kexstubs.ini, stubs.ini. For testing at this time, please use the names Kstub822.dll and Kstub822.ini . @Everyone: Suggestions for KstubE05 (E=14th month of 2012) upgrades requested! >New setting "Win2000 SP4, no ACTCTX doesn't persist. The setting jumps to base enhancements. KernelEx is rejecting this profile probably because the ActCtx functions aren't getting created by Kexstubs, so can't be uncreated in Core.ini! You can use Ktree to confirm whether or not Kexstubs is creating stubs for the KERNEL32:*ActCtx* functions.

What did you do to make SeaMonkey 2.0.14 work fine? What have you tried since you last reported this OpenOffice failure? Set the compatibility mode on all MSVCR 8 and 9 dll's to "Win2000 SP4, no ActCtx (for MSVCRT 8+)". You can find them by searching for dll's containing the text "ActCtx" and by looking at loblo's list. Iphlpapi4 might help and shouldn't hurt...Please report your findings.

Why are you considering downgrading when 98 SE SP 3.0 already contained versions 7.00.9981.0 and 7.10.7031.4? Please review Post #101 from last March (and its link) where I already covered _fstat64 (and MSVCRT.DLL dll hell). I can confirm that versions 6.10.8924.0 and 6.10.9848.0 both support _fstat64, but after 10-1/2 months of testing, I recommend using MSVCR71.DLL 7.10.7031.4 as MSVCRT.DLL.

loblo, excellent report with lots of precise details! The Active Context function stubs have been giving us more trouble than anything else. As you noted, some apps need them present, others need them to be missing. Here are the options we currently have for dealing with this problem: Implement the functions with real code (ala PrintDlgEx/ComDlgEx and IpHlpApi) + Best solution for all apps, even if we just fake it! + Wine/ReactOS should provide implementation ideas Find better stub definitions that will satisfy all apps + Everyone is welcome to help search + Just edit stubs.ini and save, then restart test app (no reboot needed!) Hex the MSVCRT 8 & 9 dll's to look for ActCxx instead of ActCtx + If ActCtx api's are missing, they work; so hex to look for something known to be missing - might not fix all apps--others may need hexing, too, or help from (2.) Use custom Core.ini profiles, possibly with multiple Kexstubs versions/definitions ~ I've had mixed success with custom profiles, but should be able to derive a non-ActCtx profile that inherits from W2K and disables ActCtx support + If core.ini can't do it alone, a second version of Kexstubs can be loaded to provide alternate definitions to the custom profile I'll get to working on (4). It'll require some reboots and creation of a test app. I'll update the post when I get it working. Update: Method 4 is ready for testing. Add the seven ActCtx api's back into stubs.ini and copy the Core.ini from the spoiler below, then reboot. After removing two Core.ini profiles to make room under the cap, these lines did the trick: [ApiConfigurations] 6=NOAC [NOAC] inherit=NT2K desc=Win2000 SP4, no ActCtx (for MSVCRT 8+) [NOAC.names] KERNEL32.ActivateActCtx=none KERNEL32.CreateActCtxA=none KERNEL32.CreateActCtxW=none KERNEL32.DeactivateActCtx=none KERNEL32.FindActCtxSectionStringA=none KERNEL32.FindActCtxSectionStringW=none KERNEL32.ReleaseActCtx=none I found that any profile past number ten gets displayed in the pick list, but won't "stick". So to make room for this new profile plus one more in the future, I removed the Win2003 and Win2008 profiles. Here is my complete Core.ini: Other changes to note: [ApiConfigurations] default=2 "2" for SE, "3" for ME users; probably should be "0" to autoselect. Should NOT be "5" for 2K--we aren't 2K and at best can only partially fake it when absolutely necessary! ComDlg32.PrintDlgEx overrides are in the Win95 section. DCFG1 description changed to "Base enhancements" to avoid the confusing overuse of the term "default". Make sure you have renamed Kstub822.dll to Kexstubs.dll

I did some more testing and found that Opera only uses MSIMG32's AlphaBlend function, and only for displaying icons in menus and the Minimize/Restore/Maximize/Close buttons on child-window menu bars. I didn't see any rendering problems with any of the three versions of MSIMG32 (SE, ME, KernelEx). The skin I use (like most skins) has custom icons and buttons prerendered to blend with matching backgrounds. Even on the Bookmarks menu which is full of icons, rendering speed was fast for all versions with no lag on my 735MHz C3 processor. And I was adding much overhead per icon by redirecting (and logging) each call to AlphaBlend via Kexstubs! So, the good news for Opera users is that any of these versions can be used. There should be no performance issues unless maybe a system has an early Pentium or slower. Use the "[user Prefs]Show MSIMG32 Warning=0" setting in "operaprefs.ini" on Win9x less than ME to avoid the need to upgrade. Use the ME or KernelEx version if you notice icon or button rendering issues. I was unable to find a test program to benchmark either MSIMG32's AlphaBlend, GradientFill, and TransparentBlt, or GDI32's GdiAlphaBlend, GdiGradientFill, and GdiTransparentBlt. If and when I do write such a program myself, I'll let PROBLEMCHYLD be head tester! Footnote: I also tried redirecting AlphaBlend to GDI32:GdiAlphaBlend from W2K and ReactOS with no luck....

Get a wifi router that also has a client mode, then connect it to the PC via the nic. No driver needed. Configure the router with your web browser. I'm online right now using an Airlink101 AP431W in this way. Edit: Bridge mode can also be used if the client router's chipset matches that of the wifi access point it is connecting to.

>Original system files should not be replaced by stubs. Agreed! Fortunately, the KernelEx version (written by Tihiy, not Xeno86) is full-featured, not stubs. The three key functions in MSIMG32.dll are: * AlphaBlend * GradientFill * TransparentBlt Tihiy's version (7.5KB) contains nearly complete implementation of all three functions and fixes visible rendering problems that can be seen when some apps use the standard SE or ME versions. The XP version [5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)] is smaller (4.5KB) because it passes most of the work to XP's version of GDI32.dll (GdiAlphaBlend, GdiGradientFill, GdiTransparentBlt--not available in 4.10.1998/4.10.2227 for SE) with just a bit of modification to AlphaBlend. The SE and ME versions are larger (52KB), perhaps because they are unoptimized, debug versions. If anyone knows of (or wants to write) a test app to compare MSIMG32 feature compatibility, fidelity, and speed, we could determine whether Tihiy's version is indeed the best to use globally.

Yesterday I took a look at that 24Mar2012 version of ComDlgEx.dll and think I know what is going on--that SumatraPDF 2.2 is now passing real unicode strings to PrintDlgExW instead of multibyte strings. The 24Mar2012 version of ComDlgEx is actually the best in that it has real Unicode support for PrintDlgExW. But it didn't work with KernelEx via Kexstubs because of the way KernelEx uses Unicows. So the ComDlgKx.dll is dumbed down slightly to work with KernelEx and doesn't work with what S'PDF2.2+ is now doing. Fortunately I've learned a lot since last March. I should now be able to produce a better ComDlg32 wrapper that will work both stand-alone and with Kexstubs along the lines of the IpHlpApi wrapper I've been working on recently. I'll post an update in Printing with KernelEx 4.5.1 when I can.

In your BIOS, look for a setting that will allow you to use slower timings on the RAM. e.g. increase the CL from 9 to 10; or decrease the speed from 1600MHz down to 1333MHz, etc. You might also be able to increase the voltage from 1.5v to 1.55v (or more) if you have good cooling. If you don't have good cooling on the RAM sticks decreasing the voltage might actually make them run more stably.

Nomen, if Opera is running in KernelEx's Win2K mode, then it is using the 5.00.2218.1 (KernelEx special version) from your Windows/KernelEx directory. Only apps for which Kex is disabled entirely will use the Windows\System version. The KernelEx special version doesn't seem to have any non-standard dependencies, so you might be able to put it into Windows\System for use by non-Kex apps.

Welcome to MSFN, roscoegrable. While KernelEx might be able to help with driver installers, it doesn't help with the drivers themselves. Since your printer problem isn't KernelEx-related (yet), I suggest starting a new topic in the Windows 9x / ME subforum. You should also look here first for a good idea from jds that might work for you.

Drop the RAM to 512MB until you get SE installed. Then you will have multiple options to get it back above 1GB. (see stickie topic about running with >1GB, etc.) If the HDD/controller is SATA, you'll probably need to look for a compatibity mode for it in the BIOS.

I've happily followed all the activity here and in related topics over the last few days, but have been a bit busy. It seems there is much energy in 2013, and much to do! I'll catch up on responding to each issue later tonight, but for now here are some new stub definitions to verify: ; Remote Access Service Functions (Windows) [RASAPI32.dll] RasGetAutodialAddressW=t5 RasGetAutodialEnableW=t2 RasGetAutodialParamW=t3 RasSetAutodialAddressW=t5 [;RASDLG.dll] --- see Lz32 --- RasDialDlgW=f4 ;needs error set in struct RasPhonebookDlgW=f3 ;needs error set in struct ; Authentication Functions (Windows) [secur32.dll] AcquireCredentialsHandleW=t9 DecryptMessage=t4 EncryptMessage=t4 GetComputerObjectNameW=z3e120 GetUserNameExA=z3e GetUserNameExW=z3e InitSecurityInterfaceW=z0 InitializeSecurityContextW=t12 LsaEnumerateLogonSessions=t2 LsaFreeReturnBuffer=t1 LsaGetLogonSessionData=t2 QueryContextAttributesW=t3

MiKl> SUNBIRD verursachte einen Ausnahmefehler 03H in Modul KERNEL32.DLL bei 0187:bff768a1. A Google search for "03H KERNEL32.DLL bff768a1" led me to this post by jds, so clearly the Active Context (*ActCtx*) stubs are not working and need to be removed. SAP GUI for Java will surely break for jds when he tests with the "new" definitions because of this regression. Also, make sure you have the Kex default in Core.ini [ApiConfigurations] set to "default=2" (WIN98). default=5 is incorrect. Your system seems to have mismatched msvcrt DLLs or other DLLs used by Sunbird that are causing the problem, not Sunbird itself. If your default is already at "2", please disable KernelEx extensions completely on Sunbird. > After closing the error box another message appears saying that NEGOTIAT.DLL is missing. This has to do with Directory Services. Maybe Sunbird is trying to access Outlook? This doesn't seem to be related to Kex or Kext. > When using the new defs Sunbird and OpenOffice crash no matter if iphlpapi 3 or 4 is 'called'. Is this the correct term ? "Called" is okay; "active", "used", "being used" might be better. The Active Context stubs seem to be the problem, not iphlpapi4--this is good. >Commenting out the msvcr... sections seem to have no positive effect on my system. Okay, thanks. It now looks like iphlpapi4 is probably okay; the problem seems to be the ActCtx definition regression. I'll correct post #116

Thanks again to everyone for testing. It seems I've make too many changes all at once and it's not clear where something has gone wrong. @MiKl: Sunbird 0.5 (zip version) does not require KernelEx (Depends and IP36 both give it a clean bill of health). It runs fine in 98SE for me with Kex disabled or in any mode. It does link to Iphlpapi.dll but has no problems with iphlpapi4 using either the Kexstubs or local copy method. Using the local copy method I can see in a process viewer (TaskInfo2000) that both the original and wrapper are loaded. Questions: Are you using the new definitions? Are you using the Kstub or local-copy method? "Crash" is extremely vague--can you provide some details? @schwups: "...IpHlpDll Entry not found (7b340000 0)" is my debug message from the DLL startup function as the load is about to fail. 7b340000 is the address returned by LoadLibrary for C:\Windows\System\iphlpapi.dll and 0 is the address returned by GetProcAddress for ??? (silly me for not including the API name in the debug message ). It appears from the log that it actually loaded successfully on the first call to GetAdaptersAddresses, then failed on the second call--this could be because it follows a call to CreateActCtxW (that has caused trouble in the past) or something to do with how KernelEx hooks GetProcAddress. Try commenting out Kernel32:CreateActCtxW (and rebooting); if that doesn't help, please try the local-copy method. @jds: Can you test using the Kexstubs method (clear the KnownDLLs entry and use the new definitions)? It looks like the global- and local-copy methods might be immune to something that is ailing the Kexstubs method. For anyone experiencing R6034 runtime errors in OpenOffice or other apps, try commenting out the Msvcr90 and/or the Msvcr sections-> "[;Msvcr90.dll]", "[;Msvcrt.dll]". [ reference1, reference2 ] If the three of you can confirm that apps that worked with iphlpapi3 and older definitions also work with iphlpapi3 and the new definitions, that will isolate iphlpapi4 as the problem. If modifications to the new definitions are needed to get iphlpapi3 to work again, perhaps iphlpapi4 will also work.