Flutter-desktop-embedding: Windows Support

[loic-sharma]

It seems like there should be an issue tracking all major operating systems. Windows support would also be awesome! :)

[aloisdeniel]

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

[ghost]

Agree. This is huge.

The only other options now are:

Qt

Xaml which uses skia under the hood hilariously.

Electron / webview.

[charafau]

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 😉

[stuartmorgan]

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.

[charafau]

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

[stuartmorgan]

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

[ghost]

What would be closer on the Windows OS then ?

[ghost]

@stuartmorgan regarding the question above.

[ghost]

https://github.com/flutter/engine/pull/4730#issuecomment-375285887

Looks like the Engine builds on Windows now.

[krisgiesing]

For Windows the ideal solution would use Windows APIs directly.

[ghost]

What about language preferences for writing plugins. Maybe the team has a
preference ?
C++, c# or other ?

On Thu, Mar 22, 2018, 5:26 PM krisgiesing [e-mail] wrote:

For Windows the ideal solution would use Windows APIs
https://msdn.microsoft.com/en-us/library/aa383723(v=vs.85).aspx
directly.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/flutter-desktop-embedding/issues/6#issuecomment-375368984,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATuCwgj1ZruiqTPQc3hnootLRvet01Knks5tg9CagaJpZM4STp5K
.

[stuartmorgan]

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.)

[krisgiesing]

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.

[ghost]

That's a really good point about reuse.

I am currently using golang to write some plugins. It's a little more work
but not much because the gomobile framework generates the binding for you
so you end up with a Android and iOS framework ready to be used.

On desktop you can call c libs that OS has but using system calls. If you
have many OS binaries or method calls to talk to use cgo or the excellent
CforGo project which code generates all the code from an xml file.
https://github.com/xlab/c-for-go

On Sun, Mar 25, 2018, 4:02 AM krisgiesing [e-mail] wrote:

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 are 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.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/flutter-desktop-embedding/issues/6#issuecomment-375939587,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATuCwnHG3WTugLPWoJSengPD_Ubk-sPZks5thvrDgaJpZM4STp5K
.

[ghost]

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.

[Gaubee]

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

[stuartmorgan]

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.

[ghost]

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

[ghost]

Would using SDL be ok ?

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

[ghost]

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

[b-strauss]

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

[ghost]

@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: https://github.com/Microsoft/Windows-universal-samples/issues/851

[b-strauss]

@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

[ghost]

@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.

[stuartmorgan]

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.

[ghost]

Thanks for the response.
It would be great for this to move forward.

You mean an SDL based approach right ?

On Mon, May 7, 2018, 7:49 PM stuartmorgan [e-mail] wrote:

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.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/flutter-desktop-embedding/issues/6#issuecomment-387146887,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATuCwuL9Hu_mTEhL3zRvNfMkGOPHYh6qks5twIkTgaJpZM4STp5K
.

[stuartmorgan]

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.

[ghost]

Ok so its more of a proof of concept.

Did some googling on this and it seems SDL proof of concept with SDL is
happening.

https://github.com/ds84182/flutter_sdl

• SDL based for Desktop.
• Nice thing abotu SDL of course is that its cross platform and so you get
  All desktops and even rasp pi

https://github.com/flutter/engine/pull/4730

• engine PR for Windows.
• waiting on beta 3 which was today :)

On Tue, 8 May 2018 at 19:58 stuartmorgan [e-mail] wrote:

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.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/flutter-desktop-embedding/issues/6#issuecomment-387489040,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATuCwntYpel3m5faxI88ClTPG2FsO0lUks5twdzQgaJpZM4STp5K
.

[malkia]

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

[b-strauss]

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.

[stuartmorgan]

Great! I'm happy to help on the C++ aspects; feel free to ping me on a work-in-progress branch (no matter how rough or incomplete) with questions.

[njskalski]

Yeah, I would like to give it a look as well, got some experience in cross-platform 3D software (games). I am however missing something like a list of TODOs. On the one hand you have the example GLFW Embedder, on the other the ticket is open. So what exactly is needed to consider Flutter running on Windows? Do we have a list bunch tests to turn green, or do we need to write them as well?

[b-strauss]

@njskalski The GLFW embedder would just be a sandbox or playground to show basic things. A complete solution involves getting flutter onto the Universal Windows Platform with C++/WinRT.

This would include:

• making Skia run on UWP; this requires some sort of bridge because UWP has no native opengl support; something like angle could be used
• making the flutter engine run on UWP
• creating a flutter XAML view in UWP that receives the native events (pointerevents, etc.)

[stuartmorgan]

On the one hand you have the example GLFW Embedder, on the other the ticket is open

We have it on Linux; there's currently nothing set up in the repository that builds on Windows.

The minimum to close this issue would be to have a windows/ directory that contains an embedder (even if it's essentially identical to the original GLFW Linux implementation) for example_flutter, including build files and instructions.

If we get to that point, I'll close this out and track a full (UWP or Win32) implementation in another issue. (But if we skip directly to a UWP initial implementation, that's great too.)

[clarkezone]

@b-strauss did you get anywhere? I work on the compositor team at microsoft and am familiar with what we’re doing with c++/winrt which is the future for native dev. @stuartmorgan woudl love to chat about taking your above MVP and seeing if we can run with that.

[b-strauss]

I had problems with setting up the engine (gclient errors). I did not have time to continue since then. 😞

[b-strauss]

See https://groups.google.com/forum/#!topic/flutter-dev/IyXM4D7OKyg for details.

[clarkezone]

OK I'll try building the engine on windows myself and see if I can get past that. I think the best solution would likely be Angle + C++/WinRT with both a desktop and UWP host. Have been playing with some of the new hosting API's my team builds as seen here https://twitter.com/Clarkezone/status/1005658900115308545 and those might be applicable here as well.

[b-strauss]

Sounds great. I didn't know C++/WinRT could be used without UWP. What would be the platform then? Win32 or .Net?

[clarkezone]

Sounds great. I didn't know C++/WinRT could be used without UWP. What would be the platform then? Win32 or .Net?

@b-strauss yes indeed ;-) its win32. BTW dont suppose you can point me at instructions to build flutter engine on windows?

_{Sent with GitHawk}

[slightfoot]

@clarkezone Just a few days ago I thought I'd give this a go. The build bot now builds windows embedder DLL files. I used the guide and linked example to try and get a version on windows working but I didn't have much luck. Looks like a crash in the DLL caused during DllMain execution because it crashes before my code starts. Check it out and perhaps you have better luck. Post back your results.. I'm very interested.

https://groups.google.com/forum/#!topic/flutter-desktop-embedding-dev/MX1Scz3ITAs
https://github.com/flutter/engine/wiki/Custom-Flutter-Engine-Embedders

[slightfoot]

Here's the windows-embedder library as of:
https://github.com/flutter/engine/commit/63e2071da8bd4400addab933f32b9e8728702c1b

https://storage.googleapis.com/flutter_infra/flutter/63e2071da8bd4400addab933f32b9e8728702c1b/windows-x64/windows-x64-embedder.zip

[clarkezone]

Here's the windows-embedder library as of: ...

@slightfoot thx will take a look

_{Sent with GitHawk}

[b-strauss]

@clarkezone build instructions are here:

https://github.com/flutter/engine/blob/master/CONTRIBUTING.md

[stuartmorgan]

I'd definitely start with trying to use the prebuilt engine, although if there are engine issues on Windows having a build may become necessary to debug/fix.

In theory you should be able to run flutter-desktop-embedding/tools/dart_tools/bin/update_flutter_engine.dart on Windows to get the right version for your Flutter tree. In practice it hasn't been run on Windows yet, so if you run into issues with it let me know!

