It could really be a game changer for company internal applications!

Agree. This is huge.

The only other options now are:

Qt

Xaml which uses skia under the hood hilariously.

Electron / webview.

Since linux version is based on glfw3 (which is also available on windows) there's a possibility that it would work also on windows. I don't have access to windows machine, so you can try it yourselves 😉

The GLFW version is temporary; the goal is to have all platforms have something closer to the current macOS level of integration where the Flutter content can be an arbitrary view within the native application.

A temporary GLFW build for Windows would be fine as well, but that wouldn't be the full implementation.

@stuartmorgan what would be 'closer' on linux site then?

GTK is a possibility that's currently being investigated. Now tracked as issue #23 since I hadn't filed it yet.

What would be closer on the Windows OS then ?

@stuartmorgan regarding the question above.

flutter/engine#4730 (comment)

Looks like the Engine builds on Windows now.

For Windows the ideal solution would use Windows APIs directly.

I don't have a Windows development background, so I don't have an informed opinion about whether C++ or C# is dominant enough within the domain to make it a clear choice for the API surface. I'm happy to hear arguments from people with significant Windows experience.

(Absent any clear consensus for C# I would lean toward C++ for a few reasons.)

C++ would allow sharing code across platforms in the plugin implementations. While this may not be a large surface area, there is at least some code in the TextInput area that would benefit from a shared model class. Also, the Flutter embedding API is in C, so use of it from C++ is straightforward; I'm not sure about the situation for C#.

That said, like Stuart I do not have a deep Windows development background, so these are just surface observations.

There have discussion about code reuse across all desktops to replace GLFW and for the plugins.

This might be a good example of it.
https://github.com/zserge/webview

Its a webview for all desktops that is written in C, and has wrappers from golang , rust and python ( separate repo).

It also handles window aspects.
It might be a decent reference point in general in order to be able to have the framework code and plugins all written in portable C.

@gedw99 I think there are diffrent. In flutter, the Paint is base. and Web has not the replacement.

Its a webview for all desktops that is written in C [...] It might be a decent reference point in general in order to be able to have the framework code [...] all written in portable C.

It's not written in portable C. It's a C wrapper around GTK-specific code on Linux, Win32 code on Windows, and ObjC Cocoa on macOS.

It also handles window aspects.

Yes, by implementing them using platform-specific toolkits, just like this project is doing on the platforms that have been implemented.

What's missing for a Windows implementation of this project is not a conceptual understanding of what needs to be written or how to write it, it's someone actually doing the work.

Good points and thanks for the clarification. I am not good enough at this level or coding to do the windows work. Wish I was.

I hope someone that does have the skills on Windows picks this up. The Mac and Linux versions are amazing to use

Would using SDL be ok ?

I only ask because i have been playing around with a FLutter Desktop that uses SDL.

This seems like the supported to support windows

https://github.com/Microsoft/cppwinrt

UPDATE:
they have moved the code into the Windows 10 SDK now.
See here for more info: https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/index

There are 3 options to embed the engine on Windows

• Win32 API

The classic Win32 API could be used. This is the most powerful Windows API. But it's old, hard to use, is written in old C style. And not future proof (no UWP support).

• .Net API

Still as powerful as Win32. C++ API. But has additional install steps (user needs to install .Net redistributable packages) and does also not run on UWP.

• Universal Windows Platform API

I think the focus should be on this. The API is future proof, easy to use, state of the art (with markup language and touch support) and runs on all Windows 10 Platforms (Xbox One etc.). Microsoft itself is converting its desktop apps to this. The problem is MS is using a costum C++ dialect and I'm not sure how hard it would be to integrate the flutter engine.

See: https://docs.microsoft.com/windows/uwp/get-started/create-a-basic-windows-10-app-in-cpp

@b-strauss Can you link to any example code using the costum c++ UWP api ?
Maybe some decent examples on github for instance.
For example this has touch and mouse and keyboard combined.
https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/Simple3DGameXaml

I tend to agree. Also with the Windows Store becoming the only way to deploy (unless you ask a user to side load) you basically have no choice as a developer but to embrace the UWP.

There is Winrt, which is now part of the latest Windows 10 SDK. But i have no idea what support for UWP it has.
This does shine some light on it though: microsoft/Windows-universal-samples#851

@gedw99

You have to be careful with the terminology here.

There was/is C++/CX which is a C++ language extension to be used for UWP app development.

The new thing now is C++/WinRT which is a new C++ "language projection" based on C++17 to be used for UWP app development (not to be confused with the actual Windows Runtime the platform runtime or WindowsRT a discontinued Windows mobile variant).

IMHO we should be using the things Microsoft suggests, which is:

The Universal Windows Platform API (UWP) for cross platform support together with C++/WinRT.

https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/

To quote Microsoft:

There is not a roadmap for deprecation of C++/CX. However, all of our conversations with customers shows usage to be very low. We’re investing heavily in C++/WinRT and we expect that it will provide a much better experience than C++/CX.

https://blogs.msdn.microsoft.com/vcblog/2017/11/01/cppwinrt-is-now-included-the-windows-sdk/

Skia seems to have some level of support:
https://skia.googlesource.com/third_party/sdl/+/master/docs/README-winrt.md

@b-strauss
Thanks for the clarification.

The last to link to the SKIA winrt support is a big bonus !!!
Also i noticed it say SDL applications. This would be great because SDL is quite easy to work with i find.
What confuses me is that in the Mac and linux ports in this repo there is no SDL. Its like a split brain with mac and linux and windows being built on a different bridging layer

I am hoping that the team start on this. My problem right now is that there is no basic build for windows yet or even architectural clarification ( but winrt looks like the one to me).
Once some meat is on the bones i can help i feel.

My problem right now is that there is no basic build for windows yet or even architectural clarification

As mentioned above, I would be happy to review and land an initial basic build separate from a decision about long-term architecture (as with Linux and the GLFW implementation). Several people indicated interest on the mailing list in helping with a Windows implementation, but so far nobody has sent any PRs or otherwise followed up.

Or GLFW, or any other workable interim solution. A simple throw-away implementation (enough to support drawing and mouse events) that lets people try it out on Windows would be useful to have until there's a full implementation.

Just a note on OpenGL and desktop applications: with the Nvidia drivers (under assuming Nvidia card) these do not work properly with Remote Desktop (Intel's for example is fine, maybe AMD too). Off course there is Google angle, but it wraps GLES not OpenGL (or maybe I have outdated information). Just FYI

I'll experiment with the UWP stuff over the long weekend. Maybe I can draw something onto the screen with angle, but my c++ knowledge is limited.

@clarkezone I'm getting an error when running the code with Visual Studio 2017 Community Edition. Do I need another Visual Studio Version? Thanks.

@b-strauss The currently landed code, which it looks like is what you are running there, is @CallumIddon's implementation, not the code @clarkezone has been working on (which is now tracked in #101)

See the discussion at the end of #87; I'm also unable to run it from VS (although the error I saw was different), but it works for me from the command line. I'd suggest seeing if the same is true for you.

Either way, please file a new bug for your issue so it can be tracked.

@b-strauss should be fixed in #106. If you could test it and let me know in that pull if it works or not it would be greatly appreciated.

TLDR - Delayloading (/DELAYLOAD:flutter_engine.dll) solves the crashing issue while debugging in Visual Studio.

What happens is that in the debugger, or maybe due to other circumstances, some thread exited (happened to be from the NVIDIA drivers), which is normal and expected, but Dart, more specifically flutter_engine.dll has established this "DllMain"-like handler (for lack of better explanation): https://github.com/dart-lang/sdk/blob/master/runtime/vm/os_thread_win.cc#L712 - e.g.

#pragma data_seg(".CRT$XLB")
PIMAGE_TLS_CALLBACK p_thread_callback_dart = OnDartThreadExit;

and

void NTAPI OnDartThreadExit(PVOID module, DWORD reason, PVOID reserved) {
  if (!dart::private_flag_windows_run_tls_destructors) {
    return;
  }
  // On XP SP0 & SP1, the DLL_PROCESS_ATTACH is never seen. It is sent on SP2+
  // and on W2K and W2K3. So don't assume it is sent.
  if (DLL_THREAD_DETACH == reason || DLL_PROCESS_DETACH == reason) {
    dart::ThreadLocalData::RunDestructors();
    dart::MonitorWaitData::ThreadExit();
  }
}

Now if this handler is called with DLL_THREAD_DETACH reason (as it happened with NVIDIA's driver), then it'll try to:

    dart::ThreadLocalData::RunDestructors();
    dart::MonitorWaitData::ThreadExit();

but Dart::InitOnce (https://github.com/dart-lang/sdk/blob/master/runtime/vm/dart.cc#L111) wasn't yet called, which would later call "OS::InitOnce();" then call (for os_win.cc) "ThreadLocalData::InitOnce" which would've initialzied two globals (mutex_ and thread_locals_) which were actually NULL when this happened.

Or maybe somewhat better order of initialization...

Oh, sorry - should've checked your messages above. I've run into similar issue with https://github.com/ds84182/flutter_sdl and had to fix it, but now that I saw the change in the main line decided to give it a try.

Seems to work fine, and flutter_gallery's example works too! Had to add whatever was done in the "example":

import 'package:flutter/foundation.dart'
    show debugDefaultTargetPlatformOverride;

void main() {
  // Desktop platforms are not recognized as valid targets by
  // Flutter; force a specific target to prevent exceptions.
  debugDefaultTargetPlatformOverride = TargetPlatform.fuchsia;
...

https://drive.google.com/open?id=1_DPr9kmoy3sGCCXb6WNAUoBkI6DcNHe4 (45mb zipped file with the gallery example).