WinApi wrapper components

[ilopX]

I suggest opening a separate folder for winApi wrapper components.
For example, for such wrappers as:

• Registry
• Win32 window - Implementation example
• Print documents
• System Tray
• etc.

[timsneath]

I'm very interested in the idea of providing a higher-level abstraction over these Win32 APIs; there are a couple of other issues relating to this, including:

• Closed: High-level wrapper APIs for Win32
• Open: Wrapper for IDispatch

I've also written a couple of packages that wrap Win32 APIs in more idiomatic Dart, for example: https://github.com/timsneath/filepicker_windows

A couple of questions that are probably worth considering:

Who is the target audience?

For Flutter at least, the ideal is that an app author can work at an even higher level abstraction: for example, they should be able to use a camera or printer with the same API whether they're building for Windows, macOS, iOS or Android. Or they should be able to persist settings on any of these platforms without knowing about specific implementation details like the Windows registry. (But perhaps these are utility classes that the camera package author would use to build the Windows implementation.)

Or is the audience a Dart user who is writing a Windows-only app?

• One potential scenario is a Dart-like equivalent of the .NET Windows Forms library, where you're writing idiomatic Dart code that calls Win32 APIs under the covers. In this world, you should never need to worry about FFI or pointers: the library should handle all the mechanics under the surface.
• Another scenario is a thinner set of helper wrappers that don't attempt to provide a full abstraction layer over Win32, but just make writing common code easier. This is perhaps more akin to MFC, which is a thin veneer over the underlying API, providing class wrappers but not obscuring much of the underlying code.

How should this be shipped?

1. Some of these could be independent packages on pub.dev that depend on win32. That would make it easy to revise, version and federate them.
2. This could be a separate package that sits on top of win32, allowing it to be versioned and packaged together, but enabling it to stabilize at a different cadence to the underlying API code.
3. This could be fully integrated as part of win32, or perhaps offered as a second import (import 'package:win32/wrappers.dart';)

My own instinct is that there's a lot of fun to be had here, but there's also quite a lot of work. That's why I've deferred this myself! What would you like to do here? As one of the largest contributors to this package, I'm interested in your take on some of these questions above.

[ilopX]

I've also written a couple of packages that wrap Win32 APIs in more idiomatic Dart, for example:

I find it inconvenient to install a package for every little thing every time.

---

Who is the target audience?

I have not done marketing research and can only speak for myself. At the moment, all the available technologies for creating gui for windows are not suitable for me personally. Flutter + Dart is the only correct solution for me.

Platforms I explored:

• JetBrain Compose for Desktop (flutter for java world)
• Delphi (outdated development environment, no web)
• UWP or WPF (I hate xaml, no web)
• Qt + QML (c++ bad for these purposes, no web)
• Electron (html,css - hard to refactor)

Deprecated:

• MFC
• WinForms
• Swing or JavaFX

---

For Flutter at least, the ideal is that an app author can work at an even higher level abstraction: for example, they should be able to use a camera or printer with the same API whether they're building for Windows, macOS, iOS or Android.

In my opinion, you shouldn't think about cross-platform inside the win32 package. For me, it's better that the Flutter plugins and launcher for Windows can only be created in Dart without using C++, this speeds up the build, launch and development.

---

Or is the audience a Dart user who is writing a Windows-only app?

In my case, yes. Why not start learning flutter from Windows?

Flutter is the best future for development on windows platform.
Dart + Flutter + Android Studio (free IDEA) is the best tools

For example, I conceived a program for design (interfaces or diagrams) for windows with interactive screens on the web (Something like figma). We get skia speed on Windows and cross-platform on the web. I can even easily create a viewer for my phone. And all with one codebase. It's incredible! DartFlutter fits perfectly! But if I need to print to a printer, I will find myself near a large wall with c++ winApi.

The main purpose of win32::wrappers or win32::tools is to show developers that Flutter can be easily used for development on Windows. Now the situation is such that for elementary printing or a tray icon, you need to shovel a lot of docs.microsoft.com, know c++ and be able to translate into Dart. And if it affects COM, then here even I take a step back. This scares away developers, even more so for beginners. Everything they could do in C# in 1 minute can take them weeks.

Role of wrappers:

• Flutter will act to create the gui,
• Dart as the main language,
• win32 package for connecting to Windows platform,
• wrappers will reduce costs when using a specific Windows api
• tools will shorten build time and remove c++, msbuild and CMake dependencies (everything is a Dart 😎)

---

How should this be shipped?

