win32

I have since revised the instructions due to the corruption issues I experienced. If all tables are good (you can check them each in CFF), then you don't have anything to worry about anyway though they will be useful with future updates.

.xdata is the preferred nomenclature.

Oh yeah, I remember discussion on the use of .manifest files to redirect DLLs in XP, and I did try it a little bit in Vista where it worked, but forgot about it after it failed in 2000. Another method of redirection is explained here: https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-redirection So instead of replacing kernel32.dll, you can simply create yyyyy.exe.local in the same directory as yyyyy.exe and plant the custom kernel32.dll in the directory as well, avoiding the effects of monthly updates.

Yes, that would definitely be possible; just change all references in the target program's import table from kernel32 to the modified kernel33. However, that may be very complex in the case of programs that have many dependencies on other files that in turn have unresolved dependencies on kernel32 (which would be resolved with a modified kernel32/kernel33). As it appears that putting the new code/stubs in separate tables from the original MS code maintains the OS' stability, I decided that modifying system files would work best, though it will prove somewhat undesirable for those who continue to update the OS. But I've been thinking about HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs, which seems to direct applications to system DLLs; perhaps I could have two entries for both kernel32 and kernel33 (kernel32 = kernel32.dll and kernel32 = kernel33.dll), thus rendering the reboot and replacement of system files unnecessary? But I'm booted into Windows 2000 right now, and I'm not sure if that key exists in Vista. UPDATE: it does exist in Vista, but I had to take ownership of it to edit. I'm going to try changing the kernel32 entry to say "kernel32.dll, kernel33.dll" and see what happens. another UPDATE: unfortunately the system and applications don't recognize the x86 kernel33.dll with the extra function.

