Compatibility with windows 11

[CBenghi]

Hello,
I have just noticed that this code is not aligned with the version of esent.dll shipped with windows 11.
At least some files created with the version of esent.dll shipped with Windows 11 cannot be opened with this code.
Is there a plan to align the code here with what ships with Windows?
Thanks,
Claudio

[JakeSays]

Claudio Benghi (@CBenghi) Here is a good overview of future plans: #21 (comment)

[CBenghi]

Thanks for the heads up, Big Jake (@JakeSays).

Brett A. Shirley (@MsftBrettShirley),
thanks for the clarification in #21.

TLDR: please release, even sporadically, a version of the code compatible with the latest version deployed across all shipped versions of Windows.

That would allow us to keep waiting for the open version of ese indefinitely, reducing pressure on you, while keeping the project alive.

Long form.

I'm the maintainer of a project relying on ManagedEsent for data storage.

Our users rarely have a need to share content files between themselves, so compatibility issues across versions were infrequent in the past.

Until now, when issues occurred, we could ask our users to update to the latest Windows 10 patch and that would resolve the problem.

Now this cannot be done because Windows 10 and 11 have diverged in the version of esent.dll, and its not possible to ask all users to upgrade windows version.

If you published a version that was capable of reading the latest files, we could deploy its binaries and prevent versioning issues across platforms in the future.

At the moment this is not an option, because if we deploy the current version of the open source dll, we would not be able to read the contents that users on windows 11 have already produced.

Lacking this, the only path forward that I can see is to deploy some conversion service online based on the latest win 11, and move to another persistence format dropping the use of ese as a backing format, but that would be a lot of pain.

Perhaps it was a mistake on our side to chose esent in this scenario, but with your help we can make it work and remain on a technology that has served us well for many years.

Many thanks,
Claudio

[MsftBrettShirley]

We are working to bring the repo up to date with the format released in Windows 11. It is years of backlogged changes to port, so we cannot be certain of the timeframe this will be done in. I will try to update this thread as info becomes available. This is very similar to the issue for Windows Server 2025: #35.

[MsftBrettShirley]

Thanks for the heads up, @JakeSays.

@MsftBrettShirley, thanks for the clarification in #21.

TLDR: please release, even sporadically, a version of the code compatible with the latest version deployed across all shipped versions of Windows.

That would allow us to keep waiting for the open version of ese indefinitely, reducing pressure on you, while keeping the project alive.

Long form.

I'm the maintainer of a project relying on ManagedEsent for data storage.

Our users rarely have a need to share content files between themselves, so compatibility issues across versions were infrequent in the past.

Until now, when issues occurred, we could ask our users to update to the latest Windows 10 patch and that would resolve the problem.

Now this cannot be done because Windows 10 and 11 have diverged in the version of esent.dll, and its not possible to ask all users to upgrade windows version.

If you published a version that was capable of reading the latest files, we could deploy its binaries and prevent versioning issues across platforms in the future.

At the moment this is not an option, because if we deploy the current version of the open source dll, we would not be able to read the contents that users on windows 11 have already produced.

Lacking this, the only path forward that I can see is to deploy some conversion service online based on the latest win 11, and move to another persistence format dropping the use of ese as a backing format, but that would be a lot of pain.

Perhaps it was a mistake on our side to chose esent in this scenario, but with your help we can make it work and remain on a technology that has served us well for many years.

Many thanks, Claudio

I am sorry I am seeing this so late. Or perhaps I saw and didn't make the connection to the EFV feature until now. But ESE has a feature that is designed to solve this backwards/forwards compatibility requirement.

We have a JET_paramEngineFormatVersion that allows you to hold the ESE format back in time ... so you could figure out the version of your lowest Windows 10 box, or perhaps even earlier that you want to keep compatibility and set the param to the JET_efv* value that matches that ... then a Windows 11 box will purposefully keep the format stuck back in time (of course you would not be able to use any of those format features as well obviously) and then the DB can be freely used amongst all versions of the OS later than that EFV / compat level you set..

There are a variety of product named JET_efv* values in the jethdr.w, this one might suit you:
#define JET_efvWindows10v2Rtm 8620 // Final format version for Windows 10 Version 1511 (Threshold 2).

But do not feel constrained to them, best to take your oldest supported release, create a DB there and dump it with:

eseutil /mh EseJetBackupApiShouldWorkInImplicitSingleInstMode.edb | findstr /c:"Format ulVersion"
Format ulVersion: 0x620,160,340 (attached by 9680 SB UV)

... then look up the last two numbers of "0x620,130,280" piece in the sysver.cxx file. And use that value. I know the first value is hex, and implies the later might be, but the 2nd and 3rd numbers are printed in decimal. And that will give you the JET_efv* value enum that you need.

Since you already unfortunately have many upgraded databases, you probably also want to or | in JET_efvAllowHigherPersistedFormat to your choosen downlevel JET_efv enum value. Without this value, the DB engine rejects attaching a database that is higher the listed format - even if the engine understands that format version.