View Full Version : Fear and Loathing with MEgui, AVS, and .net2.0 x64

3rd February 2006, 02:48
hello, i'm not sure if this is an ok place to post this since i don't really think
its a megui bug thats causing it but it definetely has to do with megui so i'll
provide as much info about the problem and my computer etc, as i can think

Ok so when i go to my new shiny version of megui .net 2.0 version I run into
this nasty error below. That is my problem i'm fairly sure that megui is not
the problem neither is the avs since it works on older megui that use .net 1.1.
I have .net 2.0 x64 installed as do i have avisynth 2.56. (tried 2.55 also)

http://www.1mbupload.com/uploads/1a7a1f9b72.jpg (http://www.1mbupload.com/landingpage.html)

I'll follow this error message with the script i'm trying to use (tried avi's and directshow files but nothing)



This avs file works fine when using megui .net 1.1 version or vdubmod will open it as well. I personally believe its a amd 64 x2 or perhaps a .net x64 problem but since i'm pretty sure doomy himself have a dual core amd processor i can't imagine this being a common problem. At the height of my
fruastration i formated and installed a clean new xp x64 os but no progress.
here is a simple list of hardware and software etc...

amd 64 x2 3800+
1g ddr dual chan ram
windows xp x64 edition professional
two 120gb ide hard drives
1 34gb seta drive
dvdr burner (can't see why this would be info anyone would need)
ati radeon 9600
3 network cards
(if this is a horrible description of my system i apoligize just ask i'll try and tell
you whatever info you need to figure out whats going on.)

I've been using megui .net2.0 on my other two computers that are just x86 pentium 4's with no problems at all. I've checked and made sure i have all
the other software that megui needs to run properly. I've used the older .net
1.1 megui for awhile now with no problems really until the update to .net 2.0.
I'd post the log if i could get that far in the program (doesn't have a chance to even make one).

ok so thats the about the sum on my problem any help would be wonderful. sorry if this is in the wrong place or if i haven't searched the forum enough
and there is a solution somewhere else.

3rd February 2006, 09:42
umm... Win64.. has it ever worked for you? And it looks like somebody didn't change script checking to the avisynth wrapper like I asked for... (hint for dimzon). Now, check your avisynth script in a VfW app (VirtualDub(mod)) please and report any errors you may be getting. And a format really shouldn't be necessary ;)