[b-strauss]

I added some initial glfw code based on this. I'm using visual studio community edition. The thing compiles and starts to run, but I'm getting an error.

https://github.com/b-strauss/flutter-desktop-embedding/tree/feature/glfw/windows-glfw

[stuartmorgan]

I don't know if it's what's causing the crash, but that code is using the old .flx format, which as far as I know isn't buildable with any version of Flutter that has a prebuilt Windows engine. So I strongly suspect that you are either using an old Flutter tree that doesn't match the engine version, or you're pointing the engine at a file that doesn't exist (or is very stale if your example app was build with flx at some point in the past).

You'll want to change that to "build/flutter_assets"; if it's not the cause of the current crash, it's something that will cause problems later.

[b-strauss]

I'm still getting the same error. I suspect the code is probably just to old. Maybe someone can take a look?

https://github.com/b-strauss/flutter-desktop-embedding/tree/feature/glfw/windows_glfw

I updated the build commands. People should be able to build this now after downloading the needed dll files. See readme.txt for more info.

[stuartmorgan]

Your readme is giving a precise engine version but doesn't say anything about the Flutter version you are using; that's a really good way to get a mismatch. The engine version must match the version specified in your Flutter tree.

Is there a reason you aren't using the script to download the right version automatically?

[stuartmorgan]

Also, you're still not passing the flutter_assets path to the engine; you removed the flx path, but didn't add the correct asset path.

You need to have run 'flutter build bundle' in the directory of the Flutter application you are trying to load, and you need to pass the resulting build/flutter_assets directory as the assets_path in the struct.

[clarkezone]

@slightfoot I was able to download the binaries per your instructions above and at least get the dll to load and give me a bad configuration message in win32 which isn't surprising as I didn't attempt to get Angle up yet ;-). But off to a start. I have other pieces in different places, will start bringing them together.

[clarkezone]

Per my last comment to @slightfoot, the flutter binary loads fine from a win32 context. I just tried loading it from an appcontainer context and getting an AV/exception thrown in the flutter startup code in this file: os_thread_win.cc.. I'm not seeing that in the engine source tree unless I'm missing something. Looking at the disassembly looks like a lock / semaphore is not getting acquired correctly.

[stuartmorgan]

From my local engine checkout, it looks like that's coming from a Dart dependency:
https://dart.googlesource.com/sdk.git/+/master/runtime/vm/os_thread_win.cc

[slightfoot]

@clarkezone that was the same issue I had. I think the next option is to attempt to build the engine.

[clarkezone]

In the process of integrating Angle with the win32 version, I'm now hitting the same issue there as well.. interestingly the call to D3D11CreateDevice is what's causing it in this case. @slightfoot any insights / pointers / learnings you can share? Next step is to build the engine and attempt to debug.

[clarkezone]

@stuartmorgan so now I can build the engine (yea) I commented out the body of OnDartThreadExit and everything is working well enough to make forward progress. Haven't figured out where threadexit is being hooked nor what the root cause is for the null reference exception in rundestructors.. maybe later :-)

[CallumIddon]

I have a basic version working on Windows that implements rendering and mouse events based on https://github.com/google/flutter-desktop-embedding/pull/12 with instructions on getting up and running on Windows over at https://github.com/CallumIddon/flutter-desktop-embedding/tree/GLFW-Windows/.
Should I file a PR?

[stuartmorgan]

Awesome, please do! As I mentioned above, I'm happy to have an initial implementation in the tree ASAP even if it will likely be replaced soon by a more extensible version.

[clarkezone]

As an FYI I have also got my Angle-based Windows version going now as well, but it will require a couple of Flutter Engine changes that I plan on submitting PR’s for before I can submit anything to the embedder repo. I will keep these in my branch for now

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10

---