I cannot say with a hundred percent certainty, but at the moment I am looking towards separate imports. And I agree that the management of individual packages will be easier. But wrappers are very closely related to winApi and when they are implemented, it will be necessary to modify win32, so it is better to make separate imports, and in the future it will be possible to put them in separate packages.

Am I understanding the future structure correctly? If so, then I will edit my pull request (#287). If you don't want to review 1300 lines of code, I understand that.

struct:

• bin
  • flutter_runner.dart
  • flutter_build.dart
  • flutter_create.dart
• lib
  • tool
    • flutter_runner
    • flutter_build
    • flutter_create
  • wrappers
    • window
    • reg_edit
    • tray
    • notification
    • mf_media
    • etc.
  • src
  • win32.dart
  • wrappers.dart

CMD example:
pub run win32:flutter_runner
pub run win32:flutter_runner --debug
pub run win32:flutter_build - creates an application from a single file or an installer built on flutter
pub run win32:flutter_create . - creates an application skeleton using a template for windows

---

What would you like to do here?

I want to implement several ideas for Windows programs.
So I'll have to implement some api. The most serious is the Media Foundation.

[timsneath]

I'm loving the idea and I'm so impressed at what you've accomplished so far. This is an immense contribution. I think there are several of us on the team who have dreamed about the runner being written purely in Dart, and your work suggests the practicality of this as a proposition.

I understand what you're saying about not wanting to have to install a cascade of packages for every random API. At the same time, people do search pub.dev for things like Bluetooth, serial port, settings. I think ultimately what you're saying is that the author of the Bluetooth package would be able to use the wrapper rather than the underlying Win32/FFI code to implement the Windows version. But I'm wondering if that's one layer of indirection too many. Is it better to contribute the code directly to the package?

In terms of including this in win32, there are two considerations that are on my mind:

• Firstly, the size of the package: win32 is a dependency of many other packages, so we have to be careful about it becoming large. That's why I split winmd into a separate package, so that the .winmd metadata doesn't get downloaded by a consumer of the win32 package. That might be valuable for flutter_runner also, since I see you include quite a few dependencies.

• Secondly, the wrapper API surface would need to be stable if it is to be included in win32 directly. Otherwise every change to a class like Hwnd would trigger a major version update to win32, which would be a significant inconvenience for those who are not using it.

For those two reasons, I'm wondering if the right thing is to keep flutter_runner and wrappers as two separate packages that together with win32 are a single 'package family'. That would give you the ability to continue to evolve them at a fast pace, keep each package tightly focused on a single function (for both marketing and clarity), and avoid version hell. It also puts you squarely in charge of their development and maintenance, which would be fantastic, since I think you're already outpacing me in these areas.

In this world, win32 stays tightly focused on providing the underlying primitives. But it would make sense for win32 to point to wrappers as the idiomatic, high-level way for Flutter and Dart to access Windows shell and hardware. For many scenarios, a Dart developer would then import wrappers rather than win32, with wrappers depending on win32 for its APIs.

By the way, at a later stage, I could imagine flutter_runner becoming a contribution to the core Flutter package, if it is able to achieve the same performance and characteristics of the C++ code that serves this purpose today.

What do you think of this approach? Again, thank you for your amazing contributions and partnership so far on this area. We're onto something here, I'm sure of it!

[ilopX]

I'm loving the idea and I'm so impressed at what you've accomplished so far. This is an immense contribution. I think there are several of us on the team who have dreamed about the runner being written purely in Dart, and your work suggests the practicality of this as a proposition.

It was fun coding.

---

In this world, win32 stays tightly focused on providing the underlying primitives.

You are right, win32 should provide basic primitives, and it will be much more beneficial for me if you're focusing on their implementation. I expect from win32 to provide com interfaces, including the media foundation.

---

For those two reasons, I'm wondering if the right thing is to keep flutter_runner and wrappers as two separate packages that together with win32 are a single 'package family'.

I'm thinking of using the flutter_runner function inside a Flutter app to provide window management and display individual dialogs. But I want to find a way to use gui wrappers without flutter. flutter_runner is not only a launch, but also a build manager and, according to my plan, a packer into one executable file. So I need to think about the third flutter_build tool.

Therefore, I will continue my experiment. When I reach a consensus, I will push it to a separate repository.

---

Thanks for correcting my path.
We have reached an understanding. 🤝

[ilopX]

I liked these commands, they fit to context.

pub run win32:flutter_runner
pub run win32:flutter_build

Now I need to think about a new naming because flutter_runner is out of the context of the win32 package. 😭