Sheepsnoop

I thought about this again recently and think I found a better solution that would've solved most problems that I should've looked into earlier. We should be able to just build the shell and forward all newer calls to the original windows /vista/7/10/11 dlls. Kind of like one core api, Except since we're using xp's shell for newer windows we still need to compile it because there are still calls removed that the rtm shell needs iirc. Again I don't know how to code so I have no idea how to implement forwarding in xp's src. I'm just putting it out there. Yes, that's been known for a while. It doesn't actually work beyond a broken start menu, and there is no fixing that because the functions are deleted or changed.

Update. I downloaded vista's sdk and copied the libs to xp's source, and then copied xp's shell libs back into the folder replacing anything else. I was able to almost successfully take the compiled shell and and place it into syswow64. The problem is the newer comctl32 calls something in shell32 that xp's doesn't have, isthreadex or something like that. I tried xp's comctl32 which lets me open applications but the windows are severely messed up (pic below). With just vista's comctl32 I was able to open notepad and taskmgr but I couldn't open dialogs like save as or open file. I was also able to get logonui to run. I also noticed vistas user32 gave some complaints about xp's uxtheme so I tried compiling xp's but some vista dll calls a function that it doesn't have so that doesn't work.

I have been testing .exe.local more lately. no luck though I got the xp source code and compiled only the shell for amd64, that way I could know exactly what dlls the shell is. sadly dll redirection for only the shell didn't work. I forget why exactly since it's been a few hours. Something about msvcr is different for the amd64 source compared to regular server 2003 x64 also. Maybe compiling the xp src instead of server will fix it? idk... I decided to do all my testing on vista rtm since it's the closest to xp and if I can get that working then I can work my way up. So far I know now that shell32, browseui, comdlg, shlwapi, uxtheme, and some other dlls can be redirected for normal applications fine but don't let explorer run, even though without those redirected ones explorer will run but broken. I feel like if the onecoreapi or vista extended kernel team had any interest in this then it would be relatively simple for them to do. oh well...

You may need to enable dev mode in the registry. Perhaps it's disabled on home editions and the like.

Use .exe.local and look at depends.exe or equivalant, you will see all the kernel and shells are 5.2, meaning we don't need to rename them at all. Unless in the file tree the dlls themselves still call the new ones but I'm pretty sure they don't. If they do, does a .dll.local work? Idk. Another idea I had was to completely replace syswow64. I know for a fact that windows can run completely fine with a replaced shell32 and whatnot in the x86 folder. And with the slow decline of x86 software, I'd personally be able to give up 6.0 and up x86 support. Though we could also mitigate this by using 32bit one core api in syswow64. Haven't done tests though.

This problem would be fixed by using .exe.local and keeping the shell dlls next to it though shouldn't it? I know it overrides knowndlls, but not if a program will actually run using a completely different shell than the system it's on uses. I know that ie6 in thinapp works completely on win7 and can access the c: drive fine. That was a few years ago last I tested though and now can't find a download to thinapp. I know that's virtualization, but iirc it was pretty seamless, and dropping explorer.exe in the virtual drive also ran semi well. Maybe that could be another avenue to look into... I hope I didn't come off as an a** when I said that, I just always see people answering to questions like this saying to just use classicshell, or even use linux which is a total joke of an answer. And sorta just dodge the question completely never giving an actual reason.

It's The best of both worlds. We could have the full feel of windows XP but still be compatible with new drivers and programs. I've asked before on different places but they've just said it was impossible, which I highly doubt. looking at explorer.exe with depends.exe, the only thing that fails it from laucnhing without compatibility mode on windows 7 1701 is shunimpl.dll. For explanation on shunimpl go here: https://www.geoffchappell.com/studies/windows/ie/browseui/index.htm Basically shlwapi and other things forward old calls to shunimpl, but shunimpl doesn't actually do anything but fail it, causing explorer to instantly fail. The only thing compatibility mode does is make it so it doesn't auto crash. I was able to get XP's explorer partly working without compatibility mode by taking a random dll like browseui and renaming it shunimpl.dll and putting it in system32. Since shell32 and others already dll proxy to shunimpl, I believe you could easily point it to an older DLL and gain all those missing functions, but that's above me. The next thing is the registry. I was able to make a winpe with win7pe builder and have the shell registry be that of livexp's explorer script one. It installed and ran but for some reason explorer.exe doesn't work on the winpe one even though it does on the normal 7 build which used the same iso. I've also tried putting explorer.exe in system32 of xp's and using explorer.exe.local and had slight success when running it in depends.exe. I believe if someone was to do this properly they'd need windows server core since it has no full shell to being with but idk. I haven't tested on windows 10 yet but iirc explorer.exe also worked on it but broken still with compatibility mode. These are all my findings. I just really want someone with better knowledge than me to work on this, it would be a dream come true for all the XP fans. btw no I don't accept any of the fake crap like reactos or classicshell. What I want is a true experience, with the full classic file explorer n all. If anyone decides to work on this, use x64 xp or server instead of 32 bit.

The kernels for xp 32 and 64 are different? d***, I was hoping to use this for my pro x64 machine