AviSynth 2.6 move to VC2005 Express.

[sh0dan]

I think it's about time that AviSynth moved off an 8 year old platform, so I have ported AviSynth 2.6 to VC++ 8 Express.

This makes it possible for you to compile and contribute to AviSynth 2.6 with Microsofts free Express Edition. It might also fix some of the bad compiler issues Ian has spent so much time tracking down.

If nobody have any serious objections, I'll commit the code to the 2.6 branch.

[Guest]

Can VC++ 8 Express co-exist with earlier versions on one's PC, such as VC++ 6?

[berrinam]

What libraries are required, since VC2005 Express doesn't come with any at all? MS Platform SDK, perhaps?

[Wilbert]

Can VC++ 8 Express co-exist with earlier versions on one's PC, such as VC++ 6?
15. Will the Visual Studio Express Editions install side-by-side with other versions of Visual Studio?

Yes, side-by-side compatibility with other versions of Visual Studio has been tested.

from the FAQ: http://msdn.microsoft.com/vstudio/express/support/faq/default.aspx

What libraries are required, since VC2005 Express doesn't come with any at all? MS Platform SDK, perhaps?
They say you will want to install PSDK, so i guess that means yes :)

http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/


I guess you need to uninstall .NET Framework 1.1 or .NET Framework 2.0 first though.

installing without registering: http://forum.doom9.org/showthread.php?p=736161#post736161

[foxyshadis]

I didn't have to, and even the pro version needs an updated PSDK as soon as you install it. VC Express does come with basic header files, but I'm not sure if it's missing libraries like openMP.

[IanB]

Call me a ludite but I will still be working with good ol' VC6! I see no reason to break support for that.

[sh0dan]

Can VC++ 8 Express co-exist with earlier versions on one's PC
Yes - works very nicely on my PCs. "DSW" files open in VC6, "VCPROJ" in VC7, "SLN" in VC8.

What libraries are required, since VC2005 Express
There is no MFC support in VC2005, but AviSynth doesn't use MFC, expecpt for adding the version number to the DLL. Other than that the PSDK is required for AviSynth, and DirectX for compiling the Directshow plugin. TCPDEliver needed to have some AFX-related stuff removed, but I've already done that.

@IanB:
The main change is that variables declared in a for loop will no longer work outside the for-loop scope - that will not compile in VC6. I had to recompile the Soundtouch library with VC8, but beside that nothing much besides loops had to be changed.

I see no reason to break support for that
Well, the world moves on. VC8 is free, which I think is a great thing for OS software, it's supported, and has a better compiler.

[Fizick]

How will be VC6-compiled plugin compatibility?

[foxyshadis]

Seamless, as far as I can tell, except that once in a while you have to substitute the VC6 or 7 ml.exe while assembling, or disable for loop conformance (as sh0dan mentions). For the most part every plugin I've loaded has compiled without errors on the new one.

Oh, and DXSDK isn't required at all anymore (unless you're building MPC or something), DS is all in PSDK, although the version of PSDK that comes with 2005Pro is so dated that it doesn't include DirectShow at all.

[IanB]

The main change is that variables declared in a for loop will no longer work outside the for-loop scope - that will not compile in VC6.It won't compile only if you don't fix the code correctly.

[IanB]

Sh0dan, you are really pushing it here. Yes, I think it is a good idea to feed the source through the new compiler and amend the code to clean up all the warning/errors in preparation. And we should do this at the maximum winge level. And yes we should be exercising this new environment. But it does not mean that we should not be able to still develope and debug under familiar VC6. When finding and fixing insideous bugs in a major new release I really don't need the extra headache of fighting to learn a new environment.One little change that can bite you is that catch(...) no longer catches Win32 exceptions, most notably access violations.This is a very serious problem! Do we really want to spend a lot of time reworking this, instead of getting the new core functionality written.Note that Express does not include the Win32 resource editor, ...This also effect the ICON as well as the REV block. It will probably be good for the soul to relearn to manuallly edit .RC files. ;)

[foxyshadis]

Express doesn't include the resource editor but that doesn't mean you can't import from VC6/7. Odd about the other one though. (Avery has amazingly informative blogs about VS.)

[sh0dan]

@IanB: ok - never mind. Let's just keep the old VC6, then.

[IanB]

@sh0dan: - By all means checkin any syntax polishing you have worked on. Getting the source syntax cross compatible is a very important first step.

