[vm/ffi] Expose dart_api.h and dart_native_api.h via dart:ffi?

[dcharkes]

We could expose some symbols from dart_native_api.h and dart_api.h via dart:ffi.

This would solve two problems:

• The symbols not being exported by various embedders dart:ffi - expose dart_api.h to FFI modules flutter/flutter#46887.
• Static linking issues on Windows [vm] Usage of dart_native_api.h requires linking dlls to either dart.exe or dart_precompiled_runtime.exe #40579.

This would change the usage of dart_api.h and dart_native_api.h to manual dynamic linking passing back function pointers.

Static linking (current situation)

#include "include/dart_api.h"
#include "include/dart_native_api.h"

void SomeCode(){
  const bool result = Dart_PostCObject(send_port, &dart_object);
}

Manual dynamic linking (proposal)

// For the typedefs, but don't use the function pointers.
#include "include/dart_api.h"
#include "include/dart_native_api.h"

typedef bool (*Dart_PostCObjectType)(Dart_Port port_id, Dart_CObject* message);
Dart_PostCObjectType Dart_PostCObject_;

DART_EXPORT void RegisterDart_PostCObject(
    Dart_PostCObjectType function_pointer) {
  Dart_PostCObject_ = function_pointer;
}

void someCode(Dart_Port send_port, Dart_CObject dart_object) {
  const bool result = Dart_PostCObject_(send_port, &dart_object);
}

// dart:ffi
external Pointer<NativeFunction<...>> nativeApiDart_PostCObjectAddess();

// user code
final registerDart_PostCObject = dl.lookupFunction<
        Void Function(Pointer<NativeFunction<...>> functionPointer),
        void Function(Pointer<NativeFunction<...>> functionPointer)>(
    'RegisterDart_PostCObject');

registerDart_PostCObject(nativeApiDart_PostCObjectAddess());

cc @mkustermann @mraleph @derolf

[derolf]

Exposing those into Dart is also an option I thought about.

I could then pass them down to my native library.

That way also the native-finalizer topic can be solved easily.

flutter/flutter#47061