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

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:

1. avisynth_c.dll works as replacement for Mingw c++ apps.
2. 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.
3. 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]

Originally Posted by Jeroi

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

What?

Originally Posted by Jeroi

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

What?

Originally Posted by Jeroi

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]

Originally Posted by Groucho2004

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.

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]

Originally Posted by handaimaoh

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.

Originally Posted by Groucho2004

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]

Originally Posted by Jeroi

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]

Originally Posted by handaimaoh

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"?

Originally Posted by Groucho2004

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.

Originally Posted by 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.

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]

Originally Posted by Groucho2004

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.

Originally Posted by handaimaoh

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.

Originally Posted by Jeroi

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]

Originally Posted by handaimaoh

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.

Originally Posted by Jeroi

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]

Originally Posted by handaimaoh

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.

Originally Posted by Jeroi

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.