SimpleSample compiles, but Avisynth won't load it. Anyone know what I'm doing wrong?

[Mini-Me]

I'm trying to learn Avisynth plugin development. My first plugin is building correctly, but Avisynth isn't loading the .dll correctly. I'm getting Avisynth open failures with an 0x7e error in LoadPlugin. I tried compiling SimpleSample1.0b, but I get the same error with that too. Here are a few details:
I'm currently building against 2.5.8 with a 2.5.8 header.
I'm using VC++ 2010. That probably includes the necessary platform SDK stuff by itself, but I also went ahead and got the Microsoft Platform SDK 7.0A.
I've tried setting up the project as a Win32 console application and as a Win32 application (both as DLL's and empty projects).
I've also tried compiling in both debug and release configurations.
I noticed something odd about the debug binary though: Even though it built fine without any errors or warnings, the actual .dll contains some strange error messages inside, like:
Unknown Runtime Check Error
Stack memory around _alloca was corrupted
A local variable was used before it was initialized
Stack memory was corrupted
A cast to a smaller data type has caused a loss of data. If this was intentional, you should mask the source of the cast with the appropriate bitmask. For example:
char c = (i & 0xFF);
Changing the code in this way will not affect the quality of the resulting optimized code.
The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
WTF? There are a bunch of error messages embedded inside the .dll like this. Anyone know what the deal is?

I originally posted this in the filter SDK sticky thread, but it'll probably get more visibility in its own thread, so I redirected here. I'm hoping that's not a violation of the cross-posting rule.

[Youka]

I'm getting Avisynth open failures with an 0x7e error in LoadPlugin. I tried compiling SimpleSample1.0b, but I get the same error with that too. I'm currently building against 2.5.8* with a 2.5.8 header, and I'm using VC++ 2010.
- You changed some things? If yes, post your source please.
- msvc++ 2010 dll builds need .NET4. You tried your compiled plugin on a computer without this .net version?
- You could use 'try & error'. Insert message popups inside your code on different lines and test in which line your plugin fails.

[Mini-Me]

- You changed some things? If yes, post your source please.
I originally wrote my own plugin, but after that didn't work I tried SimpleSample1.0b (totally unmodified). I simply copied the source from the SDK webpage into a .cpp file. It builds just fine, but Avisynth won't load the .dll, and the .dll has mysterious error text embedded in it.

- msvc++ 2010 dll builds need .NET4. You tried your compiled plugin on a computer without this .net version?
I'm pretty sure I got .NET4 with the Platform SDK 7.0A, if I didn't already have it...but I'll double-check in a few minutes.
Update: Yup, I already have .NET 4.0. :-/

- You could use 'try & error'. Insert message popups inside your code on different lines and test in which line your plugin fails.
Avisynth completely refuses to load SimpleSample, so...where should I put error output? Once before env->AddFunction and once after? I have a feeling the issue might come even earlier though, when Avisynth is trying to call AvisynthPluginInit2 in the first place...

[Gavino]

I'm getting Avisynth open failures with an 0x7e error in LoadPlugin.
...
I'm currently building against 2.5.8 with a 2.5.8 header.
2.5.8 doesn't report the LoadLibrary error code in LoadPlugin.
You must be running 2.6.0 (although it should still work).

I noticed something odd about the debug binary though: Even though it built fine without any errors or warnings, the actual .dll contains some strange error messages inside
Sounds like you have bits of the C Runtime statically linked into your dll. What linker options are you using?

[Mini-Me]

- msvc++ 2010 dll builds need .NET4. You tried your compiled plugin on a computer without this .net version?
OH, WAIT! I misread your comment: I built the plugin on a computer with .NET 4.0, but I tried using it on another computer (the one I usually use Avisynth on).

After I tried testing on this computer, the plugins loaded! So...that was the problem after all. Thank you!

UPDATE: If anyone else reads this thread and has the same problem, note that .NET was NOT the issue. Thankfully, VC10 does not shoehorn in an arbitrary .NET dependency. It's just that every build links to the VC runtime library for basic C routines, and newer versions of Visual Studio link to newer versions of the library, which older versions of Windows do not have. There are three ways to solve this:
Install the correct version of the distributable VC runtime library on every computer where you want to run the software.
Use an older version of Visual Studio that links to a lower versioned runtime.
Use the /MT switch instead of /MD, which will statically link the runtime library.
...and now, back to my usual scheduled incorrectness, after these bold-text messages.

Requiring plugin users to have .NET 4.0 is a pretty steep and arbitrary requirement though...I mean, it's just a Win32 dll, nothing fancy. It's pretty clear that's not the norm around here, since all the Avisynth plugins I've used have worked without .NET 4.0 (obviously, since I never had problems using them until now ;)).

I'm looking into targeting an earlier version of the .NET framework with VC++ 2010 Express...or, you know, no version at all. Is there any technical reason why Avisynth plugins would need any .NET dependency whatsoever? After some digging, I've found out a few things:
Visual Studio 2010 targets .NET 4.0 if earlier versions of Visual Studio are not installed.
Visual Studio 2008 targets .NET 3.5.
Both are supposed to be capable of targeting other versions (2010 should if 2008 or earlier is also installed)...but in practice, anything having to do with targeting a different version is grayed out. Maybe that's a good thing...is it possible that if it's grayed out, it means .NET isn't being targeted at all?
Even if .NET isn't being targeted, the target computers must have the correct VC++ runtime version installed (the same it was compiled with), unless it's statically linked into the binary. This could also explain why my other computer (Windows XP, .NET 3.5.1 installed) couldn't run the dll's built with Visual Studio 2010...
However, debug builds have differently versioned dependencies from release builds. If I use the v90 toolkit from 2008, my release build will run on my XP box, but my debug build will not. That's very strange by itself though, because a working release build demonstrates that my XP box has the v90 runtime, and I already know it has .NET 3.5.1, which is the latest version Visual Studio 2008 targets.

