win32

Thanks Ximonite. With this all taken into account I've finalized my plans for shell32 x86. Those functions are much simpler than what I had been originally looking at. Then there is SHGetPropertyStoreForWindow, which doesn't exist in BWC's kernel but does on 7; that seems quite simple, and I think it could be used on 2000 if the __security_cookie stuff is cut out of the start and end (unless you want to start using it). I will be putting this into its own wrapper (shellnew.dll) instead of stuffing into ntk32 as I briefly wanted to do. Have these functions even been tested on 2000? Looks like Vista will be the proving grounds to determine their capability as lots of modern applications call them. Shell_NotifyIconGetRect will be redirected to Shell_NotifyIconW and SHAssocEnumHandlersForProtocolByApplication will be redirected to SHAssocEnumHandlers as that satisfies Opera on x64.

Now that I'm revisiting 32 bit components, I'm wondering where this came from? It's not in my One-Core-Api binaries or 7 or 8.1. I am having serious thoughts about putting it into ntk32 to make as portable as kernel32/ntdll components, especially if somehow I have to use the 7 implementation. ntk32 also has the advantage in that I can properly expand the import table as it's in the "right place" (bottom of reloc section - weird but it works). I found that certain functions are perfectly importable by my new functions, but others like NtQueryInformationProcess and RtlSetThreadErrorMode are not.

SP2 is the intended target, but it is possible that this wrapper could be adapted to RTM versions of kernel32 and ntdll.

A very strange situation on the x86 side of things; it appears that in general for some imported ntdll functions on x86, they crash when being imported. Forward exporting functions doesn't seem to work either. But replicating the ntdll function in kernel32 works fine (in the case of RtlSetThreadErrorMode). But what about NtQueryInformationProcess and the like? You can't put stuff that interacts with ring-0 all over the place! I'm not sure what exactly is wrong, but it may be some strange artifact of WOW64 switching/thunking. I have yet to test any kernel extensions on a pure Vista x86, but I did make an attempt at kernel extensions on XP x86 for a specific purpose and did not have issues with import calls failing much like on Vista WOW64. With these discoveries in mind, my solution to this problem is to take one of the components of the x86 ntdll wrapper, ntnew, which was to house the code for the new x86 ntdll functions, and add the new x86 kernel32 functions to it, thus it will now be known as ntk32.dll. This is how this wrapper will be structured: Programs needing new ntdll functions: call ntext.dll instead, which will forward new functions to ntk32.dll. Programs needing new kernel32 functions: call kernel32.dll, which is the existing one augmented with an expanded export table, which in turn will forward new functions to ntk32.dll. Hopefully this should maximize portability of the x86 extended kernel components between WOW64 and pure x86 Vista. I just hope that calling the Nt/Zw* functions will be successful as that has yet to be tested and I wonder if it will be possible from ntext as opposed to ntdll. That will be a major setback if it cannot. UPDATE: NtQueryInformationProcess called through ntnew (have yet to implement kernel32 stuff in there yet), is working.

Open firefox.exe with CFF Explorer, go to "import directory" and change ntdll.dll to ntext.dll That would be quite odd to have the installer rename the existing dlls and not copy the new versions. There is a check in the installer to halt if any of the files in the folder are missing.

This has got a little weird. I can play the sample videos, but actually not the "DreamScene Content". So I checked with my non-w7mfplated VM and it is capable of both. While with W7 media foundation, it only plays wmv content and not mpg content. The sample videos are wmv and the "dreamscene content" is mpg. That may be one of the main reasons why DreamScene for W7 wasn't well received, but need to check further. Update: installing K-Lite codec pack basic 15.9 has fixed the dreamscene issues.

Personalization -> Desktop Background and you will find "Windows DreamScene Content".

Mine still works, even with win7 media foundation (though dreamscene can be enabled for W7, but is apparently unstable. for the record, it works on this same configuration with W7)

