Avisynth.H files for MinGW builds?

[Jeroi]

Since building C++ plugins is atm quite specified for M$ Visual Studio only or C version namely avisynth_c.H.

Source GIT: mingw avisynth.H files (https://github.com/mexgui/MeXgui/tree/master/mingw_avisynth)

Atm all versions are broken and in development status.

For those who wonders why?

It would be nice to make C++ plugins in Linux and Windows with MinGW compiler using avisynth.h c++ header.

Files:

mingw_avisynth2.H ->avisynth.H version 2
mingw_avisynth3.H ->avisynth.H version 3 for 2.5 plugins
mingw_avisynth5.H ->avisynth.H version 5 for 2.6 plugins
avisynthdll.H


Current state:

avisynth_c.dll works as replacement for Mingw c++ apps.
Mingw avisynth5 version is near supporting, atm mainly due the fact that stdcalls are used, waiting info if them can be replaced with cdecl functions.
v2 and v3 needs new code to go arround symbol calls to increment and decrement which at current state is M$ spesific code and same stdcall rant..

[Groucho2004]

Since developing C++ plugins is atm quite specified for M$ Visual Studio which is very "cheap" solution for us all
What?

It would be nice to make c++ plugins for avisynth with "expensive" software so that we can afford to do these C++ plugins.
What?


Atm the file misses COM handling code and some other bugs so developers may join to bring this one file into QT world.
From what I see this is an avisynth.h, 10 years old, AVISYNTH_INTERFACE_VERSION 2.
You replaced variable types globally, like "long" with "qint64" which funnily turned the word "along" in the comments into "aqint64". Also, the global replace turned "ULONG" into "Uqint64" which is a non-existent data type.

It seems that you have no idea what you are doing.

[Guest]

Also, we would prefer you to keep your stuff in your existing thread and not start extra threads.

[Jeroi]

What?

From what I see this is an avisynth.h, 10 years old, AVISYNTH_INTERFACE_VERSION 2.
You replaced variable types globally, like "long" with "qint64" which funnily turned the word "along" in the comments into "aqint64". Also, the global replace turned "ULONG" into "Uqint64" which is a non-existent data type.

It seems that you have no idea what you are doing.

I got my days funniest laughes. I did not take a look about comments tho. Yeah sometimes global replaces do funny stuff. Those fixed now.

[Jeroi]

I have added to the project now version3 and version5 avisynth.H files. It seams version 5 is quite easy to change supporting QT builds. It don't use object.h so no need to use QAtomicInt class at all. It seams we can survive only with QDataStream to provide necessary datatypes.

[Jeroi]

I found quite many bugs with orginal files. There were defined struct lists ending with "," which is not supported by normal C++ structure. Is this M$ code? Also one function declaration per file had this: "void function(nnn) {};" whis was another combiler bug where needed to remove ";" or move it to "{;}".

Anyways avisynth.H version 5 I think supports now QT so 2.6 version plugin support is for Windows QT development now. Still need to edit couble com object handlers in version 2 and 3. For AVX_support needed is to add linux spesifig calling methods because __stdcalls what I think is not supported by unix.

Have to take a look about avxsynth trunk.

[handaimaoh]

Will the plugins compiled with this header even work with Avisynth? If you want an alternate compiler, why would anyone use this over just writing a C++ plugin using avisynth_c.h which will be guaranteed to work with Avisynth?

Also, Visual Studio Express is free so it's not as if it's impossible for someone to get an MSVC++ compiler for free. Which means you don't have to deal with all the likely bugs and issues this randomly modified header will cause. Also, one can do Qt development in Visual Studio...

[Groucho2004]

why would anyone use this over just writing a C++ plugin using avisynth_c.h which will be guaranteed to work with Avisynth?
Not to mention the unspeakable bloat that QT introduces. QT is a huge pile of code and apparently everything gets linked in, no matter how little you need from it.

[handaimaoh]

Not to mention the unspeakable bloat that QT introduces. QT is a huge pile of code and apparently everything gets linked in, no matter how little you needs from it.

It's much more modularized these days so it's not as bad of an issue.

I would simply be more concerned with this even being ABI compatible with Avisynth.

[Guest]

Also one function declaration per file had this: "void function(nnn) {};" whis was another combiler bug where needed to remove ";" or move it to "{;}". The semicolon there is optional. It is certainly not a "combiler bug".

Class definitions however require the semicolon. Some people include it on functions for consistency.

[Groucho2004]

It's much more modularized these days so it's not as bad of an issue.
Maybe, dunno.
Anyway, the main question remains - what is this all about? Why does the OP want to "bring avisynth.h into the QT World"?

[handaimaoh]

Maybe, dunno.
Anyway, the main question remains - what is this all about? Why does the OP want to "bring avisynth.h into the QT World"?

Good question, since one doesn't need a questionably ABI-compatible header file when one can just use VS Express with Qt without it on Windows. And if one is doing Avxsynth development it also seems to make no sense since there is no need for it there either. And changing everything to Qt defines for integer types is also silly when one should just use the stdint.h types that have no ties to any framework.

[Jeroi]

Yeah I could do that also, it's not hard to use stdint.h but did add qt for somwhat using same time MeXgui source and changing there ints to qints prolly caused the idea to have separataley these for qt enviroment. How ever I could do those stdint.h versions if you guys like also.

That was good advice all to gether to change MeXgui codebase to have stdio.h for datatypes. Only qui components using QT.

[handaimaoh]

Yeah I could do that also, it's not hard to use stdint.h but did add qt for somwhat using same time MeXgui source and changing there ints to qints prolly caused the idea to have separataley these for qt enviroment. How ever I could do those stdint.h versions if you guys like also.

That was good advice all to gether to change MeXgui codebase to have stdio.h for datatypes. Only qui components using QT.

Such a header file should have the bare minimum of dependencies. Making a header that every plugin includes also require Qt is silly. Just use stdint.h.

[Jeroi]

Maybe, dunno.
Anyway, the main question remains - what is this all about? Why does the OP want to "bring avisynth.h into the QT World"?

The reason is not as all uses M$ operating system, and we would like to be able to write plugin that supports both worlds and same time maintain coder base that uses Windows or Linux or Mac OSX.

Such a header file should have the bare minimum of dependencies. Making a header that every plugin includes also require Qt is silly. Just use stdint.h.

Afaik version 2 and more notably version 3 need QT for winapi fuctions namely "InterlockedIncrement" and "InterlockedDecrement" where Qt offers QAtmonicInt class to handle similar functions.

[handaimaoh]

The reason is not as all uses M$ operating system, and we would like to be able to write plugin that supports both worlds and same time maintain coder base that uses Windows or Linux or Mac OSX.



Afaik version 2 and more notably version 3 need QT for winapi fuctions namely "InterlockedIncrement" and "InterlockedDecrement" where Qt offers QAtmonicInt class to handle similar functions.

But your header is likely ABI-incompatible with Avisynth especially if you are changing out functions. So it would defeat the point in using it if it's not ABI-compatible, no? Have you tested that your header can compile plugins that are ABI-compatible with Avisynth?

[Jeroi]

But your header is likely ABI-incompatible with Avisynth especially if you are changing out functions. So it would defeat the point in using it if it's not ABI-compatible, no? Have you tested that your header can compile plugins that are ABI-compatible with Avisynth?

Well I have chagned typically only datatypes and those bugs that are "optional" in M$ IDE so all functions should be ABI combatible when builded with MINGW in windows. That was the goal in first place to provide mingw build support. And since I was building Debuggin a mingw app the avisynth sources needed to be changed also. But since then I moved to devel on Linux because it's somewhat more stable system for coding open source apps but since the tool needs avisynth support in windows and avxsynth support in linux I needed to change avisynth.h to be compatible with mingw build.

But ok I will change the codebase for stdio.h and rename the thread header files for MinGW builds.

[handaimaoh]

Well I have chagned typically only datatypes and those bugs that are "optional" in M$ IDE so all functions should be ABI combatible when builded with MINGW in windows. That was the goal in first place to provide mingw build support. And since I was building Debuggin a mingw app the avisynth sources needed to be changed also. But since then I moved to devel on Linux because it's somewhat more stable system for coding open source apps but since the tool needs avisynth support in windows and avxsynth support in linux I needed to change avisynth.h to be compatible with mingw build.

You can't just willy-nilly change things in a header file and think it's going to stay ABI compatible. Again, have you actually tested that it's still ABI compatible with either Avisynth or Avxsynth? You may want to actually do that before continuing because if it's not ABI compatible your header is worthless. And that's before you even get into potential C++ incompatibilities between the MinGW/g++ and MSVC++ compilers (name mangling, structure alignment, exception handling, etc.).

[Jeroi]

You can't just willy-nilly change things in a header file and think it's going to stay ABI compatible. Again, have you actually tested that it's still ABI compatible with either Avisynth or Avxsynth? You may want to actually do that before continuing because if it's not ABI compatible your header is worthless. And that's before you even get into potential C++ incompatibilities between the MinGW/g++ and MSVC++ compilers (name mangling, structure alignment, exception handling, etc.).

Sir, you are welcomed to join the project, this is opensource. For testing I would need to switch to windows so helper could be handy here.

[handaimaoh]

Sir, you are welcomed to join the project, this is opensource. For testing I would need to switch to windows so helper could be handy here.

I don't need to test. I can say with nearly 100% certainty that for sure you are breaking ABI with Avisynth. I've never used Avxsynth so I have no clue about it, but it's doubtful you're ABI compatible with it either.

There's a reason that to use an alternate compiler to make Avisynth plugins that everyone had to use the avisynth_c.h header. If all it took was hacking up the normal avisynth.h header and using MinGW people would have already been doing so for years now.

[Jeroi]

I now edited files to include stdint.h. Someone could test if you can build your plugin with mingw with version 5 header for 2.6 plugins.

[handaimaoh]

So just for fun I pulled down one of your headers to compile a plugin. It's not even source compatible. There's no way it's ABI compatible.

[handaimaoh]

One of the biggest issues is that you've wrongly changed types such as BYTE which is an "unsigned char" to qint8 which is a signed char. This breaks things all over the place.

[Jeroi]

One of the biggest issues is that you've wrongly changed types such as BYTE which is an "unsigned char" to qint8 which is a signed char. This breaks things all over the place.

Thanks for that will change that asap and please download again, all the qt datatypes have been removed and added stdio.h datatypes instead.

I changed BYTE's to unsigned char fo now. Please test again.

[handaimaoh]

Thanks for that will change that asap.

That's great, but you're still source incompatible with plugins. Your header is worthless if it's not a drop-in replacement. With VS 2012, your header also has all sorts of compile issues on its own.

You've also changed things like IClip in ways that break ABI compatibility.

[Groucho2004]

I now edited files to include stdio.h.
Why? I can't think of anything from stdio.h that would be required for Avisynth.

[handaimaoh]

To illustrate just how you've completely broken ABI compatibility here is a comparison:

Original IClip:

// Base class for all filters.
class IClip {
friend class PClip;
friend class AVSValue;
int refcnt;
void AddRef() { InterlockedIncrement((long *)&refcnt); }
void Release() { InterlockedDecrement((long *)&refcnt); if (!refcnt) delete this; }
public:
IClip() : refcnt(0) {}

virtual int __stdcall GetVersion() { return AVISYNTH_INTERFACE_VERSION; }

virtual PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env) = 0;
virtual bool __stdcall GetParity(int n) = 0; // return field parity if field_based, else parity of first field in frame
virtual void __stdcall GetAudio(void* buf, __int64 start, __int64 count, IScriptEnvironment* env) = 0; // start and count are in samples
virtual void __stdcall SetCacheHints(int cachehints,int frame_range) = 0 ; // We do not pass cache requests upwards, only to the next filter.
virtual const VideoInfo& __stdcall GetVideoInfo() = 0;
virtual __stdcall ~IClip() {}
};