My thoughts for doing a platform change would be to do it as a null functionality change so we can do A - B cross checking. Something like develope 2.6.0 under VC6, with near as possible 2005Exp compatible syntax. Do 2.6.1 as a bug fix release + reworking of things like the *.ASM's and the try/catch(...)'s that will choke in 2005Exp. Then do 2.6.2 as an Identical 2005Exp release of 2.6.1 i.e. no new features just pure base translation.

[devaster]

where is source ???
i have checked cvs yesterday and avs26 folder is empty ...

[IanB]

It's in the regular tree as CVS branch "avisynth_2_6"

[devaster]

IanB :
when I select this CVS branch its still empty ...
Iam using a tortoise CVS for checking ...

[IanB]

Wander around the CVS Tree (http://avisynth2.cvs.sourceforge.net/avisynth2/avisynth/src/?sortby=date&pathrev=avisynth_2_6#dirlist) with a web browser to get your bearings first. The files changed specifically for 2.6 have revision stamps like 1.22.2.6 (4 part numbers)

[Wilbert]

I attached two screenshots for you. pm the relevant mods if it they forget to approve them :)

[devaster]

Thanx Wilbert

[scharfis_brain]

Is there a binary of AVS 2.6 available?

[Wilbert]

Is there a binary of AVS 2.6 available?
http://www.avisynth.org/FeedBack

[sh0dan]

My thoughts for doing a platform change would be to do it as a null functionality change so we can do A - B cross checking. Something like develope 2.6.0 under VC6, with near as possible 2005Exp compatible syntax. Do 2.6.1 as a bug fix release + reworking of things like the *.ASM's and the try/catch(...)'s that will choke in 2005Exp. Then do 2.6.2 as an Identical 2005Exp release of 2.6.1 i.e. no new features just pure base translation.

ASM is compatible. Clean installers can download the assembler for VC2005 at:

http://www.microsoft.com/downloads/details.aspx?FamilyId=7A1C9DA0-0510-44A2-B042-7EF370530C64&displaylang=en

Try/Catch need to be replaced by __try/__catch - they catch Win32 exceptions.

I had to remove the ressource files from the project, since it requires MFC. I suppose there

The SoundTouch library had to be recompiled, since it linked too many libraries. I downloaded the new version and compiled it.

ok - the way it could be made cross/compatible:

We use the pragma, to enable VC6 "for-loop scoping".
We fix the "implicit int" errors (only a few) in the code, they are compatible with VC6.
We replace try/catch, that catches win32 expections with TRY/CATCH, and use defines for them.
We exclude the ressource file from the VC2005 project.