3rd February 2006, 10:28
I think (not completely sure since I haven't tried myself) this is because running megui with .net x64 = a 64-bit program, and 64-bit programs can't use 32-bit dlls e.g. avisynth. Even with 64-bit avisynth that script won't work because the plugins are 32-bit.

Richard Berg
3rd February 2006, 12:43
The solution is to add /platform:x86 to the C# compiler options.

3rd February 2006, 12:49
The solution is to add /platform:x86 to the C# compiler options.Would that make the app run in 32bit mode on Win64? I think the issue lies with the AviSynth script and plugins though so imho that needs to be checked first.

Richard Berg
3rd February 2006, 16:36
Would that make the app run in 32bit mode on Win64?
Yes. /platform:msil is the default, which gets JIT'd into the runtime's native instruction set.

4th February 2006, 00:49
hi thanks for the reply's yes i have opened the script fine in virtualdubmod. i can easily just open up the last version of megui .net 1.1 and encode using that. I can also move the files onto my other computer(x86) that has megui .net 2.0 and it will run just fine. only seems to be on this comp with .net i'm guessing since avisynth works fine in virtualdub and megui .net 1.1 . hope this helps just ask if there is anything else you might need to know about the situation. oh and when you ask if win64 has ever worked for me are you asking if the megui .net 2.0 version has ever worked? in which case in opens but i've never gotten in to encode on this x64 computer. unless you mean win 64 in general in which case no there have been combatability problems with some other things (games mostly)

4th February 2006, 00:58
Yes. /platform:msil is the default, which gets JIT'd into the runtime's native instruction set.

Is it true that VB .NET integer and c# int maps always and anywhere to System.Int32? Sounds rather stupid, the responsible architects are not stupid so there must be reasons (that I would like to know).

Richard Berg
4th February 2006, 01:51
Yes. C# spec (http://msdn.microsoft.com/library/en-us/csspec/html/vclrfcsharpspec_4_1_4.asp)

It makes perfect sense to me. The way native value types change size across platforms is a huge pain in the ass in C++. (There were legitimate reasons for it to be that way in C, but IMO if the ability to compile C hadn't been so important to Bjarne he would've changed it in C++ decades ago.)

Look at any highly portable C++ library, say libjpeg. The first few hundred lines are spent doing pointless #ifdefs & #defines so that the rest of the code finally has custom types to work with that are guaranteed to be 8, 16, etc. bits wide.

4th February 2006, 02:20
Wouldn't run Int64 on x64 systems faster? If so wouldn't it be then desirable to have C# int to be Int32 on 32 bit system and Int64 on 64 bit systems?

Like C# int would map to IntPtr and that would be used for arithmetic operations.

Richard Berg
4th February 2006, 02:59
No. It might even be slower...I haven't looked at the A64's latencies. And of course, it would make lots of calculations wrong.

4th February 2006, 10:07
ha ok so i'm going to guess by my lack of c# or any programming lang (except maybe html ha) that i can't really do anything mostly because of incompatabilty issues with 32 bit apps and windows x64 or 64 bit processors? or is it something that can be solved by compiling or revising rather a megui version? Or am i stuck in a megui 1.1 world? again thank you for the insight this has been driving me crazy...
I mean its not really a big deal to me since i can use another computer or even just go the the command prompt and just use x264 the old fashion way. but its still been bugging me ^^

Richard Berg
4th February 2006, 20:46
It should be fixed in the next release of MeGUI.

4th February 2006, 22:26
I'm getting the same error here, also on Windows XP x64. Is there a way to download a source code of MeGUI without instaling CVS because i want to compile it.

EDIT: As I posted in development thread, i compiled MeGUI for x86 platform and it works as a 32-bit application.

5th February 2006, 02:10
Not sure if it had been implemented in megui (when i wrote this i tried but nothing has helped yet. I'm proubly jumping the gun but just in case i thought i'd let you guys know.

6th February 2006, 15:53
I'm trying to use MeGUI on Win64 as well, and would very much like this to get fixed very soon. Or at least, if someone could post a link to a precompiled 64bit compatible binary, as I'm not much for compliling myself.

6th February 2006, 16:03
as I'm not much for compliling myself.You just need the sources.. then all it takes is a double click on compile.bat.. you don't need to install any software.

6th February 2006, 16:09
I see, I didn't know that. Thanks!

8th February 2006, 02:07
hi not to bother anyone but i just want to make sure i understand the problem.
If i understand correctly (correct me if i'm wrong please) I'd have to compile it myself? I've tried the newer dev builds but i get the same error msg with a new added msg at the end.

"Error message for your reference: An attempt was made to load a program with an incorrect format. (exception from HRESULT: 0x8007000B)

Don't know if its suppose to be fixed or if i'm suppose to compile it myself (which i can understand i mean there must be all of 5 people who need this)

8th February 2006, 02:38
Theoretically, it would be very easy to fix, and when Richard said it will be fixed in the next version, I think he meant it *should*. At the moment, it is just another feature on the TODO list, so it will be done at some time or another. Until then, you can either wait or compile yourself.

Richard Berg
8th February 2006, 02:56
I meant it'll be fixed in the next major version that goes up on Sourceforge.

8th February 2006, 10:22
As I mentionned in the bug report (I did not see this thread before), you can use the .net SDK tool Corflags.exe to mark exes as 32 bit only, if you want to avoid a recompilation.

11th February 2006, 13:43
oh my god i love you that worked perfectly. very easy thanks