What a mess...it seems like the newer your compiler, the less portable the code will be.

2.5.8 doesn't report the LoadLibrary error code in LoadPlugin.
You must be running 2.6.0 (although it should still work).
Good catch. I built on 2.5.8, but I was testing the plugin on a different computer from the one I developed on - probably a bad idea in hindsight - and I'm using 2.6 alpha 3 on that computer. As it turns out, using a computer without .NET 4.0 was the problem...but I'm still curious about the embedded messages.

Sounds like you have bits of the C Runtime statically linked into your dll. What linker options are you using?

Is that normal/typical for debug builds? I'm just using the default debug build settings. Copied and pasted:

/OUT:"C:\Users\Mini-Me\Documents\Visual Studio 2010\Projects\SimpleSampleTry2\Debug\SimpleSampleTry2.dll" /INCREMENTAL /NOLOGO /DLL "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /MANIFEST /ManifestFile:"Debug\SimpleSampleTry2.dll.intermediate.manifest" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\Users\Mini-Me\Documents\Visual Studio 2010\Projects\SimpleSampleTry2\Debug\SimpleSampleTry2.pdb" /SUBSYSTEM:WINDOWS /PGD:"C:\Users\Mini-Me\Documents\Visual Studio 2010\Projects\SimpleSampleTry2\Debug\SimpleSampleTry2.pgd" /TLBID:1 /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:QUEUE

Looking through the settings, it seems the culprit is probably "Basic Runtime Checks," which uses the /RTC1 flag. (The description mentions stack frame checks and uninitialized variable checks.) That flag doesn't show up in the above copy/paste, but it might be implied by /DEBUG. Odds are, the embedded messages are simply part of the code needed to display the errors in the event the runtime checks fail.

[Groucho2004]

First of all, if you have a .NET dependency in your simple plugin you're really doing something wrong.

There may be a dependency to the VC runtimes but even that can be avoided using the "MT" switch.

I have built plugins with VC6 through VC8 and I never had any dependencies.

[Mini-Me]

First of all, if you have a .NET dependency in your simple plugin you're really doing something wrong.
That's what I thought too! I created a Win32 project, and the /clr switch is off, so there is absolutely no good reason for anything .NET to be targeted whatsoever. It's not like I selected C# or anything. ;)

It's just that Youka mentioned a .NET 4.0 dependency for VC10. Afterwards, I looked in the Project Properties->Common Properties dialog box, and it turns out it says, "Targeted framework: .NETFramework,Version=v4.0." It's simply stated as a fact, not a selectable option or anything, and it seems to say that no matter what. VC9 says something similar in the same dialog box. It says, "Targeted Framework: .NET Framework 3.5." Here, the latter part is a drop-down list, but it's grayed out.

As it turns out, you are correct: .NET is not actually being targeted. The fact that the drop-down list is grayed out in VC9 seems to hint this too: I think it just means .NET isn't being targeted at all, and it's just something the project properties always show, i.e. "in the event you chose to use .NET, this is the version you'd be using."

As you say below, the only real dependency is on the VC runtimes.

There may be a dependency to the VC runtimes but even that can be avoided using the "MT" switch.

I have built plugins with VC6 through VC8 and I never had any dependencies.

I've been using VC9 and VC10, but /MT should let my XP computer run the plugin no matter which build I use. UPDATE: I just checked, and it turns out that's exactly the case. If I use /MT for release and /MTd for debug, the plugin runs anywhere. Thank you. :)

It seems that most plugin writers are using VC8 or lower, so their plugins would work on my XP build (without the newest runtimes) regardless of whether they chose /MT or /MD. Is it customary to build Avisynth plugins statically linked with /MT, or is /MD usually used instead? If the latter is the case, I'll need to get VC8. Otherwise, maybe I'll /MT with VC10 and take advantage of C++0x features...

[jmac698]

VC.. ugh! There is no need to use this huge program.
BloodShed Dev C++ is only 2mb.
Full guide here
http://forum.doom9.org/showthread.php?t=158439&highlight=compile&page=2

[TheFluff]

VC.. ugh! There is no need to use this huge program.
BloodShed Dev C++ is only 2mb.
Full guide here
http://forum.doom9.org/showthread.php?t=158439&highlight=compile&page=2

If you use any non-MSVC compiler you must use the C-plugin interface rather than the C++ one, because C++ interfaces are not portable between compilers the way C interfaces are.

[Mini-Me]

If you use any non-MSVC compiler you must use the C-plugin interface rather than the C++ one, because C++ interfaces are not portable between compilers the way C interfaces are.

In addition, development of Dev C++ was discontinued a long time ago. A new programmer has been working on it since about a month ago, but there's no telling whether he'll stick with it. I assume he's using the newest GCC, which is what really matters, but...that still comes back to the C++ ABI incompatibility.

My particular problem might have come up with any IDE and build chain anyway; I was dynamically linking to dependencies that were too new. Dynamically linking to GNU libc might have created the same problem.