Build Win32 apps with Dart!

Would it be possible to create a sample of using project reunion with this and how to deploy it with a flutter app?

The reason why this is important is that without project reunion creating things like full featured video players with DRM, OpenIdConnect authentication windows and the like is incredibly difficult with C++ (you have to get down into the Media Foundation layer which is brutally complex as an example) or downright impossible because it isn't accessible from win32.

With this project and a project reunion sample, the sky's the limit and we can quickly backfill all of the existing functionality and reach parity with Android and iOS.

Thanks!

Thank you so much for sharing this repo :)

I would like to provide thermal printing using bluetooth for a Flutter desktop app used on windows. It seems this could be achieved using the win32 API calls mentioned :

• https://docs.microsoft.com/en-us/windows/win32/api/_bluetooth/

Once implemented, it could also lead to a dedicated bluetooth repo similar to your filepicker_windows.

One day I had a problem, wanting to use SAPI in my application via COM. Now I have two problems. It would be nice if there was an extension on IDispatch which had some functions that accepted a List or something as arguments and automatically converted them to COM types and called the specified method or set the specified property. I saw the example/idispatch.dart wrapper class, but that doesn't seem to compile anymore and calling a method is still pretty complicated.

Originally posted by @halildurmus in https://github.com/timsneath/win32/issues/431#issuecomment-1133899087

Assume that we're using the Mixin model for generating WinRT classes.

There are some cases where we can't deallocate pointers in the generated code. Therefore, it is the consumers' responsibility to deallocate them once they're done using them.

These are:

• WinRT class pointers e.g. Calendar's pointer (these pointers are allocated by constructors such as Calendar's default constructor, factory constructors, methods, properties, or by consumers using ActivateObject or other helper methods)
• WinRT mixin pointers e.g. pointers of the ICalendar and ITimeZoneOnCalendar
• APIs that return IVector<T extends IInspectable> or IVectorView<T extends IInspectable> e.g. IVector<StorageFile>. As of now, these are exposed as Pointer<COMObject>. We only auto-generate APIs that return IVector<String> and IVectorView<String> at the moment but we will add support for these in the future. Here is the one I manually generated.

...and probably much more in the future as the WinRT projection matures (asynchronous APIs, IMap & IMapView...).

The problem is that there are many situations where the consumers need to free pointers manually and I think it is pretty common to forget freeing some of the pointers (especially if you're using a lot of them). Another thing that is quite painful to deal with is that if you accidentally call free method twice on the same pointer, the process will crash and good luck figuring out the source of the problem (I got bitten by this many times :( ).

I've been trying to find a way to fix these issues for the past few days and I have some ideas I'd like to share with you.

I'll start with the first design. We could consider introducing a class that manages the pointers that could not be freed in the generated code:

class WinRTAllocator {
  static final allocator = Arena();

  /// Releases all resources managed by the [allocator].
  static void freeAll() => allocator.releaseAll(reuse: true);
}

This class would contain a static allocator to be used by the generated code and a static method to free all pointers. We would expose this to the outside world so that the consumers would have a way of freeing all pointers by calling just a single method once they're done using WinRT APIs.

Here are the cases where we need to modify the generator to use this allocator:

• WinRT class pointers
• WinRT mixin pointers (We would pass WinRTAllocator.allocator to toInterface method as a parameter)
• APIs that return IVector<T extends IInspectable> or IVectorView<T extends IInspectable>

...and much more in the future...

This design is much simpler to use, but if consumers use WinRT APIs heavily, I'm worried that the memory usage may be higher until they call WinRTAllocator.freeAll() (there may be some cases where the consumer is using tightly coupled APIs and because of this they can't call freeAll method between calls and must wait for all calls to complete).

To solve this, here is the final design I came up with. First, we could create our own Arena implementation by slightly modifying dart:ffi's implementation to allow freeing specific pointers from the _managedMemoryPointers list (by modifying Arena's free method):

class WinRTAllocator {
  static final allocator = _Arena();

  /// Releases memory allocated on the native heap.
  static void free(Pointer<NativeType> pointer) => allocator.free(pointer);

  /// Releases all resources managed by the [allocator].
  static void freeAll() => allocator.releaseAll(reuse: true);
}

class _Arena implements Allocator {
  /// The [Allocator] used for allocation and freeing.
  final Allocator _wrappedAllocator;

  /// Native memory under management by this [Arena].
  final List<Pointer<NativeType>> _managedMemoryPointers = [];

  /// Callbacks for releasing native resources under management by this [Arena].
  final List<void Function()> _managedResourceReleaseCallbacks = [];

  bool _inUse = true;

  /// Creates a arena of allocations.
  ///
  /// The [allocator] is used to do the actual allocation and freeing of
  /// memory. It defaults to using [calloc].
  _Arena([Allocator allocator = calloc]) : _wrappedAllocator = allocator;

  /// Allocates memory and includes it in the arena.
  ///
  /// Uses the allocator provided to the [Arena] constructor to do the
  /// allocation.
  ///
  /// Throws an [ArgumentError] if the number of bytes or alignment cannot be
  /// satisfied.
  @override
  Pointer<T> allocate<T extends NativeType>(int byteCount, {int? alignment}) {
    _ensureInUse();
    final p = _wrappedAllocator.allocate<T>(byteCount, alignment: alignment);
    _managedMemoryPointers.add(p);
    return p;
  }

