jumper

> Ah, I see. And if I'm interpreting this correctly, the "ntdll.RtlDeleteCriticalSection" and similar functions seen in 'k2rnel32.dll' (W2K 'kernel32.dll') are export forwarder thingies. I think so. > So what we actually need (ignoring the other issues here) is an Export Patcher tool? Today (Feb 19) is the one-year anniversary a short-lived Export Patcher project according to my folder creation date. I dropped it in favor of fwd: DLL forwarder which came out about a week later. > As regards not being able to have two versions of 'kernel32.dll' loaded at the same time, does not renaming the W2K version (theoretically) make this possible? The two versions both want to be loaded in overlapping address spaces, so one of them must be relocated. The 9x version is not relocatable, I don't think the NT version is either (look for a .reloc section with Quick View). The ReactOS version is, however (and also doesn't overlap)!

According to Depends, 98SE contain the following 86 exports in Iphlpapi.dll: What's the count and list for the ME version? I should be able to make the wrapper compatible with both.

Supplement:The ImportPatcher generats this ini µTorren#3.0.0 26473.zip file of µTorrent 3.0 exe. It lists many missing functions, but in comparison to the generated file of version 2.0.4 (stable with KernelEX) there are only seven functions more. The difference: [ntdll.dll] NtStopProfile= RtlUnicodeToOemN= _chkstk= RtlAdjustPrivilege= NtSetIntervalProfile= NtStartProfile= NtSetInformationProcess= [Patches needed] PSAPI.DLL=Functions, Unbind This appears to be a debug build (_chkstk and profiling apis). Perhaps it's a beta???

A quick peek into KernelEx.nsi (in the 4.5.2 source package) reveals that it contains no support for silent installs. [ref. 4.12 Silent Installers/Uninstallersk Try using a macro recorder.

Quicktime allows you to create a small, new media file with metadata and just a reference to the music track.

According to MSDN - RegOpenUserClassesRoot function (Windows), these definitions should all work well: [Advapi32.dll] RegOpenUserClassesRoot=r120s4 RegOpenUserClassesRoot=t4 RegOpenUserClassesRoot=o4 The 'e0' isn't needed as the LastError isn't set. "r120s4" would provide the best desciption of the failure.

> To run the setup I added [Advapi32.dll] RegOpenUserClassesRoot=o4e0 - (4 is # of WINAPI parameters, e0 is error success). It works, but I'm not sure with the value codes. "o" by hit or miss. Check the log. If RegOpenUserClassesRoot is not there, then the definition doesn't matter; it is only needed to satistfy the loader. If it is being called, a better definition or implementatation might improve the quality of the install and help the app run better.

> ...SeaMonkey 2.0.14 crashes immediately when I try to print ... What was in the log file? Perhaps one of the new ActCtx definitions? What modes are you using (with old and new core.ini)? Please try to step through the few core.ini differences and debug this for us.

A while back I assembled a set of stub definitions to duplicate the KernelEx functions that are pure stubs (so no lost functionality). I'll package them with a special version of Kstub822 so we can log what functions are being used and might need better definitions or actual implementations.

After much definition testing, I was unable to find one for FindActCtxSectionStringW that would appease Msvcrt90. The ActCtx definitions were introduced way back in post #10 and schwups first reported problems with it in post #15. Joe traced the main problem to FindActCtxSectionStringW in post #25. Clearly including FindActCtxSectionStringW was a big mistake (mine!), as no app is known to need it. Removing FindActCtxSectionStringW, retaining the other new definitions, and adding similar new definitions for the rest of the (non-Find*) ActCtx clan, we get: [Kernel32.dll] ActivateActCtx=o2e0 AddRefActCtx=z1 CreateActCtxA=p1e0 CreateActCtxW=p1e0 DeactivateActCtx=o2e0 GetCurrentActCtx=f1e ; needs code for success IsolationAwareCleanup=z0 ; for ActCtx/manifest QueryActCtxSettingsW=o7e0 QueryActCtxW=o7e0 ReleaseActCtx=z1 ZombifyActCtx=o1e0 Using these "Method 2" definitions, we shouldn't need method 4 (or 3). So here is a Core.ini that reverts nearly back to the original: The only differences are: [ApiConfigurations] default=0 [DCFG1] contents=Kstub822,std,kexbases,kexbasen desc=Base enhancements [DCFG1.names.98] ComDlg32.PrintDlgExA=Kstub822 ComDlg32.PrintDlgExW=Kstub822 [DCFG1.names.Me] ComDlg32.PrintDlgExA=Kstub822 ComDlg32.PrintDlgExW=Kstub822 I'm hoping to assemble this week a release package for Kexstubs that will be easy to install. I'll be reviewing Kstub822.ini and preparing a stubs.ini that has logging disabled and any last definitions that should go in. All suggestions are very welcome!

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....