[vlc-devel] [PATCH 0/2] Libvlc formatted log callback

[Jeremy Vignelles]

> Le 18 mai 2019 à 10:05, Rémi Denis-Courmont <remi at remlab.net> a écrit :
> 
> 
> Le perjantaina 17. toukokuuta 2019, 12.23.44 EEST Romain Vimont a écrit :
> > On Fri, May 17, 2019 at 10:04:59AM +0200, Jérémy VIGNELLES wrote:
> > > Hi,
> > > 
> > > In libvlc, there is currently a `libvlc_log_set` function, that can
> > > register log callback in a vprintf style, that is, with a `va_list`
> > > argument.
> > I agree that we should avoid va_list in callbacks :)
> > > This is nice when you are trying to call from C, but when using other
> > > languages like C# or Java, va_list is impossible to get right, and even
> > > if it did, those languages do not provide ways to format that kind of
> > > stuff.
> > (not counter-arguments, just comments)
> > 
> > I don't know C#, but in Java you will need a JNI layer in C, so it can
> > be handled here.
> 
> DotNet has a special syntax to bind native function call symbols as regular 
> DotNet methods.
> 
> But it is designed for Windows DLL and Win32/COM type system,

Probably true, it certainly began as a way to consume windows DLLs (hence the
historical name `DllImport`). It evolved a lot since then, with mono first,
which allows to load .so on linux, as documented there :
https://www.mono-project.com/docs/advanced/pinvoke/ . Now, Microsoft is
completely on cross-platform with .net core, and `DllImport` is supported and
cross-platform, even though it kept its name

> and basically fails to account for anything outside of that, such as
> signedness of char,

byte : https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/byte
sbyte : https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/sbyte

> width of long,

If by that, you mean "a width that depends on the CPU", then it is doable, but not easily. However,
(U)Int32/(U)Int64 are a thing.

> versioning of shared objects,

Don't really understand what you mean there. LibVLC API shouldn't change between
two major versions right?

> process-wide symbol namespace,
What is that?

> etc. So if you try to run the same code on Mono (or vice versa), it will fail 
> (been there, done that).

We don't have any code specific to mono, but we do have some code related to the
loading of the libvlc shared library, that is specific to the OS being used.
Things are getting even trickier when it comes to Android and iOS, but that's
another story.

> If you want to write really portable code, you don't typically use DotNet, I 
> believe.

As of 2019, .net core offer the ability to write truly cross-platform
applications. The only exception I see is that there are currently no truly
cross-platform GUI framework :

* WPF, WinForms, UWP on windows on .net framework
* GTK# with mono on Windows, Linux, Mac
* Android with Xamarin.Android (mono underneath)
* iOS with Xamarin.iOS (mono underneath)
* Mac with Xamarin.Mac (probably mono)
* Xamarin.Forms, that is arguably the most cross-platform framework that works on all those platforms as it generate one application per platform (but no "one build to rule them all")

LibVLCSharp is already supported on all those platforms, with 90% of the same code. The 10 remaining percent are UI toolkit specific code, getting window handles and passing them to LibVLC. 

> And if you do, there you probably have a native portability framework underneath.

The runtime itself acts as one. I guess that the goal in the future of .net is to have one .net assembly that you can truly drop on your target platform without rebuilding.

> -- 
> Реми Дёни-Курмон
> http://www.remlab.net/
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel