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.

[handaimaoh]

Nobody is ranting, you're simply ignoring handaimaoh's advice and now you're being simply rude.

And at this point I will simply give up. It's not worth trying to help him when he's clueless as to the issues that I'm bringing up. Have fun with your project that is doomed to fail.

[Jeroi]

Ok, I went to the windows and borrowed one 2.6 plugin source and made autotools project out of it and loaded that into Windows Qt creator. Debugged it shown to me that it was necessary to support backwards combatibility by definining windows types to the header, since plugin dev used BYTE and WORD and so on. I also defined windows type ints to the file. Without these additions plugin sources cannot be compiled. How ever in atleast Windows MinGW do support windows c++ headers so this might not be greatest issue of it. Have not taken look about the Linux MinGW libraries.

I have also edited the header a bit as debugger said conflicts with parent and extend classes and some M$ spesific forward declarations. It seems that I have now debugger free and compilable 2.6 header file for mingw but it is very experimental. I need to build dll first and test it with avisynth.

[Forensic]

While extremely comfortable with AviSynth, creating/understanding header files is currently beyond my skills. I would be extremely appreciative if, should a QT/MinGW32 Avisysnth 2.6 header be successfully created, that someone modify it to support AviSynth 2.5 so I can build DLLs in that legacy environment. I have several scripts that I want to gift to the AviSynth 2.5 community that are only useful under the awesome speed improvements of CPP compiling, and I prefer to work in QT/MinGW32 (their GUI/development tools and available video tutorials appear to dramatically reduce my CPP learning curve). If my request is not possible for technical reasons, please propose an alternate compiler here, in private message or in (http://forum.doom9.org/showthread.php?t=169704)

[Jeroi]

While extremely comfortable with AviSynth, creating/understanding header files is currently beyond my skills. I would be extremely appreciative if, should a QT/MinGW32 Avisysnth 2.6 header be successfully created, that someone modify it to support AviSynth 2.5 so I can build DLLs in that legacy environment. I have several scripts that I want to gift to the AviSynth 2.5 community that are only useful under the awesome speed improvements of CPP compiling, and I prefer to work in QT/MinGW32 (their GUI/development tools and available video tutorials appear to dramatically reduce my CPP learning curve). If my request is not possible for technical reasons, please propose an alternate compiler here, in private message or in (http://forum.doom9.org/showthread.php?t=169704)

The obivous answer to you question is to download VCexpress which is free from M$. They will say to you that plugins can only developed in M$ VS because the whole code is M$ spesifig. The main idea in this thread is to get avisynth.h header support for cross platform programs and some developer that may want to develop with other C++ tools avisynth plugins. Also I am including to this project soon the Avxsynth.h so that it can be modified to support windows source plugins to compile them to linux. Mainly replacing the orginal avisynth.h header and introducing avxsynt.h in replace and some modifications to orginal code and build for linux plugin.so.

I just watched avxsynth header, it seams even this project is build with VC++ because it is 2.5 v3 header and no modification to support other compilers. So I think my edited header will be suporting both avxsynth and avisynth both systems. Hah it was funny to watsch some sources ther :D, they have copied all windows defines from windows libs and added them to windows code support so that compiler can handle windows types and definitions. Similar what I am doing with my header to support windows native plugins to be able to build for linux :D.

[handaimaoh]

Yes, I said I would not respond anymore but I will one more time in the vain hope that you will listen.

The obivous answer to you question is to download VCexpress which is free from M$. They will say to you that plugins can only developed in M$ VS because the whole code is M$ spesifig.

No, the reason you need MSVC++ is because unless you use the C interface you're plugins will not be binary compatible with any Avisynth version in existence. If it was possible to simply modify the header to support building using the C++ interface with MinGW that would actually work with Aviysnth, IT WOULD HAVE ALREADY BEEN DONE. You have not come up with anything either novel or clever. You've simply created something that will never work with any version of Avisynth that any user will be using. This is not some conspiracy to get people to only use the "M$" (a moniker that is highly lame by this point) compiler but simply is due to the realities of C++ compiler ABI incompatibilities in Avisynth's legacy.

[Jeroi]

Yes, I said I would not respond anymore but I will one more time in the vain hope that you will listen.



No, the reason you need MSVC++ is because unless you use the C interface you're plugins will not be binary compatible with any Avisynth version in existence. If it was possible to simply modify the header to support building using the C++ interface with MinGW that would actually work with Aviysnth, IT WOULD HAVE ALREADY BEEN DONE. You have not come up with anything either novel or clever. You've simply created something that will never work with any version of Avisynth that any user will be using. This is not some conspiracy to get people to only use the "M$" (a moniker that is highly lame by this point) compiler but simply is due to the realities of C++ compiler ABI incompatibilities in Avisynth's legacy.

How come avxsynth can exist then if g++ cannot build abi supported code? I have done code that can give same output to Avisynth that M$ build. It is all about valid code, it does not have to be c++, it can be java, python what ever as long as it outputs correct variables and function definitations. Also there is dtk version of mingw these days that should provide better windows support, so you are wrong. What I can tell is that originally avisynth was coded with M$ code and devs told to people that it is not possible to build with mingw because the code do not work in that environment. That's why it have to redefined with development to support abi with another compiler and this is why C version exists. One guy decided to do another port of the header.

Actually one could use avisynth_c.dll and code c++ there and compile it with g++ to make dll since GCC can do preprosessing the C stuff and use G++ for c++ code.

And I strongly wait avisynth developers to bring them selves header for opensource crossplatform programs to work with if Avisynth will never ever even become native cross platform frame server.

[JEEB]

How come avxsynth can exist then if g++ cannot build abi supported code?
First of all, the existence of avxsynth has nothing to do with the fact that the C++ specification does not specify an ABI and it is thus completely left to the implementation.

What you really seem to be asking is why something like avxsynth can exist and kind of work (to the level that avxsynth works), including (I have not tried myself but I would guess) C++ API plugins? The reason is simple. On a Linux system you generally have a single ABI, namely the GCC ABI. You don't generally install multiple compilers that have a different ABI on such a system, and most non-GCC vendors try to be at least somewhat compatible with GCC's ABI. For example, Clang does not have 100% ABI compatibility with GCC, but it generally tends to "kind of work" (answer (http://stackoverflow.com/a/11683966/1620828) related to this from circa 2011). I would guess the Linux version of the Intel C++ compiler also supports it in general (related PDF (http://software.intel.com/sites/products/collateral/hpc/compilers/intel_linux_compiler_compatibility_with_gnu_compilers.pdf)).

Now let's go back to Windows. Microsoft set their general C++ ABI with their first C++ compilers, and it has had some changes along the years and versions of their compiler suite. Intel and Borland, among others, support the Microsoft ABI, and thus things built with the other generally work, just like with Linux and the ABI used by GCC. Enter mingw.

Instead of implementing the Microsoft ABI, the people at GCC and mingw decided to just use the same C++ ABI on Windows as they use everywhere else. And thus we have two groups of compilers that use a different ABI, and thus we have problems. If you try to load a mingw-built C++ API DLL from a MSVC-built Avisynth it will not work (related post (http://stackoverflow.com/a/7119896/1620828)). The opposite will not work, either. The C interface was made exactly for this reason, as pretty much by chance the ABI for C is (more or less) set, and thus it is generally OK to mix binaries created by different C compilers.

Do note that the Microsoft and GCC-used C++ ABIs are not the only ones, and that there are other problems surrounding ABIs, including and not limited to exception handling. And this can differ even within GCC binaries thanks to the fact that GCC has multiple ways of doing exception handling, which is configured when the compiler is built.

If you want extra reading regarding calling conventions and name mangling and such ABI-related things, I just seem to have found a PDF that lists quite a few things of various implementations. Available here (http://www.agner.org/optimize/calling_conventions.pdf). Basically these things in general are not fixable by a mere header, you would have to patch a compiler for the other calling convention, as well as handle exceptions so that the other side would understand it as well. And so forth, and so forth.

[handaimaoh]

How come avxsynth can exist then if g++ cannot build abi supported code?

This is a non-sequitur. The existence of Avxsynth has nothing to do with C++ ABI issues between MSVC++ and MinGW/g++.

I have done code that can give same output to Avisynth that M$ build.

Bull. MinGW does not give the same output that MSVC++ does when compiling C++.

It is all about valid code, it does not have to be c++, it can be java, python what ever as long as it outputs correct variables and function definitations.

Sure if you ignore C++ name mangling differences, exception handling differences, structure alignment differences, etc. These are all limitations acknowledged by the MinGW developers.

Also there is dtk version of mingw these days that should provide better windows support, so you are wrong.

No, I'm not. What you are referring to merely misses the point.

What I can tell is that originally avisynth was coded with M$ code and devs told to people that it is not possible to build with mingw because the code do not work in that environment.

*facepalm* The issue is not with compiling the code. The issue has to do with the ABI of the compiled code. Again, if merely changing the header was the issue, IT WOULD HAVE BEEN DONE SO ALREADY. It is an extreme case of hubris if you really think you're smarter than all the other people who have been working on Avisynth for years.

That's why it have to redefined with development to support abi with another compiler and this is why C version exists. One guy decided to do another port of the header.

MinGW doesn't support the MSVC++ ABI. Redefining a few things in the header does not do what you think it does.

Actually one could use avisynth_c.dll and code c++ there and compile it with g++ to make dll since GCC can do preprosessing the C stuff and use G++ for c++ code.

Sure, if avisynth_c.dll uses the C ABI which is compatible between MinGW and MSVC++. You again, confuse the issues.

And I strongly wait avisynth developers to bring them selves header for opensource crossplatform programs to work with if Avisynth will never ever even become native cross platform frame server.

They will never do so because your headers will break ABI compatibility with every version of Avisynth out there. It would be insanity to do that.

[Groucho2004]

I have several scripts that I want to gift to the AviSynth 2.5 community that are only useful under the awesome speed improvements of CPP compiling
You'll have to elaborate a bit, that statement makes no sense to me.

[Jeroi]

And here is again proof that I may be right:

http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs

The thing is again that it would nice if Aivisynth finally could adopt GCC supported C++ code in the header.

[handaimaoh]

http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs

That doesn't prove what you think it does.

http://www.mingw.org/wiki/MixingCompilers

Even though GNU g++ can link MSVC C++ libraries now, and can produce MSVC++ compatible libraries/DLLs, this does not mean that they will be able to work at run-time due to the dynamic nature of C++. Some possible reasons for this are:--

The simple name mangling issue which it may be possible to circumvent with an explicit .def file.
Different structure alignment issues which need the correct compiler options (-mms-bitfields, ...).
A fundamental conflict of underlying exception and memory models:--
A new/delete or malloc/free in a MSVC DLL will not co-operate with a Cygwin newlib new/delete or malloc/free. One cannot free space which was allocated in a function using a different new/malloc at all.
An exception raised by an MSVC DLL will not be caught by a Cygwin executable, and vice versa.
The slow GNU SJLJ exception model, (used in GCC-3.x and earlier), is compatible with the MSVC++ model, but the new DWARF2 model, (which will be used by GCC-4.x), will be incompatible.

[Jeroi]

While extremely comfortable with AviSynth, creating/understanding header files is currently beyond my skills. I would be extremely appreciative if, should a QT/MinGW32 Avisysnth 2.6 header be successfully created, that someone modify it to support AviSynth 2.5 so I can build DLLs in that legacy environment. I have several scripts that I want to gift to the AviSynth 2.5 community that are only useful under the awesome speed improvements of CPP compiling, and I prefer to work in QT/MinGW32 (their GUI/development tools and available video tutorials appear to dramatically reduce my CPP learning curve). If my request is not possible for technical reasons, please propose an alternate compiler here, in private message or in (http://forum.doom9.org/showthread.php?t=169704)

Rememeber to go to the help->tools and enable autotools support. You can debug all the opensource and build them as you like with autotools project files "makefile.am".

[handaimaoh]

The thing is again that it would nice if Aivisynth finally could adopt GCC supported C++ code in the header.

Then go into the Avisynth forum and tell IanB this idea. Considering it will break ABI and all backwards compatibility, I can assure you the likelihood is probably around zero.

[handaimaoh]

Here (http://forum.doom9.org/showthread.php?t=168764&page=2) is the thread you should use to request what you want, Jeroi.

Moderator note: The posts that this spawned in IanB's alpha thread have been moved back to this thread. Please continue in this thread. IanB is aware of this thread. Thank you.

[Jeroi]

IanB I have a very honorable, overly talked thingy in my development project, feature question and a really big need for cross platform tools to have native c++ header file and methods to talk with avisynth with these kind of tools http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs. Since cross tools are usually build in MinGW/Linux environments Avisynth could support native C++ language and G++ supporting header file.

I would like to have native header for my MeXgui project to support linking the file with the rest of the code to have windows version that will use avisynth and linux it uses Avxsynth or Avisynth+. Orginaln Megui did not had this issue because it was build from VS but this time project focuse cross platfrom qt application which don't rely on Mincrosoft spesisifc code.

[TurboPascal7]

Jeroi
This is a very interesting idea indeed. Could you please provide a binary of a more or less complex avisynth plugin, built with g++, that would work with existing avisynth builds on windows?

Of course it should use the C++ interface as you propose.

[Forensic]

For legacy compatibility with AviSynth 2.58, all my computers are Windows-7 32-bit. Anxious to just use what is known to work so I can start writing AVIsynth compatible DLLs today, and later create a GUI rich video enhancement program, I have just downloaded:
Qt 5.1.1 for Windows 32-bit (VS 2012, 511 MB) {http://qt-project.org/downloads}
Microsoft Visual Studio Express 2012 for Windows Desktop {http://www.microsoft.com/en-us/download/confirmation.aspx?id=34673}
If I am understanding this correctly, these tools should play nicely with the avisynth.h (2.5 v3) {http://avisynth.nl/images/Avisynth.h-2.5.8.avs}. If so, bye bye minGW32 and hello plug-in creation. Does the above make sense? Thank you in advance.

[handaimaoh]

For legacy compatibility with AviSynth 2.58, all my computers are Windows-7 32-bit. Anxious to just use what is known to work so I can start writing AVIsynth compatible DLLs today, and later create a GUI rich video enhancement program, I have just downloaded:
Qt 5.1.1 for Windows 32-bit (VS 2012, 511 MB) {http://qt-project.org/downloads}
Microsoft Visual Studio Express 2012 for Windows Desktop {http://www.microsoft.com/en-us/download/confirmation.aspx?id=34673}
If I am understanding this correctly, these tools should play nicely with the avisynth.h (2.5 v3) {http://avisynth.nl/images/Avisynth.h-2.5.8.avs}. If so, bye bye minGW32 and hello plug-in creation. Does the above make sense? Thank you in advance.

The only way to get something that will work with the versions of Avisynth that are out there is to use MSVC++. Which you can get with Visual Studio Express. His headers will not work no matter what Jeroi believes.

[Groucho2004]

Could you please provide a binary of a more or less complex avisynth plugin, built with g++, that would work with existing avisynth builds on windows?

Of course it should use the C++ interface as you propose.
You're so cruel. ;)

[handaimaoh]

BTW Jeroi, how exactly did you compile a plugin with your MinGW headers when you have typos in the code? In your "avisynth26.h" you have a typo on the ApplyMessage method of IScriptEnvironment where you have "_stdcall" instead of "__stdcall". Even excluding that, I've yet to find a single version of your headers that even compile with my MinGW that uses GCC 4.8.1.

[Guest]

...
If you want extra reading regarding calling conventions and name mangling and such ABI-related things, I just seem to have found a PDF that lists quite a few things of various implementations. Available here (http://www.agner.org/optimize/calling_conventions.pdf). Basically these things in general are not fixable by a mere header, you would have to patch a compiler for the other calling convention, as well as handle exceptions so that the other side would understand it as well. And so forth, and so forth. Thanks for that valuable post with excellent links, JEEB!
:thanks:

[handaimaoh]

Jeroi
This is a very interesting idea indeed. Could you please provide a binary of a more or less complex avisynth plugin, built with g++, that would work with existing avisynth builds on windows?

Of course it should use the C++ interface as you propose.

He can't. For one thing his MinGW headers don't seem to be able to compile with MinGW in all the tests I've tried. Furthermore, even if many of the errors I'm seeing is merely an issue on my side his header for Avisynth 2.6 has a typo of "_stdcall" instead of "__stdcall" on the ApplyMessage method of IScriptEnvironment which would prevent compilation success.

[handaimaoh]

Thanks for that valuable post with excellent links, JEEB!
:thanks:

Yes out of everything in this thread it was quite an awesome PDF. Agner Fog's docs are awesome!

[Guest]

He can't. I'm pretty sure that's why TurboPascal7 posed the question. ;)

[Jeroi]

IanB I have a very honorable, overly talked thingy in my development project, feature question and a really big need for cross platform tools to have native c++ header file and methods to talk with avisynth with these kind of tools http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs. Since cross tools are usually build in MinGW/Linux environments Avisynth could support native C++ language and G++ supporting header file.

To add to my question would it be possible to define all the __sdtcalls with __declspec(dllexport/import) to allow more better MINGW support? __stdcalls seem to have problems with namemangling but __declspec seem to be standart c++ that mingw should handle with similar to MSVC.

[TurboPascal7]

Wow, the guy sees only what he wants to see?
Don't just go and ignore my question, Jeroi.

[Jeroi]

Wow, the guy sees only what he wants to see?
Don't just go and ignore my question, Jeroi.

I can build but need to change those sdtcalls to declaspec and since avisynth uses stdcalls the dll might not work because stdcall is in MSVC def file _function$plaah where in mingw it is function$plaah.

How to go arround this problem is produce the windows dll with a bit harder method with DEF file to make DLL support dll's that use __declspec(export).

See: http://wyw.dcweb.cn/stdcall.htm

If dll plugin header uses stdcall it pretty much kills mingw support.

The header could be written like this:

#ifdef PLUGIN
#define EXPORT __declspec(export)
#end
#define EXPORT __declspec(inport)
#endif

Then replacing all calls in the avisynth header with:

EXPORT int __cdecl Add(int a, int b)

Since __cdecl is handled similar with MSVS and MINGW this would provide intial support for plugins builded from mingw.

The downsode of this change is plugin sources need to recombile with new header while but whats is more greater is to add support mingw builds.

All this would change the current issue of plugins buildable only at Visual Studio and since plugins cuild be build in mingw natively wihtout def files it would provide Cross Platfrom softwares avisynth support natively in Windows.

[handaimaoh]

Well, yes, that is part of what I was trying to beat into your head. The only way for what you want to work is to use avisynth_c.h. Any other option breaks ABI and thus all backwards compatibility. And at that point, what's the point of using Avisynth if all your plugins are no longer compatible? You might as well just move to something like Vapoursynth.

[handaimaoh]

This would provide intial support for plugins and then in windows avisynth.dll should be build with DEF file so that decorations are off from Avisynth.dll.

Now only downside for this change is that all plugins need to be build against this new header file to support it.

All this would change the current issue of plugins buildable only at Visual Studio and since plugins cuild be build in mingw natively wihtout def files it would provide Cross Platfrom softwares avisynth support natively in Windows.


You do realize that's a huge downside right? And why would anyone use your headers and rebuild their plugins such that they would be incompatible with every version of Avisynth in existence?

Edited to add:
BTW Jeroi, you do realize that both Avisynth and most Avisynth plugins contain inline x86 asm that is incompatible with g++, right? One cannot simply recompile either Avisynth or the vast majority of plugins without major rewrites and ports even with your modified header. I'm not even sure if at this point Avisynth+ can be compiled with MinGW (I could be wrong though). No one is going to put in the effort to do all that work merely to be able to use the Avisynth C++ interface in MinGW.

[Jeroi]

Edited to add:
BTW Jeroi, you do realize that both Avisynth and most Avisynth plugins contain inline x86 asm that is incompatible with g++, right? One cannot simply recompile either Avisynth or the vast majority of plugins without major rewrites and ports even with your modified header. I'm not even sure if at this point Avisynth+ can be compiled with MinGW (I could be wrong though). No one is going to put in the effort to do all that work merely to be able to use the Avisynth C++ interface in MinGW.

You can still build everything in MSVS. But you can develop new plugins in mingw and use the header with mingw build apps.

The downside is that current plugins need to be build again with new header in MSVS to support new header version.



I'm not even sure if at this point Avisynth+ can be compiled with MinGW (I could be wrong though). No one is going to put in the effort to do all that work merely to be able to use the Avisynth C++ interface in MinGW.

No it cannot, one of the main issues is the avisynth header and since Avisynth+ has not announced linux support yet. In achieving this task the header file _MUST_ be changed. It is the most important issue with current Avisynth.

[handaimaoh]

The header could be written like this:

#ifdef PLUGIN
#define EXPORT __declspec(export)
#end
#define EXPORT __declspec(inport)
#endif

Then replacing all calls in the avisynth header with:

EXPORT int __cdecl Add(int a, int b)

Since __cdecl is handled similar with MSVS and MINGW this would provide intial support for plugins builded from mingw.

So then why not merely use the avisynth_c.h which uses __cdecl so that you can use MinGW to create plugins? It seems now you are simply creating a buggier version of the already existing Avisynth C interface.

You can see it here (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/core/avisynth_c.h?revision=1.8&view=markup).

You can still build everything in MSVS. But you can develop new plugins in mingw and use the header with mingw build apps.

The downside is that current plugins need to be build again with new header in MSVS to support new header version.

And I am aware that this breaks 2.5 support and so on but what is greater is support Cross compilable programs and avisynth plugins.

Since for most thing to other programs is just to use new header file for next build of the program, so every programs could adopt new version of header in sooner or later. In mean time they use 2.5 combatible plugins.

Or one can simply just use the already existing Avisynth C interface that won't break backwards compatibility with 2.5 compatible plugins? Your interface offers nothing of benefit over the existing C interface and on the other hand requires recompiling plugins and breaking compatibility. You've created essentially nothing of value over what already exists.

No it cannot, one of the main issues is the avisynth header and since Avisynth+ has not announced linux support yet. In achieving this task the header file _MUST_ be changed. It is the most important issue with current Avisynth.

Adding Linux support would not mean breaking existing ABI with all current Windows plugins as your header does foolishly.

[Jeroi]

Or one can simply just use the already existing Avisynth C interface that won't break backwards compatibility with 2.5 compatible plugins? Your interface offers nothing of benefit over the existing C interface and on the other hand requires recompiling plugins and breaking compatibility. You've created essentially nothing of value over what already exists.



Adding Linux support would not mean breaking existing ABI with all current Windows plugins as your header does foolishly.

Yes will use that for my current project, but it would be nice to see the header to switch using more standart c++ language to provide support mingw building.

[handaimaoh]

Yes will use that for my current project, but it would be nice to see the header to switch using more standart c++ language to provide support mingw building.

It does support MinGW building. That was the whole reason the C interface was created. This is what I told you 2 days ago.

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.

You then brushed me off. And now you've simply been talking about poorly re-implementing it.

[Guest]

Posts have been moved from IanB's thread to this one.

@Jeroi

Please confine your discussion to this thread. Thank you.

[Jeroi]

It does support MinGW building. That was the whole reason the C interface was created. This is what I told you 2 days ago.



You then brushed me off. And now you've simply been talking about poorly re-implementing it.

Yes you have been right with the C header all a long, but originally the thread is for development of C++ header which at current state is way too M$ code to support mingw build, and the fact it uses stdcall instead of cdecl is one of the reason why it does not work with mingw. If you call that brushing you off, then you are right. I my point of view, you are in past, I look for future.

And yes, atm they are broken and in development, you can download the code see the bugs and re edit them. This is opensource.

[Guest]

So you are saying just a few bugs stop the header file from giving us cross-platform operability using the C++ interface? If you really believe that, can you please explain how the header file (when 'fixed') can solve the problems of ABI incompatibility?

[Jeroi]

So you are saying just a few bugs stop the header file from giving us cross-platform operability using the C++ interface? If you really believe that, can you please explain how the header file (when 'fixed') can solve the problems of ABI incompatibility?

Well there will not be ABI incompatibility when cdcl is used like C plugin does it. This is because gcc and g++ can handle cdcl and combile dll that has "fucntion@m" like MSVC has "function@m" so both compilers can produce equal dll. If u use stdcall You will produce with mingw "function@m" and MSVC will output functions as "_fucntion@m". This breaks mingw DLL functions work because Avisynth.dll waits "_function@m" input. For similar reason current avicynth C plugin autoloading does not work and atm Avisynth+ can handle C plugin input just fine, that is compiled with mingw. The main problem is that if we change avisynth.H into avisynth.dll it then need to provide backwards support via stdcalls. This means that we would need to produce 2 versions, one for mingw build and one avisynth.h that support both function styles input at Windows. Lets say that WIN only version should be reanmed to avisynth_win.H and crossplatfrom supported version without stdcalls should use avisynth.h This provides mingw to be able to build functions with cdcl and be able to run the DLL's in Avisynth windows.

The main reason for all this is to enable native cross platfrom build support for avisynth. How ever it have said that C file does exist already and you can use it to provide avisynth support. My main consider is that does avisynth_c.h be autoload version in Windows? I mean when program X, wants to import avs file in Windows, and the program has avisynth_c.h included in bin, is it able to load those functions calls automatically with avisynth with it?

Let's say that program wants to import Audio and video data, it writes functions that use cdcl to to fetch from avisynth dll the video and audio, can avisynth then respond automatically to cdcl calls?

[Guest]

I will interpret what you say as acknowledging that the problem cannot be solved with a header file and that your project cannot meet its goals. It's important to get this in the open so other people do not needlessly waste their time trying to achieve something that is known to be impossible.

[handaimaoh]

Yes you have been right with the C header all a long, but originally the thread is for development of C++ header which at current state is way too M$ code to support mingw build, and the fact it uses stdcall instead of cdecl is one of the reason why it does not work with mingw. If you call that brushing you off, then you are right. I my point of view, you are in past, I look for future.

And yes, atm they are broken and in development, you can download the code see the bugs and re edit them. This is opensource.

I know I've been right. It's good to see you finally realize that. Also, I'm not looking into the past at all. If you want to be able to use C++ interface classes like in the regular Avisynth.h simply create such a C++ wrapper that calls into the C header functions behind the scenes. The major benefit is that doesn't require ABI breakage thus making such plugins incompatible with every Avisynth install in existence.

Well there will not be ABI incompatibility when cdcl is used like C plugin does it.

Changing the calling convention breaks ABI... As to the rest of your post, I know very well what the differences between cdecl and stdcall are so I don't need your lesson. And it is much more involved than what you mention. cdecl and stdcall are also different in whether it's the callee or caller who cleans up the arguments from the stack. You will probably run into issues with inline asm functions due to this (although your bigger issue is simply the incompatibility between MSVC and g++ inline asm).

[Jeroi]

You will probably run into issues with inline asm functions due to this (although your bigger issue is simply the incompatibility between MSVC and g++ inline asm).

No that is not a great issue. You can still build plugins with MSVC and use inline assembly. But you will lose unix support if your plugin uses inline assembly. Use native asm assembly would generate unix support for the plugin. This would be in future must anyway to support unix usage of the plugin.

But the main issue is current header limitation which is too win spesific with those stdcalls. If these are changed to cdecl it means only recombile the plugin which has inline assembly. This is not a big issue for plugin devs. The inline to asm is more bigger one for them.

The most backward support would provide 2 headers, one that stays native win but has no future support and the new cdecl header that implements c++ native functions and provides native c++ build support for every plugin/guiprogram that has full support.

In future when programs are moving to use cdecl calls the stdcall header could be removed as the time goes by.

Development sometimes need drastic movements and towards cross platfrom support to stay touch with the time.

[handaimaoh]

But the main issue is current header limitation which is too win spesific with those stdcalls. If these are changed to cdecl it means only recombile the plugin which has inline assembly. This is not a big issue for plugin devs. The inline to asm is more bigger one for them.

Wrong. You can not change the C++ header from stdcall to cdecl and expect the plugins to work. Best case the plugins will crash and at worse you will have all sorts of bugs at runtime. There is more to the difference between cdecl and stdcall than you seem to realize.


The most backward support would provide 2 headers, one that stays native win but has no future support and the new cdecl header that implements c++ native functions and provides native c++ build support for every plugin/guiprogram that has full support.

Except that simply using cdecl doesn't solve the C++ ABI issue between MSVC and MinGW/g++. Things such as exception handling, data alignment, etc are likely to cause runtime issues. You're missing the forest for the trees.


In future when programs are moving to use cdecl calls the stdcall header could be removed as the time goes by.

Development sometimes need drastic movements and towards cross platfrom support to stay touch with the time.

Except that going cross platform in no way requires obliterating ABI compatibility for Windows. Vapoursynth is cross-platform and is ABI compatible with Avisynth plugins on Windows.

[Jeroi]

Wrong. You can not change the C++ header from stdcall to cdecl and expect the plugins to work. Best case the plugins will crash and at worse you will have all sorts of bugs at runtime. There is more to the differences between cdecl and stdcall than you seem to realize.



Except that simply using cdecl doesn't solve the C++ ABI issue between MSVC and MinGW/g++. Things such as exception handling, data alignment, etc are likely to cause runtime issues. You're missing the forest for the trees.



Except that going cross platform in no way requires obliterating ABI compatibility for Windows. Vapoursynth is cross-platform and is ABI compatible with Avisynth plugins on Windows.

The runtime issues are for avisynth devs, we here talk about supporting C++ header for programs to call avisynth when video is needed in the program. When avisynth supports unix, the devs need to change all that so it supports both systems. Until avisynth becomes unix stable I think Avisynth+ has a better chance but it has the header thingy also. It uses exact same header.

Well in unix these functions are ignored in the build prosess and used are only normal functions that are public at unix but this means building with g++ at linux and building with msvc at windows. How ever does vstudio handle good autotools and qt projects?

[handaimaoh]

The runtime issues are for avisynth devs, we here talk about supporting C++ header for programs to call avisynth when video is needed in the program. When avisynth supports unix, the devs need to change all that so it supports both systems. Until avisynth becomes unix stable I think Avisynth+ has a better chance but it has the header thingy also. It uses exact same header.

Well in unix these functions are ignored in the build prosess and used are only normal functions that are public at unix but this means building with g++ at linux and building with msvc at windows. How ever does vstudio handle good autotools and qt projects?

They don't need to change anything for Windows. You simply use ifdefs and nothing is broken.

[TurboPascal7]

Until avisynth becomes unix stable I think Avisynth+ has a better chance but it has the header thingy also. It uses exact same header.

Avisynth+ will get a C API when coming to Linux of course, most likely with a thin C++ wrapper provided for convenience.

Now I have a question: why do you even bother with this header? Vanilla avisynth will never work on linux and you won't port it. What do you want to achieve?

[Guest]

He wants to bring all of Doom9's developers out of the past and into the future:

Development sometimes need drastic movements and towards cross platform support to stay touch with the time.

[handaimaoh]

Avisynth+ will get a C API when coming to Linux of course, most likely with a thin C++ wrapper provided for convenience.

Now I have a question: why do you even bother with this header? Vanilla avisynth will never work on linux and you won't port it. What do you want to achieve?

He was apparently unaware of the C interface that already existed for quite some time now and thus was trying to poorly recreate it by creating a Frankenstein header file from the C++ interface. Why he continues to persist down this path after knowing of the C interface's existence, though, is definitely a mystery. Especially when he doesn't understand ABIs, calling conventions, etc. and doesn't understand why what he's doing is not as simple as he's making it out to be. But then again with choice quotes like:

The runtime issues are for avisynth devs

I couldn't help but laugh my butt off.

[Jeroi]

He was apparently unaware of the C interface that already existed for quite some time now and thus was trying to poorly recreate it by creating a Frankenstein header file from the C++ interface. Why he continues to persist down this path after knowing of the C interface's existence, though, is definitely a mystery. Especially when he doesn't understand ABIs, calling conventions, etc. and doesn't understand why what he's doing is not as simple as he's making it out to be. But then again with choice quotes like:



I couldn't help but laugh my butt off.

Well I am not interested to develop avisynth, there are others for that. Also I am not naming you with any names. But glad that I can entertain you. Instead of calling me as poor please do some work for these projects and we can have mutual respect for each other. I also took the risk to talk people like you, who comment work that is not complete, in development, asking people to join. I am fully aware that people like you exists. And for the record I do have Java and C background so jumping to these projects are a learning prosess but satisfactory to do.

[TurboPascal7]

Well I am not interested to develop avisynth, there are others for that.
These "others" and a few more people already told you - this will never happen. Give up. No one will (help you) modify avisynth C++ API to get it compatible with mingw because it's freaking impossible. Use the existing C API if you want to compile anything with mingw right now.

C++ API compatible with different compilers will most likely be added to Avisynth+ in the future as a wrapper around a C API.

Before that, if you're targeting GNU/Linux, VapourSynth is your best bet. Stop wasting your time.

[Guest]

No one will (help you) modify avisynth C++ API to get it compatible with mingw because it's freaking impossible. Use the existing C API if you want to compile anything with mingw right now.

C++ API compatible with different compilers will most likely be added to Avisynth+ in the future as a wrapper around a C API. That sounds inconsistent to me. Why couldn't Jeroi also make a C++ wrapper around the C interface? It's possible if you do it but not Jeroi? I don't get it.

The impossibility here is the idea of cross platform runnability of the executables.

I guess we're back to asking Jeroi exactly what he is trying to accomplish. Just rambling about "cross platform is needed for modern times" is too nebulous to convey any real meaning.

[TurboPascal7]

Why couldn't Jeroi also make a C++ wrapper around the C interface? It's possible if you do it but not Jeroi? I don't get it.
There's nothing that prevents Jeroi from writing his own wrapper of course. But if he wants to get one without doing any work - he'll need to wait. That is all.

[handaimaoh]

That sounds inconsistent to me. Why couldn't Jeroi also make a C++ wrapper around the C interface? It's possible if you do it but not Jeroi? I don't get it.

He could, but as I quoted above he's trying to punt that work off onto someone else. Likely because he is way over his head and has no clue how to do so.

[Jeroi]

He could, but as I quoted above he's trying to punt that work off onto someone else. Likely because he is way over his head and has no clue how to do so.

Rolf, that line get people normally banned, ofcourse I can write wrapper. But I was not even talking about it, you people seem always to refer C header. I am always talking about the C++ header and the need of it to be rewrite as you guys all know, if I modify the header to include cdecl calls the plugin is dll but Avisynth expects stdcalls which breaks it work. I can even make windows dll with QT that would associate right output calls in windows but to me it would be too just one project file as who would like to add bunch of qt stuff to their c++ plugin which makes the filesize quite big and feels dum. Much better way would be modify orginal project header to support many compilers. But this header was written in 02´ and people here seems from that era altho I am over 30 years old but I feel that programs should support also cross compiling in ideal world and M$ does not represent ideal.

Somehow I feel the same level with Ultim that this project should need new blood to take it further. It feels like stone aged.

[jackoneill]

If I'm not mistaken, the stdcall decorations only matter for the functions you export, namely AvisynthPluginInit2/3. stdcall functions can be decorated ("_function@bytes") or not ("function"), and Avisynth tries both versions (https://github.com/jeeb/avisynth/blob/master/src/core/plugins.cpp#L114). Now, gcc decorates stdcall functions only halfway ("function@bytes"), and I don't know if you can make it prepend the underscore, but you can make it produce the not-decorated version instead, using "-Wl,--kill-at".

[handaimaoh]

I am always talking about the C++ header and the need of it to be rewrite as you guys all know,

It does not need to be rewritten. To do your wrapper you simply need to do ifdefs around compiler and platform specific pieces. This prevents having to break anything for currently existing plugins and requires zero rewriting of anything on the Avisynth side either.

Much better way would be modify orginal project header to support many compilers.

Of which the way to do so is through #ifdef so you can maintain ABI compatibility with Avisynth and Avisynth+.

[Guest]

Guys, it's getting too personal. I will start issuing strikes for posts that attack a person rather than being factual and technical. Doom9 is about civil technical interaction. If you can't keep it that way then please do not post. Thank you for your understanding.