Blender 3 alpha user32.dll win7 x64

[vvo1tv]

Do you have a solution to the problem of finding an entry point in user32.dll (Windows 7 x 64) for Blender 3 alpha?

[nalexandru]

No. From what i can see the missing functions are related to Pen input. In addition to the missing entry points from user32.dll, Blender 3 needs api-ms-win-shcore-scaling-l1-1-1.dll which is also not available on Windows 7.

This repository is for getting 2.93 to work on 7, for 3.0 i will make a new one if i manage to get it working, however there will be missing features (based on what it can't find, so far the missing features are pen input and DPI scaling).

[Juris3D]

We could live without some of those features, such option to have would be very very nice, Thank You in advance! (for 3.0)

[Juris3D]

Noob question, isn't it possible to hack out Pen Input as such from Blender's "body"?

[Limezero]

I would be interested in this as well. Backporting functionality into Windows 7's USER32.dll is probably unreasonable, but it should be possible to revert the commits which made Blender depend on GetPointerInfo, or just comment out those parts of the code entirely (thereby breaking pen support/DPI scaling if necessary).

Obviously this is going to be an uphill struggle as devs add more and more Win8/Win10 API calls to the project (like Adobe, Maxon and others), but having a major release like 3.0 run on Windows 7 without having to use a VM would be nice, for the sake of history if nothing else.

Then again, I also wish Blender would have documented this more clearly and had some sort of a deprecation plan, instead of adding two lines of arbitrary code and saying "lol fuck you update". Same goes for Python.

[nalexandru]

My initial idea was to use DLL redirection to override user32 and add the missing entry points so that the original Blender executable could be used, however this is not possible on Windows 7 because user32 is a known DLL and Blender has an embedded manifest file. The backporting is not really unreasonable (and might be necessary) because the function can return an error if the functionality cannot be implemented.

After taking a closer look at the documentation, GetPointerInfo can also be used for the mouse input so commenting out the code might not be a solution (i don't know if Blender 3.0 does this).

I think a viable solution would be to make a DLL that implements (or returns an error where it can't) the missing functionality and build Blender so that it uses that DLL instead of the Windows DLLs.

[Limezero]

I'm not too familiar with Windows internals - would it be possible to create a shim DLL, say FakeUser32.dll that exposes every function in the original one, and "implements" them by just passing the call it got to the original C:/Windows/system32/user32.dll library and returning with the result THAT returned? If so, we could then add homebrew implementations of win8/10 functions to the shim library itself without having to touch the system directories, which would be really elegant.

I don't have the time right now, but I'll take a crack at the Blender source and see what exactly they changed between 2.93 <-> 3.0 and why. It's still possible that reverting a few commits or using equivalent Win7 API calls is all it takes to regain compatibility.

[nalexandru]

What you described is the DLL redirection i was talking about. The problem with it is that user32 is a known DLL and Windows will not load it from the application directory unless it's specified in the application's manifest, which can be embedded into the executable or an external .manifest file in the executable's directory (in this case, blender.exe.manifest).

Starting with Vista, if there is an embedded manifest into the executable it takes precedence over the external one so the only way to change the manifest is to modify the executable.

More details on DLL redirection: https://www.exploit-db.com/docs/english/13140-api-interception-via-dll-redirection.pdf

[Limezero]

Ah yeah, I read about that. Still, since we can easily recompile Blender it's not a dealbreaker, it just means the solution will be less pretty than being able to drop a DLL next to an unmodified executable (which sucks, but hey).

[nalexandru]

I have managed to get it working, not sure if it has pen support as i don't have the hardware to test with. I made a new repository for 3.0 support: https://github.com/nalexandru/BlenderCompat

The modifications made to Blender are to the build system, so that it links with the compat DLL instead of the Windows ones. api-ms-win-core-path-l1-1-0.dll is still required because of Python.

I think this approach is better than reverting commits or commenting out Blender code because it's easier to maintain.

[Limezero]

Jesus, that was fast. It crashes every five seconds as Blender usually does, but other than that everything seems to work fine.

Edit: Tablet input seems to work fine as well.

[Juris3D]

First of all - WOW !! And, second - that's with the "Blender usually crashes"?? :D Crashes are extremely rare, well, for me anyway :)

[Limezero]

https://user-images.githubusercontent.com/8932874/124401808-ddd52e00-dd2b-11eb-85da-2dc756417f92.mp4

It's probably hardware-dependant. I know for about a year or two trying to use GPU rendering on AMD cards literally resulted in a BSOD (last I checked it still doesn't work unless you're using a beta driver). Regardless, it feels like whenever I click a button there's a 10-20% chance Blender will crash without an error message for no reason. Especially if it's a large file or a complex operation.

Though this is getting off topic - like I said, I doubt the DLL hack has anything to do with it (and 3.0 is still technically in alpha).

[Ayusman-Singhal]

I am not able to use blender 2.93.1. So can you please post a video on how to do it.