  /// Registers [resource] in this arena.
  ///
  /// Executes [releaseCallback] on [releaseAll].
  ///
  /// Returns [resource] again, to allow for easily inserting
  /// `arena.using(resource, ...)` where the resource is allocated.
  T using<T>(T resource, void Function(T) releaseCallback) {
    _ensureInUse();
    releaseCallback = Zone.current.bindUnaryCallback(releaseCallback);
    _managedResourceReleaseCallbacks.add(() => releaseCallback(resource));
    return resource;
  }

  /// Registers [releaseResourceCallback] to be executed on [releaseAll].
  void onReleaseAll(void Function() releaseResourceCallback) {
    _managedResourceReleaseCallbacks.add(releaseResourceCallback);
  }

  /// Releases all resources that this [Arena] manages.
  ///
  /// If [reuse] is `true`, the arena can be used again after resources
  /// have been released. If not, the default, then the [allocate]
  /// and [using] methods must not be called after a call to `releaseAll`.
  ///
  /// If any of the callbacks throw, [releaseAll] is interrupted, and should
  /// be started again.
  void releaseAll({bool reuse = false}) {
    if (!reuse) {
      _inUse = false;
    }
    // The code below is deliberately wirtten to allow allocations to happen
    // during `releaseAll(reuse:true)`. The arena will still be guaranteed
    // empty when the `releaseAll` call returns.
    while (_managedResourceReleaseCallbacks.isNotEmpty) {
      _managedResourceReleaseCallbacks.removeLast()();
    }
    for (final p in _managedMemoryPointers) {
      _wrappedAllocator.free(p);
    }
    _managedMemoryPointers.clear();
  }

  /// Releases memory allocated on the native heap.
  @override
  void free(Pointer<NativeType> pointer) {
    final isRemoved = _managedMemoryPointers.remove(pointer);
    if (isRemoved) _wrappedAllocator.free(pointer);
  }

  void _ensureInUse() {
    if (!_inUse) {
      throw StateError(
          'Arena no longer in use, `releaseAll(reuse: false)` was called.');
    }
  }
}