I still think a clean switch would be easier, since it would mean we only have to support one compiler (there is no reason for people not to install VC2005, since it's free).

I thought the outlook of a compiler that most probably has fixed the SEH-problem would get you out of your chair. Guess I was wrong.

[IanB]

ASM is compatible.Not necessarily the *.ASM files, I was expecting the tighter need for qword ptr etc in the inline stuff to sting. Which really is wrong/slack the way it is. Try/Catch need to be replaced by __try/__catch - they catch Win32 exceptions.Do you mean __try/__except? In many cases a __try/__finally would be a cleaner choice. Wrinkle is you can't mix SEH and C++. C++ routines that have stack based objects implicitly get C++ exception handling to do the object destructor code. And these objects do leak when you eventually handle system exceptions in 2005. I had to remove the ressource files from the project, since it requires MFC. I suppose thereJust dust off your doing .RC files by hand knowledge. We don't need the MFC crap, we just want one ICON and one REV block. The SoundTouch library had to be recompiled, since it linked too many libraries. I downloaded the new version and compiled it.What a newer new version, I only upgraded CVS to 1.3.1 a little while ago. Ah! you are just catching up.ok - the way it could be made cross/compatible:

We use the pragma, to enable VC6 "for-loop scoping".Yeeetch, just replace the poxey for (int i=0; construct in the few places it is ambiguous. We fix the "implicit int" errors (only a few) in the code, they are compatible with VC6.Also there are a batch of signed/unsigned that are being #pragma'd away that should be explicitly fixed. We replace try/catch, that catches win32 expections with TRY/CATCH, and use defines for them.Maybe, the implicit C++ handling with stack based objects might scuttle this, cleaver thinking will be required. We exclude the ressource file from the VC2005 project.Just strip the MFC crap from the .RC and hand edit it when we bump a rev.I still think a clean switch would be easier, since it would mean we only have to support one compiler (there is no reason for people not to install VC2005, since it's free).Well I was proposing a clean switch, just not quite yet.Then do 2.6.2 as an Identical 2005Exp release of 2.6.1 i.e. no new features just pure base translation.The important point is that the compiler transition is the only change from release N to release N+1. No other feature or bug fixes should be done.

And actually yes there is a very good reason. It will only install on the latest service packed versions of 2K, XP and 2003. NOTE! No NT4/98/ME debugging. This is yet another Micro$oft Genuine DISadvantage carrot and stick. I can run up VC6 on any machine in my network that can map my V: drive, 2005 won't even begin to think about running on a machine that has not had 2005 explicitly installed on it and it will only install if the service packs are to it's liking and it also wants that filthy stinking .NET pollution to be installed.I thought the outlook of a compiler that most probably has fixed the SEH-problem would get you out of your chair. Guess I was wrong.Well I am actually pretty pissed with Microsoft over this. The SEH and other problems were well known about while VC6 was still mainstream, but VC.Net was about to go beta so the fixes went into it and VC6 languished.

To me a C compiler/debugger should be pretty environment agnostic, you put source in 1 end and get executable code out the other. I really don't care if the pretty GUI pretends to need some wiz bang feature only in the latest service pack.

[madoka]

To me a C compiler/debugger should be pretty environment agnostic, you put source in 1 end and get executable code out the other. I really don't care if the pretty GUI pretends to need some wiz bang feature only in the latest service pack.
I believe it's possible to use the new VC8 compiler with the old VC6 IDE. Unfortunately, I forgot where I saw the instructions. Try searching with Google.

From the language conformance and quality of implementation perspectives, VC8 is light years ahead of VC6. Of course, there are many other considerations in the real world, so I understand your sentiment.

Or you can do what I do: use (X)Emacs & make. :)

[foxyshadis]

IanB:
http://msdn2.microsoft.com/en-us/library/bt727f1t.aspx

Unfortunately remote debugging appears to be limited to Pro. Bah. But it is possible on NT/98.

[henryho_hk]

Doesn't the free Express edition lack optimization options?

[sh0dan]

@henryho_hk: No. They are all there.

btw, a VC2005 Express solution is now included in CVS.

[Richard Berg]

convert_a.asm still doesn't assemble in masm8.

error A2070: invalid instruction operands - line 290

I had to switch to masm6 to make it work.

Also there are a batch of signed/unsigned that are being #pragma'd away that should be explicitly fixed.
I'm working on these an other MSVC8 warnings slowly but surely.

[Fizick]

Why to use masm8? May be better to port it to nasm?
Some time ago I try to port Convert_rgb_mmx (which is almost plain copy of convert_a_asm) from Cedocida codec to Nasm. It works fine.

[Manao]

Nasm/Yasm would really be a must. I would gladly help making such conversions, especially for removing all the inlined asm code.

[squid_80]

Removing the inlined stuff isn't as simple as that since it uses variables as well which you can't do with external assembly.
Fixing it to work with masm8 is trivial, converting it to nasm would mean one more program to add to the tool chain. Don't get me wrong, I would love to see everything converted but speaking from experience (For 64-bit I rewrote the color conversion routines for yasm) it's not worth the effort.

[Fizick]

Anyway, here is 2.5.6 NASM code :)
http://avisynth.org.ru/tmp/convert_a_nasm.asm

nasmw.exe -f win32 -dPREFIX -o $(IntDir)\$(InputName).obj .\convert\$(InputName).asm

[Richard Berg]

Nasm/Yasm would really be a must.
Why? The only thing I can think of is portability to Linux, which is a lot more work than just fixing the ASM...

[IanB]

If people are really keen to spin there wheels, then Softwire is probably a better choice apart from the lack of a 64 bit version, yet.

As for easy of coding you can't beat inline assembler like in VC. It is a real pity some ludite decided not to continue supporting it into 64 bit. Yes it is not in the slightest portable, but then that is not why people write hand optimized assembler. It is generally a given doing so is targeted at a single environment and performance is sufficiently critical to make any support difficulties cost effective.

Call me slack but being able to write like this rocksint SomeRoutine(int arg1, char *arg2, ...)
{
int i, j;

for (i=0; i< arg1; i++)
{
__asm {
put some really hoakey
assember in here
}
}
return j;
}What more could a programmer want, the compiler does all the mundane work, subroutine entry/exit, stack management, loop contructs and I get to thrash the instruction set to my best advantage.

[Richard Berg]

