Open Sourcing Update

[vatsan-madhavan]

We are happy to announce that we are open sourcing (#2553) native components in WPF – wpfgfx_cor3.dll and penimc_cor3.dll. With this, we have completed all planned open-sourcing work for WPF on .NET Core.

PresentationNative_cor3.dll and a small library used by wpfgfx_cor3.dll (bilinearspan.lib) contain proprietary content and are not being open sourced.

These sources have gone through extensive preparatory work – for e.g., sanitizing them to remove content that is not suitable for open-sourcing (e.g., internal-bug database references, user names etc.) of which there were several thousands of instances, identifying and excluding proprietary IP, and security cleanup (for which we used Semmle – please check it out at https://www.semmle.com).

In addition to this news, we have been making continuous improvements to .NET Core 3.1. You can see information about .NET Core January 2020 update here (dotnet/core#4119), and the February 2020 update will be out soon this month.

Cheers!
WPF Team
@dotnet/wpf-developers

[wjk]

Question for you. I understand PresentationNative has a dummy project file that extracts the prebuilt DLL from a NuGet package. AFAICT, there is no such mechanism for bilinearspan.lib. wpfgfx.vcxproj contains a direct ProjectReference to bilinearspan.vcxproj, which is of course missing. As such, this project cannot be built outside of Microsoft currently. Are there any plans to fix this, so that wpfgfx can be successfully built from source modulo this one file? Thanks!

[vatsan-madhavan]

There are build targets in place that transparently supply missing ProjectRefereces from prebuilt-libs or DLL’s. Wpfgfx Is designed to be buildable by anyone, and you should be able to do so right away.

[yekanchi]

Is there any plan to open source (buildable of course!) components like Rehosted Workflow Desinger which are actually a presentation layer for workflows in wpf?

[rladuca]

@richlander Can you help answer @yekanchi ?

[rladuca]

@wjk Take a look at:

wpf/eng/WpfArcadeSdk/tools/WpfProjectReference.targets

Line 110 in b20dc4c

<Target Name="EnsureWpfProjectReference"

and then:

wpf/eng/WpfArcadeSdk/tools/SdkReferences.targets

Line 155 in b20dc4c

Name="ResolveMicrosoftDotNetWpfDncEngReferencesForCpp"

That should give you the basic idea of how the ProjectReference replacements work.

[cbaysinger]

Congratulations on this milestone. Your team has been working on this for months including holidays and we appreciate the teams efforts. Can you give us some insight into the bug fixes and release plans going forward. Thanks again, Craig From: Vatsan Madhavan [mailto:notifications@github.com] Sent: Tuesday, February 11, 2020 6:18 PM To: dotnet/wpf Cc: Subscribed Subject: [dotnet/wpf] Open Sourcing Update (#2554) We are happy to announce that we are open sourcing (#2553<#2553>) of native components in WPF – wpfgfx_cor3.dll and penimc_cor3.dll. With this, we have completed all planned open-sourcing work for WPF on .NET Core. PresentationNative_cor3.dll and a small library used by wpfgfx_cor3.dll (bilinearspan.lib) contain proprietary content and are not being open sourced. These sources have gone through extensive preparatory work – for e.g., sanitizing them to remove content that is not suitable for open-sourcing (e.g., internal-bug database references, user names etc.) of which there were several thousands of instances, identifying and excluding proprietary IP, and security cleanup (for which we used Semmle – please check it out at https://www.semmle.com). In addition to this news, we have been making continuous improvements to .NET Core 3.1. You can see information about .NET Core January 2020 update here (dotnet/core#4119<dotnet/core#4119>), and the February 2020 update will be out soon this month. Cheers! WPF Team @dotnet/wpf-developers<https://github.com/orgs/dotnet/teams/wpf-developers> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#2554?email_source=notifications&email_token=AFJQKYGVQBXXBMODKDSCGZDRCNE3DA5CNFSM4KTPZ3S2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IMY53RQ>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFJQKYFKV35NNQPN4JRFCD3RCNE3DANCNFSM4KTPZ3SQ>.

[jtbrower]

Excellent, I love seeing any and all effort put in towards WPF improvements, including open sourcing it. Thank you for your efforts.

[SariDev]

Congratulations!
It's great to see that WPF all open-sourcing work have been accomplished.

If I remember it correctly the initial goals of this repo were:

• Open sourcing WPF
• Writing tests and publishing them here
• Fixing critical bugs while doing this

Is this project now in a state were feature suggestions from the community will be tackled for the .NET Core / WPF 5.0 release?

I would like to see an update for the WPF Roadmap and see what the WPF team is planning for V5.0 and if the community can collaborate with the team for V5.0 (new features, fixes, suggestions...).

The readme.md's status section would also need an update.

[Ruedii]

Is there a way those remaining proprietary libraries can be blobed as included Restricted Freeware binaries to assist porting efforts?

Also is there any way the API documentation of the said binaries could be released so an alternative implementation can be written@

Finally is there a way that the Windows version of .Net, and it's remaining proprietary components have it's license adjusted to permit running under non-Microsoft platforms,.so it can be used in Binary form as Freeware for porting stacks.

[weltkante]

@Ruedii what exactly do you mean? They are already distributed as binary blobs through a nuget archive downloaded during the build. However those DLL and lib are native code not .NET, it doesn't run on non-windows platforms in the first place - you'll have to replace them with a ported implementation just like you have to replace DirectX or HWND usage with ported implementations. Note that .NET Core on Linux/Mac doesn't even have the concept of C++ mixed mode assemblies so porting those parts requires rewriting them anyways.

For what its worth bilinearspan.lib has a corresponding source file so I don't know exactly why its distributed as a blob (maybe its a specially optimized version they distribute) - so this leaves only PresentationNative which isn't open sourced, and you'll just have to treat it like porting DirectX and HWND usage.

Yes, having the API to PresentationNative.dll documented would be "nice to have", but honestly its just text layout and you most likely won't want to reimplement the API anyways. I already looked at it and the API is highly coupled to the implementation, what you'll want to do is replace the text layout logic in C# to use a different library instead of reimplementing the PresentationNative API for the text layout engine.

[miloush]

For what it's worth I believe the text layout is long overdue a major update anyway to bring it on par with latest DirectWrite (languages support, vertical text, color fonts, math etc.), so perhaps there is an opportunity there for having this bit replaced with open source.

I agree with @weltkante though that that would be of little help with running it on other platforms.

[vatsan-madhavan]

Is there a way those remaining proprietary libraries can be blobed as included Restricted Freeware binaries to assist porting efforts?

We will research this and get back to you 😄. I honestly don't know the answer, but I suspect that we'll figure this out as part of dotnet/core#2955.

bring it on par with latest DirectWrite (languages support, vertical text, color fonts, math etc.),

A lot of this can be done in DirectWriteForwarder + PresentationCore. What's in PresentationNative has to do with logical layout of lines, grids etc. I'm not saying that the latter is uninteresting or unimportant - just that there are a great many things related to text rendering can be improved now and PresentationNative (i.e. lack of its sources) would probably not hinder these improvements.

having the API to PresentationNative.dll documented would be "nice to have"

Apologies for being being the bearer of a "no" answer again about this 😞, but I'm afraid that PresentationNative related documentation is not something we expect to put out.