New IClip:

// Base class for all filters.
class IClip {
friend class PClip;
friend class AVSValue;
int refcnt;
QAtomicInt::QAtomicInt(refcnt);
void AddRef() { QAtomicInt::ref((qint64 *)&refcnt); }
void Release() { QAtomicInt::deref((qint64 *)&refcnt); if (!refcnt) delete this; }
public:
IClip() : refcnt(0) {}

virtual int __stdcall GetVersion() { return AVISYNTH_INTERFACE_VERSION; }

virtual PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env) = 0;
virtual bool __stdcall GetParity(int n) = 0; // return field parity if field_based, else parity of first field in frame
virtual void __stdcall GetAudio(void* buf, qint64 start, qint64 count, IScriptEnvironment* env) = 0; // start and count are in samples
virtual void __stdcall SetCacheHints(int cachehints,int frame_range) = 0 ; // We do not pass cache requests upwards, only to the next filter.
virtual const VideoInfo& __stdcall GetVideoInfo() = 0;
virtual __stdcall ~IClip() {}
};

You can't add things to an interface and change method signatures and expect ABI compatibility. So as I said before, this is absolutely worthless for anyone wanting to write Avisynth plugins compatible with either official Avisynth, Avisynth+ or Vapoursynth's Avisynth compatibility.