(I'd like to point out that calling WinRTAllocator's free multiple times on the same pointer won't crash your process as the implementation checks if the pointer exists in the _managedMemoryPointers list before calling the native API.)

Then, we could create a dispose method in IInspectable:

class IInspectable extends IUnknown {
  ...

  /// Releases all memory allocated by this object.
  void dispose() => WinRTAllocator.free(ptr);
}

...and modify WinRT classes and mixins like this:

// icalendar.dart
mixin ICalendar on IInspectable {
  late final ptrICalendar =
      toInterface(IID_ICalendar, allocator: WinRTAllocator.allocator);
  // ...
}

// itimezoneoncalendar.dart
mixin ITimeZoneOnCalendar on IInspectable {
  late final ptrITimeZoneOnCalendar =
      toInterface(IID_ITimeZoneOnCalendar, allocator: WinRTAllocator.allocator);
  // ...
}

// calendar.dart
class Calendar extends IInspectable with ICalendar, ITimeZoneOnCalendar {
  Calendar() : super(ActivateWinRTClass(_className));
  Calendar.fromPointer(super.ptr);

  static const _className = 'Windows.Globalization.Calendar';

  // ...

  @override
  void dispose() {
    WinRTAllocator.free(ptr);
    WinRTAllocator.free(ptrICalendar);
    WinRTAllocator.free(ptrITimeZoneOnCalendar);
  }
}

With this design, consumers have the flexibility to use the dispose method of the WinRT classes in combination with the freeAll method of the WinRTAllocator for memory management. They can decide which option is more suitable for their needs or preferences. Some might prefer to just use freeAll for its simplicity while others may use both of them to make their applications more efficient.

I've searched around, tried some of the examples. Very cool stuff!

Is there a way to show a simple input dialog? I am looking for a small window that a user can type into and return the value for use. Something like:

int timerDuration = getInput();

and the user could type 5 so a 5 minute timer could be set.

I am interested in using wincred.h: https://docs.microsoft.com/en-us/windows/win32/api/wincred/nf-wincred-credwritea to port my plugin to windows.

Do you have any plans to add support for it - or how much work is it? I'm not completely sure how much magic is autogenerated and what has to be manually added :-)

Created this issue to continue our discussion at https://github.com/timsneath/win32/issues/423.

I love this. I wonder: as we're starting to it should be Calendar() rather than using the factory Calendar.create(). That feels more idiomatic.

I agree. In that case, we could generate activatable WinRT classes this way:

class Calendar extends IInspectable with ICalendar, ITimeZoneOnCalendar {
  Calendar() : super(ActivateWinRTClass('Windows.Globalization.Calendar'));

  Calendar.fromPointer(super.ptr);
}

That will cause a cascading breaking change for traditional COM interfaces though, and I'm not sure how to get around that. Perhaps they need to become factory constructors themselves, with IFileOpenDialog.cast(myComObject) or something. We should probably move this dialog into a separate design doc

Yeah, this will be difficult to do for COM interfaces.

In the meantime, I'm going to merge this, since it's obviously in the same vein as trustLevel and runtimeClassName. Maybe we'll hide these from the "outside world" later on. It looks like that's what C# does.

Hiding them might be a good idea. Looks like C#/WinRT only exposes GetRuntimeClassName method to consumers.

Hello there,

Would it be possible to provide wrappers to interfaces from shobjidl_core.h? I am particularly interested in IShellLinkA/IShellLinkW.

Thanks.

/root/.pub-cache/hosted/pub.dartlang.org/win32-1.7.1/lib/src/generated/IWbemServices.dart:495:15: Error: 'NativeFunction' isn't a type. Pointer<NativeFunction<_ExecMethod_Native>>.fromAddress( ^^^^^^^^^^^^^^ /root/.pub-cache/hosted/pub.dartlang.org/win32-1.7.1/lib/src/generated/IWbemServices.dart:495:7: Error: Method not found: 'Pointer.fromAddress'. Pointer<NativeFunction<_ExecMethod_Native>>.fromAddress( ^^^^^^^^^^^

Hi, I was wondering how simple it would be to implement the audio api from win32 https://docs.microsoft.com/en-us/windows/win32/coreaudio/about-the-windows-core-audio-apis It's quite large, but enables fully-featured audio and music players on windows

Currently, the only supported types are String and WinRT types such as IHostName.

I found the types that IVector and IVectorView support in here.

From the link above, the types that IVector and IVectorView support are WinRT types, primitive types like String, int, bool etc., and also some structs like GUID, Point, Size, DateTime, Uri etc.

I looked into the WinMD files using ILSpy and the majority of the APIs returns IVector<String> or IVector<T extends IInspectable>. This is also the case for IVectorView. That's why I didn't add support for the remaining types and some of them were structs like GUID, Point which I don't know how to project them. We can add support for them in the future.

While adding support for generic types, I had to find a way to create constructors from generic T types. In the beginning, I was storing the constructor tear-off mappings for T types inside a Map like this:

  static const map = <Type, IInspectable Function(Pointer<COMObject>)>{
    IHostName: IHostName.new,
    IStorageFile: IStorageFile.new,
    ...
  };

After learning the number of types that IVectorView supports -- which is more than 300, I abandoned this plan and added a creator parameter to constructors of IVector and IVectorView.

This parameter is only required for WinRT types like IVector<IHostName> and as I assume we will convert methods or properties that return Pointer<COMObject> to their respective types such as IVector or IVectorView(we're gonna expose this as a List, but first we're gonna turn this into an IVectorView in the generated code), the consumers won't have to deal with this which is great.

I'm looking forward to hearing your thoughts on this.

EDIT: I just figured out how to use IIterable and IIterator. I won't include them in this since this PR has grown quite a bit already.

Please add Bluetooth Classic support to the Dart win32 library. Enhance the bluetooth.dart example using SOCKADDR_BTH for the connection, send and recv. Also include support for ws2bth.h and Ws2_32.lib.

I want to call Windows.Media.Ocr in my flutter desktop application. Could I simply add this package to my project? And are there any demo codes from this function? Thank you.

support RasDialA ?

see https://docs.microsoft.com/zh-cn/windows/win32/api/ras/nf-ras-rasdiala?redirectedfrom=MSDN and https://stackoverflow.com/a/11616990

I'm trying to connect my MIDI device to a Flutter app running on Windows. I have the following:

final Pointer<HMIDIIN> hMidiDevice = malloc();

Pointer<NativeFunction<MidiInProc>> callbackPointer =
	Pointer.fromFunction(midiInCallback);

final result = midiInOpen(
  hMidiDevice,
  0,
  callbackPointer.address,
  0,
  CALLBACK_FUNCTION,
);
midiInStart(hMidiDevice.value);

midiInOpen takes a pointer to a function as 3rd argument. Here is my callback method:

static void midiInCallback(
	int hMidiIn,
	int wMsg,
	int dwInstance,
	int dwParam1,
	int dwParam2,
) {
	print('Message: $wMsg dwParam1: $dwParam1');
}

This compiles and works with a connected USB MIDI device. However, when I press a key on my MIDI device, then I get the following error:

../../third_party/dart/runtime/vm/runtime_entry.cc: 3657: error: Cannot invoke native callback outside an isolate.
pid=11004, thread=21860, isolate_group=(nil)(0000000000000000), isolate=(nil)(0000000000000000)
isolate_instructions=0, vm_instructions=7ffef50837c0
  pc 0x00007ffef51a3732 fp 0x00000057468ff990 angle::PlatformMethods::operator=+0x322d8a
-- End of DumpStackTrace

What am I doing wrong?

Hello,

I've gone through several examples and tried running a lot of them. It's quite difficult to understand how a lot of this interacts with flutter. Is there an example I could follow for SetWindowsHookEx for flutter? I have seen https://github.com/timsneath/win32/issues/509 and it doesn't really explain how it would work in flutter without creating a extra window!