So here is the first part of the Windows Vista x86 kernel extension tutorial. More functions are to come. Since the code will be much longer than before, we will use HxD along with CFF Explorer and PEMaker v0.82 to speed up the process. Take the kernel32.dll from your X:\Windows\System32 folder (on x86 systems) or X:\Windows\SysWOW64 (on x64 systems) and copy it somewhere else. Open that copy of kernel32.dll in CFF Explorer and click "Section Headers [x]" on the left sidebar. Right-click on the table of sections and click the option to "Add Section (Empty Space)". Set the size to 0000B100, then name the new section .xdata. Set the characteristics to 60000020. Close CFF Explorer and open the file in PEMaker. Head to the "Export TBL" tab. click the lower Load button and watch the export table populate. Change "Table Address" to 000D2600 (or whatever value you get for "RawPointer" of .xdata in the "Section" tab preceded by three zeros) and then click the lower Save button. Go to the "Main" tab and "Check" "SizeofCode", before saving your kernel32.dll itself. Open the file in HxD. While in HxD, copy the code below into your file by right-clicking in the new section below the export table (which will correspond to 000DC000 or so, in order to give the export table some wiggle room) and then clicking the "Paste write" option. 8B FF 55 8B EC 5D FF 25 D4 15 88 6B This code represents K32GetProcessMemoryInfo, taken from the Windows 2000 extended kernel. I tried with Server 2019 initially, but found out that the kernel structure is very different from Vista, where the bulk of the code is not contained in kernel32 itself, rather it being in One-Core API dlls (not to be confused with XP extended kernel, this is of MS' doing). Even with Windows 7, which still had complete code for the functions in kernel32, things didn't work out. Reopen PEMaker, go to the "Export TBL" tab and load it, then enter the offset corresponding to the start of your function (which again will correspond to 000DC000 or so) in the third box from the left, and then the function name K32GetProcessMemoryInfo in the far-left box. The rest will be done for you. First save the export table, then save the file. Place your modified kernel32.dll in the folder of each application that requires it. Create a file labelled "xxxx.exe.local" (where xxxx is the name of the application executable) in order to direct the executable to use the modified kernel32.dll as opposed to the one in the system32/sysWOW64 folder. WARNING At present, this file seems to have issues with export table modification, whether it be through ExportTableTester or PEMaker, regardless of which action is taken with the export table (moving it, keeping the existing one and simply adding functions to it, or creating a second one with the new function). It doesn't seem to work properly and throws an error about being "not designed to run on Windows". It appears that somehow, the import, resource and relocation tables have been corrupted. A very tricky process indeed, which deviates greatly from the process for x64 libraries. UPDATE: by simply adding the function in PEMaker and not selecting the option to align the import table yet correcting file and code size, I have managed to only corrupt the import table, which is still very sad. What a comedy of errors this has been. SECOND UPDATE: it was just me again failing to realize that the export table was overwriting the beginning of the import table. I used PEMaker to move the import table address from 000C281C to 000C286C and now things are cool. I know that many of you are probably wishing that they could get binaries given the complexity... but now things are back on track using v0.82 of this tool from the great BWC: http://blog.livedoor.jp/blackwingcat/archives/1313117.html with this in mind, another revision to the instructions is incoming, involving a way to non-destructively move the export table to avoid destroying anything else. In hindsight, the decision to have these extensions alongside system files instead of replacing them was great.

So the problem is at 00128E30, so it's still my code, or more specifically K32GetProcessMemoryInfo. And in the process I've discovered a serious problem. Windows 7 x64 code that looks like this: Looks like this when placed in a Vista x64 binary: I don't have this problem with x86 binaries. This means that the functions that have been implemented are glorified stubs. They may still be useful in certain cases. I do plan on making a proper x86 kernel extension, as there are still many x86 applications around today. And hopefully I can eventually get over this setback and return to extending Vista x64. UPDATE: This just happened to me with a chunk of an x86 subroutine. It appears that I have to right-click and convert it to code (and then modify it further). I will investigate this further when I start trying to extend x64 again. And yes, the results of most of the posts of mine so far have revealed my incompetence in this arena, which is being corrected as I type.

Yes, one per line of course.

So I added those two functions and tried launching GIMP 2.10.18. However, even after getting over the hurdle represented by those two functions, there was another missing one in shell32.dll, SetCurrentProcessExplicitAppUserModelID. And it looks like it's an important one too: https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-setcurrentprocessexplicitappusermodelid Once it tried calling that one, it suddenly went crazy and crashed. Now I'm wondering if it would be better to have it forward to an API function representing XP/Vista-style taskbar grouping or keep it the way it is. But again, I'd like to focus on taking care of kernel32.dll and functions forwarded from it to ntdll.dll before the lower level dlls, as well as also making updates to the 32bit versions. Anyway, the code for these two new functions is available here: SetThreadErrorMode: 48 FF 25 D9 DC 05 00 CC K32GetModuleFileNameExA: 48 FF 25 49 2D 04 00 CC UPDATE: GIMP 2.10.0 is working, but it doesn't seem to use any of my functions. But it's still higher than the 2.8.22 that's listed in the last versions of software thread.

We are only two functions away from getting GIMP 2.10.18 to possibly work - SetThreadErrorMode and K32GetModuleFileNameExA. So the first test of the extended kernel will be very soon. If anyone can find other x64 programs that were only prevented from running on Vista by the lack of the functions that have been implemented already, that would also be good.

Yes, those are all correct.

You are on the right track. and what @Ximonite said. I forgot about section flags/characteristics. The 48 is part of the first function of course.

Unfortunately, it appears that starting with 6.0.6003.20731, they ate up most of the zeros in .txt. So the solution to that will be to add a new section, which I was intending on doing for later updates to the initial version. So right click in section headers view, click "Add Section (Empty Space)", make the size 0000B100 (looking forward to many new API functions!) and then name it .xdata. And then add the code in that section, though the offsets reset themselves per-section in section headers view so you will be telling ExportTableTester that your functions will be located at 00128E00, 00128E10, 00128E20... Given that kernel extending is typically seen as an "elite" activity in the world of Microsoft Windows, and this is the very first go of it for NT 6.x, I'm not surprised to see this level of questioning, considering that this could open up the art of kernel extension to a far wider audience than before. Though it will be for the greater good, as Vista has certainly been held back win2k-style by MS. NB: the procedure for modifying the file should be the same through 6.0.6003.20686 as in the OP though.

Which version of kernel32.dll do you have? I was quite concerned about this possibility, given that Vista has multiple update paths (through April 2017 EOL, Server 2008 updates until the one that changes the build to 6003, Server 2008 EOL and ongoing ESU). I decided to forgo all updates after Vista's EOL, and the kernel32.dll I have was actually updated in March 2016 (I know there is a later one numbered 6.0.6003.20489), so I was hoping that frequent updates to the file wouldn't take place. In any event, start adding the code on the first line with all zeros. And accordingly adjust the function addresses in ExportTableTester,

To prevent user confusion, I strongly recommend disregarding the tutorials and contacting me directly instead about the extended kernel. The original post was removed as it was continuing to confuse users. There will be further discussion about the evolution of the extended kernel in the coming pages.

Mine is: Mozilla/5.0 (%OS_SLICE% rv:42.0) Gecko/20100101 Firefox/42.0 Basilisk/52.9.0 so the OS part would be NT 5.2 in my case.

I kept the user agent override that makes it think I'm running Firefox/42.0. Now it displays a browser support warning before it lets me enter the site but it still mostly works. But sometimes it loads polymer anyway.

I'm running Serpent 2020-05-23 IA32 and there are no problems with viewing videos, even in classic (though descriptions seem to be broken/truncated sometimes in classic).

Or perhaps you don't even need a site:

I know there is invidio.us, but I found it to be much slower than classic (and similar to Polymer v1) on my T60. Even with my Xeon X5670, slowness is apparent with Polymer v1. If/when Polymer v2 is made mandatory, and Pale Moon/New Moon/Basilisk/Serpent don't support it by then, I somehow think I will be dumping Google (who has been fighting a rough battle with the YouTube "shells" working on providing alternatives for NT5/old hardware), not 2000/2003. Lots more needs to happen for me to permanently jump to another OS.

I think that only 98SE KernelEx has had a compatibility tab with options like 2000/XP/Vista. On Windows 2000, no shimming is typically required to run newer apps (but it's required more often for installers). If needed, you can do it with the included tools fcwin2k (changes OS version per-program) and NNN4NT5 (changes OS version system-wide). http://win2k.org/wlu/wluen.htm - where you can find BWC's updates and drivers. https://twilczynski.com/windows/updates/ - for official Windows 2000 updates. So, yes.

Nope, it is Windows2000-KB935839-v30e-x86-ENU.EXE. That has nothing to do with the extended kernel. You can enable it by doing regsvr32 %windir%\apppatch\slayerui.dll. It is ESR 52.9.0.

WildBill's PETool 0.0.5 can add exported functions. Under "Directories", there is an option to "Add exported function". And then its name can be added separately through the option "Add exported function name". But it is very buggy in that respect. I can't get it to show the new test function I made in the table unless I make other functions below it or do other changes and when I try adding function names, it doesn't actually do so for the selected function; I have to select the one above it to get it to add the function name. And sometimes I can get it to do stuff to the functions that are actually selected! So keep verifying with export table tester and other tools. And you can also add exports with BWC's PEMaker by inserting the necessary parameters in the fields below the export table and then pressing "Change".

I just dragged a wlu file (WindowsLU-KB975599-v3-intl.wlu) to wlupdate.vbe and it ran the hotfix installer. If you continue to have issues with WLU, you can simply extract the WLU files to a folder and run the included cmd/update.exe/etc.

hotfix confirmed working. Now running 5.00.2195.7133.

https://mega.nz/file/4hsATIiC#Nu-mOrPbXiFOnbHZ5QJRC4pDYSY2cvXPTMm-Hbwyg9c