[Jeroi]

To illustrate just how you've completely broken ABI compatibility here is a comparison:

Original IClip:

// Base class for all filters.
class IClip {
friend class PClip;
friend class AVSValue;
int refcnt;
void AddRef() { InterlockedIncrement((long *)&refcnt); }
void Release() { InterlockedDecrement((long *)&refcnt); if (!refcnt) delete this; }
public:
IClip() : refcnt(0) {}

virtual int __stdcall GetVersion() { return AVISYNTH_INTERFACE_VERSION; }

virtual PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env) = 0;
virtual bool __stdcall GetParity(int n) = 0; // return field parity if field_based, else parity of first field in frame
virtual void __stdcall GetAudio(void* buf, __int64 start, __int64 count, IScriptEnvironment* env) = 0; // start and count are in samples
virtual void __stdcall SetCacheHints(int cachehints,int frame_range) = 0 ; // We do not pass cache requests upwards, only to the next filter.
virtual const VideoInfo& __stdcall GetVideoInfo() = 0;
virtual __stdcall ~IClip() {}
};

New IClip:

// Base class for all filters.
class IClip {
friend class PClip;
friend class AVSValue;
int refcnt;
QAtomicInt::QAtomicInt(refcnt);
void AddRef() { QAtomicInt::ref((qint64 *)&refcnt); }
void Release() { QAtomicInt::deref((qint64 *)&refcnt); if (!refcnt) delete this; }
public:
IClip() : refcnt(0) {}

virtual int __stdcall GetVersion() { return AVISYNTH_INTERFACE_VERSION; }

virtual PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env) = 0;
virtual bool __stdcall GetParity(int n) = 0; // return field parity if field_based, else parity of first field in frame
virtual void __stdcall GetAudio(void* buf, qint64 start, qint64 count, IScriptEnvironment* env) = 0; // start and count are in samples
virtual void __stdcall SetCacheHints(int cachehints,int frame_range) = 0 ; // We do not pass cache requests upwards, only to the next filter.
virtual const VideoInfo& __stdcall GetVideoInfo() = 0;
virtual __stdcall ~IClip() {}
};