My [completely unfounded] guess is that MS cared less about portability and more about the way __asm makes most compiler optimizations impossible. Too bad intrinsics are still hard to read and generate bad code (http://www.virtualdub.org/blog/pivot/entry.php?id=46).

[Manao]

Mundane work when coding in asm can be easily handled by a proper set of macros. Nasm/Yasm preprocessor is quite powerfull ( a lot more than the C preproc ), so you can easily reduce the amount of work with it. It remains the loops. But :
mov eax, [esp + .nHeight]
.loop_y
line processing
dec eax
jnz .loop_yIsn't a lot more complicated than your loop, is it ? And it's mostly what you have to do when you image processing.

Even for non portable code, I don't use the inline assembler anymore.

Yes it is not in the slightest portable, but then that is not why people write hand optimized assembler? You are using a quite broad definition of portability. I was more thinking of cross-OS compatibility, not cross-platform. Anyway, with Mac now using Intel processors, the two will merge.
Why? The only thing I can think of is portability to Linux, which is a lot more work than just fixing the ASMAsm is the biggest part. AVISource is the second biggest. DirectShowSource is hopelessly lost. External filter is the third and last one.

Finally, 64bit assembly can be gained easily during the conversion, without having to write every function twice ( thanks again to the macros )

[squid_80]

I thought it conflicted with the new way epilogs and prologs have to be arranged and annotated.

I might have said this before but when I rewrote the yv12 horizontal resizer for 64-bit, even with 15 GPRs at my disposal I found it very challenging to equal the performance of the x86 softwire routine.

VS 2005 handles intrinsics pretty well, when I've used them they've given me exactly what I'd expect. But they still look horrible and debugging them using a debug build is, well, ridiculous since everything goes through mm0/xmm0. It's a lot simpler to make a release build with symbols and debug that instead.

[IanB]

@Richard, Yes I think you have hit the nail on the head ;)

Intrinsics suck! Prac 101 on how to be as compilcated as assembler but only have 0.5 the functionality. Typing for intrinsics is strong, but I want to abuse the addressing and registers for a strong hit.

@Manao, I think you miss my point. I am not saying using a good macro assember is hard or harder. My point is one of convienience (and some slackness ;) ) inline __asm in VS is addictive, a bit like the sugar McDonalds put in their buns. The choice point becomes a slow C++ routine or a Manao?/IanB/Shodan/... inline __asm special.

As for 64 bit versions of assembly routines, you probably can directly port the 32 bit version and easily, but the temptation is to use all the extra registers and SSE3 instructions to go even faster (or less slowly ;) ).

@Squid, yes the softwire routines have a distinct advantage in that they are explicitly customized for each individual resize operation. [ebx+offset] is slightly faster than [ebx+esi+offset] and it frees the address ALU pipe up earlier for more work.

[trbarry]

All my stuff is done in inline asm. I'd be very annoyed to have to give it up. :(

- Tom

[IanB]

@trbarry, be annoyed, be very annoyed!:angry:




:DBe afraid, be very afraid!

[Fizick]

I fixed convert_a.asm for masm8 compatibility
(movd DWORD PTR [addr])

[DocAliG]

Hi Fizick,
can you make this masm8 compatible file available ? That would be great :)...
We are fighting to make avisynth compiling with VC2005...

Thanks !! :D :D

[Fizick]

it is at avisynth CVS (in 2.6 branch)
:)

[Wilbert]

@Sh0dan,

I got a problem when compiling TCPDeliver (tcpsource.cpp) with VC6:

F:\CompilingPlugins\avs_v26\avisynth\src\plugins\TCPDeliver\TCPServer.cpp(284) : error C2065: 'sprintf_s' : undeclared identifier
Error executing cl.exe.

I guess it must be something VC8 specific, since the corresponding AviSynth v2.5 version hasn't got that command.

[sh0dan]

Yes - I've added a server GUI to the 2.6 version.

I've changed the two places it's used, but have no VC6 to test on.

I'm not converting SoundOut, since setting up the build env for this one took ages. I also managed to get it to link the runtime library static, which so far has failed me on AviSynth.

[IanB]

_snprintf

[xxthink]

Would someone like to give me some advice on how to compile avisynth with vs 2005 express? when I compile avisynth 2.6, it always complains that nasmw.exe is not found

[xxthink]

http://www.mediafire.com/myfiles.php
user name : zhihang.wang@gmail.com
pwd: 123456

You can login in this site to view my build.log . There are so many errors.:confused:

[xxthink]

@henryho_hk: No. They are all there.

btw, a VC2005 Express solution is now included in CVS.


But I can't compile it directly with this sln file by VC2005 Express. I have installed DirectX sdk , the windows sdk and nasm compiler.