Paint.NET 3.36 installer wont start due to CreateFileMappingW() returned NULL

[jusefn]

My Setup:
86box with
i430FX ASUS P/I-P55TP4XE
Intel Pentium with Frequency set to 120
64MB RAM
Windows 95 OSR 2.5
IE 5.51 (5.51.4807.2300)
USB Supplemental Installed

Paint.NET version 3.36 (should run with .NET 3.5, SetupShim.exe fails due to an unsupported version of Windows)

Installation fails after launching SetupFrontEnd.exe with following error

System.ComponentModel.Win32Exception: CreateFileMappingW() returned NULL (120)
at PaintDotNet.SystemLayer.SinglelnstanceManager.. ctor(String moniker)
at PaintDotNet.Setup.SetupWizard.GetAppSinglelnstanceManager()
at PaintDotNetSetup.SetupWizard.MainImpl(String[] args)
at PaintDotNetSetup.SetupWizard.Main(String[] args)

I also launched the Lego Island Rebuilder to test if my .NET installation is even working and i am getting the following error code

I would assume that my IE installation may be too new so I am going to setup a fresh Win95 installation later but wanted to give a heads up with these issues.

EDIT: 2024-04-33

Turns out the version of Rebuilder I tested was not the .NET 2.0 build, tried again with the .NET one and Rebuilder opened successfully. Removed the Error in this issue as that would be more appropriate to be reported in the Lego Island Rebuilder repository.

[whindsaks]

CreateFileMappingW is probably not implemented on 95. The wrapper needs to translate the name (if any) and call the A function.

[GravisZro]

CreateFileMapping does exist in the Win32 API for 95 but CreateFileMappingA/W does not.

[itsmattkc]

Windows 95 does have CreateFileMappingW, the issue must be something else.

Unfortunately this is where the backport falls short a little. SetupShim.exe is calling a Win32 API directly rather than through any standard .NET library, which means our only recourse is patching Paint.NET itself. Or sidestepping to a more formal kernel extender (#4 (comment))

[whindsaks]

Windows 95 does have CreateFileMappingW

It is exported but probably does not work. Very few W exports work on 95 (< 1%).

[andresvettori]

Official Microsoft documentation says CreateFileMappingW is only supported on Windows XP onwards.

https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-createfilemappingw

[itsmattkc]

Official Microsoft documentation says CreateFileMappingW is only supported on Windows XP onwards.

Microsoft documentation isn't reliable. It also says CreateWindowA is only available from "2000 Professional" upwards when it too is very much available on 95.

It is exported but probably does not work. Very few W exports work on 95 (< 1%).

You're right, looking at the function in Ghidra, it appears to just return a ERROR_CALL_NOT_IMPLEMENTED. I've also seen W functions just wrap to A functions, which would probably be our solution to this, but it doesn't change the difficulty of having to patch Paint.NET directly with the current approach.

[whindsaks]

Microsoft documentation isn't reliable

In their mind it's exactly as they intend. You see, when a page says ”Minimum supported client: Vista" that just means that the last time that particular page had a major update, Vista was the oldest OS still receiving updates from Microsoft AKA "supported". They also delete older KB articles with useful information just for fun. And they have deleted all downloads older than 2015 or whatever year it was.

I've also seen W functions just wrap to A functions

The design is, MessageBoxW works and a handful of other things so that a Unicode-only application can then do a little bit of startup, discover that it's not on NT and exit with an error message.

[jamsilva]

Windows 95 does have CreateFileMappingW, the issue must be something else.

Unfortunately this is where the backport falls short a little. SetupShim.exe is calling a Win32 API directly rather than through any standard .NET library, which means our only recourse is patching Paint.NET itself. Or sidestepping to a more formal kernel extender (#4 (comment))

A large number of the W functions are implemented by the Microsoft Layer for Unicode (aka Unicows) and its open source alternative Opencow.

You should be able to just redirect calls to the regular dlls with calls to one of these and get things working.

[GravisZro]

@jamsilva Opencow a great find!
FYI, part of the implementation is to reject the *W stubs that MS put in.

I opened a discussion on integrating these kind of polyfills here: #37