You can't add things to an interface and change method signatures and expect ABI compatibility.

Yes version 2 and 3 are broken atm please use only version 5.

[handaimaoh]

Yes version 2 and 3 are broken atm please use only version 5.

They will always be broken unless you remove the Qt dependencies and revert IClip back to its original version.

[Jeroi]

They will always be broken unless you remove the Qt dependencies and revert IClip back to its original version.

They WILL be always broken if those aren't coded again since mingw don't support object.h which is m$ file.

[handaimaoh]

Yes version 2 and 3 are broken atm please use only version 5.

To add, you've changed the return types of a couple of methods in that version. That's not going to work either.

They WILL be always broken if those aren't coded again since mingw don't support object.h which is m$ file.

So then what is the point of your header if it is obviously going to break ABI?

[Jeroi]

Please consider your effort to Avisynth.H version 5. 2 and 3 are broken and in development atm so no shouting please I don't epect them to work atm. Again if you are going to rant about unfinished business please join the effort. Again the effort is to bring avisynth.h to mingw compile so things may still be broken.

[handaimaoh]

Your version 5 is broken too. As I said, you've changed the return type on method signatures in ways that are ABI incompatible.

[handaimaoh]

Again the effort is to bring avisynth.h to mingw compile so things may still be broken.

Which is meaningless if the plugins are not binary compatible. Which they won't be even if you do fix the header file.