From: stuartmorgan [e-mail]
Sent: Sunday, July 8, 2018 8:08:27 PM
To: google/flutter-desktop-embedding
Cc: James Clarke; Mention
Subject: Re: [google/flutter-desktop-embedding] Windows Support (#6)

Awesome, please do! As I mentioned above, I'm happy to have an initial implementation in the tree ASAP even if it will likely be replaced soon by a more extensible version.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fflutter-desktop-embedding%2Fissues%2F6%23issuecomment-403347375&data=02%7C01%7C%7C3c5b07b853a746869f0408d5e5493e0f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636667025084908548&sdata=rjSqwdK0nFqz0ueJWEqdjPO3Bznz9GZM5qR%2F0HKF76k%3D&reserved=0, or mute the threadhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABE3OoBiTMUH5ZrDOs4p58_3_Vh6XGwxks5uEskrgaJpZM4STp5K&data=02%7C01%7C%7C3c5b07b853a746869f0408d5e5493e0f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636667025084908548&sdata=BWpsh5WmKreRW11LfiWr1%2FX04lPPgF8Xn%2F71RY5b8do%3D&reserved=0.

[stuartmorgan]

The GLFW Windows implementation is landed! 🎉 Thanks to @CallumIddon, as well as to everyone who provided information and feedback during all the Windows discussion.

I'm closing this out now, with #101 tracking the next stage implementation, so interested parties will want to follow that issue.

[b-strauss]

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

[stuartmorgan]

@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 https://github.com/google/flutter-desktop-embedding/pull/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.

[CallumIddon]

@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.

[malkia]

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...

[clarkezone]

Correct, that’s what I was seeing also. I have filed a bug on the dart project with a suggested fix.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10

---

From: malkia [e-mail]
Sent: Sunday, July 15, 2018 6:38:18 PM
To: google/flutter-desktop-embedding
Cc: James Clarke; Mention
Subject: Re: [google/flutter-desktop-embedding] Windows Support (#6)

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#L712https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdart-lang%2Fsdk%2Fblob%2Fmaster%2Fruntime%2Fvm%2Fos_thread_win.cc%23L712&data=02%7C01%7C%7Cbc53b87430114e4ea42e08d5eabccee5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636673018995625033&sdata=Kjc8MdUcrB8xW7iZcPotxOGimdaV%2BkSMNiqS5466brY%3D&reserved=0 - 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#L111https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdart-lang%2Fsdk%2Fblob%2Fmaster%2Fruntime%2Fvm%2Fdart.cc%23L111&data=02%7C01%7C%7Cbc53b87430114e4ea42e08d5eabccee5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636673018995625033&sdata=MtPss4a%2F6frc4A6w3TX1BaJFE8QjoEyzLJkO11nAROY%3D&reserved=0) 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...

[image]https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuser-images.githubusercontent.com%2F51738%2F42740585-3b6a6b64-885e-11e8-89de-8735f2059a9c.png&data=02%7C01%7C%7Cbc53b87430114e4ea42e08d5eabccee5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636673018995625033&sdata=tOGNCPWebIb%2F1jheeQUoPs09HJsFNaIRyj27Ei7O9CQ%3D&reserved=0

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fflutter-desktop-embedding%2Fissues%2F6%23issuecomment-405133788&data=02%7C01%7C%7Cbc53b87430114e4ea42e08d5eabccee5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636673018995625033&sdata=7SsvsjBgUrfUtnhHLtDJ%2FXEsfWsV5eCw5spX3%2BS0I%2F0%3D&reserved=0, or mute the threadhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABE3OhHsxluNT-v9TWeSeXp06AGsk6JJks5uG-6KgaJpZM4STp5K&data=02%7C01%7C%7Cbc53b87430114e4ea42e08d5eabccee5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636673018995625033&sdata=MDAHWwcAeuBDBJhwo1F2t3FYPtMGs1bMUww7RVbAGOU%3D&reserved=0.

[malkia]

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.

[malkia]

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).