It may be possible to use Firefox with localized versions of mf and mfplat.dll along with the other codecs, as Dixel said. But there may have been a reason why I discounted it back in July.

I just checked and it is the media foundation replacement that kills it (one of the tests it does is "checking Windows media playback"; a system with updated kernel files but not media foundation ones has no issues.

Yes, I confirm that the VLC developers did change the buttons between 2.x and 3.x.

x64, though the situation is similar on x86.

I kinda tried that, by changing a couple of empty bytes at the end of the existing .text section. Even with the digital signature removed, code integrity and driver signing enforcement disabled, it caused a BSOD. My implementation is better in some ways than the original ntdll, as it can be local redirected. which can quite be important for difficult version checks. Though I do want a patcher that can change all instances of "ntdll" in a file to "ntext". A script to latch onto firefox.exe to do just that, allowing you to run it in seconds.

Those are unrelated issues, as ntdll in this case is x64 and kernel32 is x86. Just decided to jam them into the same post. ntdll on x64 is settled for now, but kernel32 on x86 is far from it, as we all know. PE32 files have some special undocumented rules that PE32+ ones don't. I knew that something was truly wrong when VLC x86 started to fail with calls to RtlSetThreadErrorMode, similar to the problems with NtQuery* functions reported back in July. (sorry, I can barely type today)

To steer this back to kernel discussion, I saw the ReactOS code. However, as I am not under the same restrictions for code usage that ReactOS has, I will try with the Windows 7 version of the function first, in both ntdll and ntoskrnl. January 2021. Before that, there is a possible solution to the kernel32 x86 problems I have discovered. I now have a hunch that putting any code after rsrc and reloc (in addition to the export table) is a recipe for disaster so I will have to rework the file with the export tables and code all before rsrc/reloc.

You need a newer release of the Common Controls library (comctl32.dll), such as version 4.70. It is shipped with IE5.

Apologies, I edited the quotes so they wouldn't refer to you. It is very difficult on this forum to quote multiple posts on different pages. Replacing functions works sometimes (one taskbar icon-related function in shell32 calls an older one because the real function would crash a program if someone scrolled over or clicked the taskbar icon), but in many cases it doesn't (most notably forwarding the K32 series of functions to the non-K32 versions in psapi.dll; it should work as the differences between K32 and non-K32 versions seem to be minute, but it doesn't for presently unknown reasons). I guess you could disassemble programs, compare the last not using a certain function with the first using it, and change whatever routines to the old versions. Just need to bypass any integrity checks if possible.

No, as there is ntext. Though due to its design, it is a pain to work on but I'll need to do major work on it to push this further. I made some attempts to extend x86, but aside from helping a bit with Steam clients, most of them have failed. Recently, I appear to have solved the outstanding issues with shell32, but that won't do much when kernel32 remains seriously bugged up (I suspect it to be causing problems with Bandicam and VLC x86).

The image quality is quite low, but that seems to be the 32bit shell32 causing the problems, which is an MS creation.

comctl32 seems to be fine, as the "open/save file" dialogs are fine, aside from the fact they are unskinned! So what has problems is uxtheme.dll. Here is some Dependency Walker output: The Vista version of SetDefaultDllDirectories is quite basic compared to the 7 version.

This doesn't have anything to do with Windows 10. I have used the root cert update in that package successfully on Vista.

On x64? With Haswell? No idea about the VRAM reporting though.

I haven't been able to try RTM, and I've heard about its file copying and setup issues (on some machines it fails if there is too much RAM; all but 1 GB must be removed temporarily for setup to complete). Also, several ntdll functions were added in SP1 which would likely make even local redirection impossible with SP2-based files.

I plan to focus on SP2 with 2017 updates. Though I do wonder what happens when dxgkrnl.sys, dxg.sys, d3d11.dll, and dxgi.dll are copied from SP2 to SP1 (RTM gets harder because certain functions are missing).