[Jeroi]

Your version 5 is broken too. As I said, you've changed the return type on method signatures in ways that are ABI incompatible.

Combile errors please? I have changed only datatypes. No methotds other than __inline which is M$ code so please provide errors.

Ok I may know where is the error. I made in replace all quint8 into unsigned char. It may so that those function that needed unsigned integers changed also. I will check on that.

Oh found some QT integers still. Changed them now. Edit added also some uints that was somehow in search and replace changed to normal ints.

[handaimaoh]

Combile errors please?

Not a compile error. You've widened the return types from float to double which is going to break the ABI. ABI compatibility requires alignment and type size to not change.

[handaimaoh]

Ok I may know where is the error. I made in replace all quint8 into unsigned char. It may so that those function that needed unsigned integers changed also. I will check on that.

Oh found some QT integers still. Changed them now.

Which as I said, is only the start of your problems. You can not get around the ABI issue no matter what you do. Do you really think if merely changing some things in the header and recompiling with MinGW would have worked no one would have done so already? As I said before, the only way to get what you want is to either use avisynth_c.h or create your own C header. But it will have to be ABI compatible as well which you seem to have no notion of what that means or why it is important.

[Jeroi]

Which as I said, is only the start of your problems. You can not get around the ABI issue no matter what you do. Do you really think if merely changing some things in the header and recompiling with MinGW would have worked no one would have done so already? As I said before, the only way to get what you want is to either use avisynth_c.h or create your own C header. But it will have to be ABI compatible as well which you seem to have no notion of what that means or why it is important.

I have found some datatypes not replaced by search and replace for somehow. I will soon inform again. I am checking version 5 now from row to row with 2 monitors that datatypes should match.

Ok it seams I forgot to serch and replace qint32 so those are now int32_t. Can you please check now, all datatypes should work. It is funny that I did not type typedef unsigned char = BYTE so that I could have workaround for BYTE instead of replacing BYTE's.

Edit: HAH I had wrong include: STDIO I needed to have STDINT :D:D:D:D

[handaimaoh]

I have found some datatypes not replaced by search and replace for somehow. I will soon infrom again. I am checking version 5 now from row to row with 2 monitors that datatypes should match.

Specifically the issues are with your changes to:

float (AVSValue::*AsFloat)() const;

to

double (AVSValue::*AsFloat1)() const;

and

float (AVSValue::*AsFloat2)(float def) const;

to

double (AVSValue::*AsFloat2)(float def) const;

You cannot widen a type like that.

[handaimaoh]

Also other offending spots are:

float AsFloat() const AVS_BakedCode( return AVS_LinkCall(AsFloat)() )

to

double AsFloat() const AVS_BakedCode( return AVS_LinkCall(AsFloat1)() )

and

float AsFloat(float def) const AVS_BakedCode( return AVS_LinkCall(AsFloat2)(def) )

to

double AsFloat(float def) const AVS_BakedCode( return AVS_LinkCall(AsFloat2)(def) )

[Guest]

...those bugs that are "optional" in M$ IDE... The optional element that you mentioned (semicolon after }) is optional in C++ syntax. It is not a bug and it has nothing to do with MS IDE. You would be well advised to firm up your theoretical foundations before attempting difficult projects like this.

[handaimaoh]

The optional element that you mentioned (semicolon after }) is optional in C++ syntax. It is not a bug and it has nothing to do with MS IDE. You would be well advised to firm up your theoretical foundations before attempting difficult projects like this.

Specifically about how to maintain ABI compatibility and the ABI incompatibilities between the MinGW/g++ and MSVC++ compilers that his hacked up headers will never be able to fix.

[Guest]

For sure, but I thought you had that covered already. :p

[handaimaoh]

For sure, but I thought you had that covered already. :p

I would have thought so too, but he seems oblivious to my warnings that all his work is for naught...

[Jeroi]

I would have thought so too, but he seems oblivious to my warnings that all his work is for naught...

Have you checked the latest file? All datatypes should be now compatible and API supported all the way as I am changing only datatypes to support mingw, everything else should support mingw already by default or if mingw says something then there is something to fix. And this should support both M$ and Mingw compilers when this is done since we are reverting to native C++ code rather than writing M$ spesific code. There is nothing that should break API to support avisynth as any functions, any parameter have not changed. Only reverting from M$ to C++ native code. How ever one must find solution for version 2 and 3 for those object calls to native c++.

I wonder whats wrong with Creator debugger, it seemd not to find any problems even tho I had wrong include... :/

[Guest]

A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing.

George Bernard Shaw

[handaimaoh]

Have you checked the latest file? All datatypes should be now compatible and API supported all the way as I am changing only datatypes to support mingw, everything else should support mingw already by default or if mingw says something then there is something to fix. And this should support both M$ and Mingw compilers when thish is done since we are reverting to native C++ code rather than writing M$ spesific code. There is nothing that should break API to support avisynth as any functions, any parameter have not changed. Only reverting from M$ to C++ native code.

You didn't fix the functions I mentioned a couple of posts back. Widening data types like float -> double breaks ABI.

And for the umpteenth time, even if your headers do not break ABI themselves, the generated code will have all hosts of run-time issues due to compiler incompatibilities. You've essentially put out all this effort and yet the compiled plugins will not even work with Avisynth. The only way to get plugins compiled with MinGW to work with Avisynth is to use the avisynth_c.h header file which will not be subject to C++ name mangling and which will use C-linking in which both compilers are ABI compatible.

[Jeroi]

You didn't fix the functions I mentioned a couple of posts back. Widening data types like float -> double breaks ABI.

And for the umpteenth time, even if your headers do not break ABI themselves, the generated code will have all hosts of run-time issues due to compiler incompatibilities. You've essentially put out all this effort and yet the compiled plugins will not even work with Avisynth. The only way to get plugins compiled with MinGW to work with Avisynth is to use the avisynth_c.h header file which will not be subject to C++ name mangling and which will use C-linking in which both compilers are ABI compatible.

Could you tell what row? I havent touched any doubles or floats so this is new error.

The bigger issue is with version 2 and 3 since they use actual winapi object calls to to incrementing and decrementing and that should be done other way to support mingw.

I don't find these hard projects for me as I am Engineer Student and hobby project like these makes studies more better :)

[handaimaoh]

Could you tell what row? I havent touched any doubles or floats so this is new error.

Never mind. I was looking at an old version of the 2.6 header when those returns were still float. The other part of the post that you keep ignoring still stands.

G++ should support __stdcalls because it should be able to provide winapi support. Anything else is just datatypes and some M$ spesifig way to descripe funtionality that is changed the code should combile like the avisynth_c.H with mingw. Your rant about ABI compatible build is not relevant issue here, go somewhere else to rant about it, this is about to get mingw working header for avisynth c++ plugins and if the code needs to change so that it support avisynth ABI it shall be done, the rant is pointless here.


I'm not talking about supporting __stdcall. I'm referring to name mangling differences, exception handling differences, data alignment differences, etc. That is why the only way to write Avisynth plugins using MinGW and having them be ABI compatible is using the C interface. Hacking up the header file does not get around these ABI issues.

[Groucho2004]

Your rant about API compatible build is not relevant issue here, go somewhere else to rant about it, this is about to get mingw working header for avisynth c++ plugins and if the code needs to change so that it support avisunth API it shall be done, the rant is pointless here.
Nobody is ranting, you're simply ignoring handaimaoh's advice and now you're just being rude.