|
|
| david.horman |
| Posted: Nov 17 2009, 04:07 PM |
 |
|
Member
Group: Members
Posts: 15
Member No.: 26332
Joined: 18-October 09
|
I was a little trepidatious at the thought of trying to compile my own build of VirtualDub, but I really need to make a tiny tweak to the source code.
After a bit of struggling (not helped by a hopelessly out-of-date page at Virtualdub's site which led me to install VC 6!), and a bit of help from old posts in this forum, I've just successfully compiled VirtualDub for the first time, and thought I'd post my notes in case they were of any use. Hopefully it isn't relying on something that I installed a while ago and forgot about...
1. (already installed) Visual C++ 2008 Express Edition
2. Installed the lastest Windows SDK from http://www.microsoft.com/downloads/details...&displaylang=en
3. Installed the latest DirectX SDK from http://www.microsoft.com/downloads/details...splaylang=en#dx
4. Downloaded and extracted the Vdub 1.9.7 source, and took off the Read only attribute on all files
5. Opening the .sln file prompts VC++ 2008 to convert the file from 2005 format. It will ask if you want to "permanently remove the source control bindings from the projects" - I said Yes.
6. Added the DX include folder (C:\Program Files (x86)\Microsoft DirectX SDK (August 2009)\Include on my system) to VC's "Include files" directory (Tools->Options->Projects and Solutions->VC++ Directories)
7. Added the DX lib folder (C:\Program Files (x86)\Microsoft DirectX SDK (August 2009)\Lib\x86 on my system) to VC's "Library files" directory (as above)
8. Swapped a single use of "MIIM_FTYPE" in src\system\source\w32assist.cpp to the integer value "0x100" - this may not be the best way to fix it, but I was going for simplicity.
9. Copied the dummy dxtrans.h file from http://www.riseoftheants.com/mmx/mjpeg.zip into DirectX's Include folder above - apparently it's been missing from the DX SDK for some time.
10. Downloaded yasm from http://www.tortall.net/projects/yasm/ and put it in C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin (renamed to yasm.exe)
And that was it - I haven't tested it extensively, but the build is working fine so far.
Please let me know if I've done anything wrong or stupidly.
David |
|
| TCmullet |
| Posted: Feb 5 2010, 02:43 PM |
|
|
Advanced Member
Group: Members
Posts: 312
Member No.: 3970
Joined: 2-May 03
|
Maybe this thread should be pinned. I, too, suspect I need to tweak (or at least look at) Vdub source. I'm using VS2008 Standard, and it barfed on all those read-only .vcproj files. (Phaeron, isn't it a "bug" to send out source code with read-only files?)
I'm not sure how far I'll get with this:
1. I'm NOT crazy about modifying Vdub for my need. I'm trying to modify Delogo 1.3.2 for *everyone's* needs.
2. I'm more inclined to compromise my design goals than to make a custom Vdub.
3. I'm more concerned (for now) with getting something working for my own backlog of videos that I want to process with my customized Delogo.
I found this short thread by looking for "read and only" (as in read-only), I think. I'm slightly disappointed I have to add some big programs to my system that will never be used except for this Vdub mod that will probably not happen (I just reinstalled Windows XP before installing VS2008 Standard), but I will get over it (assuming no problems when installing or *briefly* learning what I have to do with them to get on with diving into Vdub source itself).
Thank you David for posting this. |
|
| dloneranger |
| Posted: Feb 5 2010, 08:43 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
Thanks for the walkthrough
Installing VS and all the required bits was the only thing putting me off modifying/recompiling virtualdub
That, and never having used c++ before (ye gods, it's foul - I think I'll stick with my rad environment for all but this one thing)
From a blank VM it took about 40 minutes to turn out my first vdub modification :-)
Nothing fancy, just a one line change in clippingcontrol.cpp to show the width&7 and height&7
(can't count how many times I've come back to a 'source is not acceptable.....' error due to an odd width/height)
-----
Though, for some reason, vs2008 express seems to like deleting Changes.bin and rel_notes.bin in \src\VirtualDub\res
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| phaeron |
| Posted: Feb 6 2010, 03:59 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Yeah, it's a pain to get a VirtualDub dev environment setup, but welcome to serious Windows application development. Believe me, it gets much, MUCH worse in commercial development. You can thank Microsoft for constantly making SDKs incompatible and changing the project format with every damn version of Visual C++.
And, as a reminder, the official compiler for current versions of VirtualDub is Visual Studio 2005. I won't be upgrading to VS2008 due to system requirements (VS2008 cannot build executables that run on Win98) and because I won't pay for such an incremental update (I use some features that are only present in Professional edition).
| QUOTE |
Phaeron, isn't it a "bug" to send out source code with read-only files?
|
I'm assuming that if you are modifying source code that it's not a big deal to remove some read only flags, or for that matter, source code control bindings. The files are read only because that's how my source code control system marks them when checked in and I don't know of an easy way to tell 'zip' not to include that information.
|
|
| levicki |
| Posted: Feb 6 2010, 06:55 PM |
|
|
Advanced Member
Group: Members
Posts: 167
Member No.: 22605
Joined: 13-December 07
|
| QUOTE (phaeron @ Feb 6 2010, 04:59 AM) | I won't be upgrading to VS2008 due to system requirements (VS2008 cannot build executables that run on Win98)...
|
Avery, are you sure about that?
After all, the output is a standard PE executable, why wouldn't it run on Windows 98?
You probably just need to override version info in executable header (say from 5.01 to 4.00 or something). If I remember correctly, there is /SUBSYSTEM:WINDOWS,x.yz linker option and also /VERSION:x.y, one of them should do the trick.
Regarding read-only attributes, if you are using Info-ZIP or 7-Zip there is no way. If you use command line RAR, then you can use ai option (ignore attributes), note that you can compress to ZIP using RAR. Another option is to copy source tree to a temp folder and run attrib -R /S on it before packing.
|
|
| phaeron |
| Posted: Feb 6 2010, 07:46 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
| QUOTE | | After all, the output is a standard PE executable, why wouldn't it run on Windows 98? |
Because it calls APIs that don't exist on Windows 98.
Microsoft has been increasingly using APIs in the C runtime libraries that don't exist on downlevel systems. Apparently, in some cases, GetSystemWindowsDirectory() will show up. There are various hacks you can do to get around the problems, but they're risky and annoying.
|
|
| TCmullet |
| Posted: Feb 6 2010, 09:44 PM |
|
|
Advanced Member
Group: Members
Posts: 312
Member No.: 3970
Joined: 2-May 03
|
| QUOTE (phaeron @ Feb 5 2010, 10:59 PM) | | QUOTE |
Phaeron, isn't it a "bug" to send out source code with read-only files?
|
I'm assuming that if you are modifying source code that it's not a big deal to remove some read only flags, or for that matter, source code control bindings. The files are read only because that's how my source code control system marks them when checked in and I don't know of an easy way to tell 'zip' not to include that information. |
I did figure out that I needed to go to WE (Windows Explorer) and change the property of all files in the right folder tree to read-write. But I was a little scared to as the question "why would he make them read-only" was burning on my mind. I stepped forward realizing if it screwed up something, I could re-extract the stuff.
"Source code control system" sounds like Visual Source Safe. I haven't used it, but I know shops that do. I guess it might make sense to mark files r-o somewhere in the version security process.
It did freak me out a bit when some sub-projects couldn't be VS2008 converted due to the r-o files. But after I fixed the properties, rerunning the converter caught the right subprojects. |
|
| TCmullet |
| Posted: Feb 7 2010, 03:47 AM |
|
|
Advanced Member
Group: Members
Posts: 312
Member No.: 3970
Joined: 2-May 03
|
| QUOTE (phaeron @ Feb 6 2010, 02:46 PM) | | QUOTE | | After all, the output is a standard PE executable, why wouldn't it run on Windows 98? |
Because it calls APIs that don't exist on Windows 98.
Microsoft has been increasingly using APIs in the C runtime libraries that don't exist on downlevel systems. Apparently, in some cases, GetSystemWindowsDirectory() will show up. There are various hacks you can do to get around the problems, but they're risky and annoying. |
I must say I'm rather stunned that MS would do this BS (but perhaps I shouldn't be). I'd want to see what "improvements" MS made to the C runtime libraries that were based on adding new APIs to pass more than tentative judgement. But while it's fine to upgrade a development language/environment, for a compiler to create object code (via referencing those libs) that won't run on somewhat earlier operating systems is shear insanity. What were they THINKING??
In a parallel issue, I refer to what I went thru in my Summer '09 Web Programming course (XHTML/CSS). We were required to have our projects, not only validate to XHTML 1.1 (w/rare exceptions), but we had to verify it ran under 4 certain current browsers. HOWEVER, while we had to use IE at least v.7, we were ENCOURAGED to attempt to have them degrade gracefully under older browsers. In one comm. with the prof., he told me some folks still access the college websites via IE ****2****!!! I couldn't believe it. Yet, MS doesn't seem to have "backward compatibility" in their vocabulary (as far as runtimes are concerned).
I'm a C neophyte here, but I must say it might be worth it to get those hacks in place at least optionally (if they can be made non-risky). I think MS should work on the real problem, though. Maybe if some exert pressure (via written snail mail - I'll think about this), they might revise "backwards" the C runtime libraries. Nothing wrong with having the Windows APIs there. But unless the new APIs provide functionality that prior versions don't, all they've done is make something useful (Win98) obsolete. (Of course that MAY be what they want.) I just can't imagine anything done by a language runtime library that needs more than what's in Win98. If there is, it should be configurable, even if it means multiple runtimes.
Well, I needed to blow off a bit of steam. After my years long experience of holding onto 98 and FAT32 longer than most, I'm believing that one must sometime migrate forward, even if at a late date. So there probably will come a time when Vdub will need to go to VS '08 or '10 or maybe '14. (I hate it that they can't get a language stable for more than 2 years. More steam.) |
|
| levicki |
| Posted: Feb 9 2010, 08:05 PM |
|
|
Advanced Member
Group: Members
Posts: 167
Member No.: 22605
Joined: 13-December 07
|
| QUOTE (phaeron @ Feb 6 2010, 08:46 PM) | | QUOTE | | After all, the output is a standard PE executable, why wouldn't it run on Windows 98? |
Because it calls APIs that don't exist on Windows 98.
Microsoft has been increasingly using APIs in the C runtime libraries that don't exist on downlevel systems. Apparently, in some cases, GetSystemWindowsDirectory() will show up. There are various hacks you can do to get around the problems, but they're risky and annoying. |
That particular API call resides in crtlib.c in function _check_manifest().
Call to that function is inside of __CRTDLL_INIT() and it is being compiled conditionally upon _CRT_CHECK_MANIFEST macro.
If you are shipping runtime DLLs to Win98 users, then it is most likely a matter of #undef _CRT_CHECK_MANIFEST and compiling your own DLL to distribute for Win98 systems.
|
|
| david.horman |
| Posted: Aug 19 2011, 07:42 PM |
|
|
Member
Group: Members
Posts: 15
Member No.: 26332
Joined: 18-October 09
|
I'm now trying to compile VirtualDub with the latest VC++ 2010 and the latest SDKs, but I've run into a problem I can't understand when trying to build the project "Riza":
| CODE | 1>------ Build started: Project: Riza, Configuration: Release Win32 ------
1> cap_dshow.cpp
1>c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\utility(163): error C2664: '`anonymous-namespace'::VD_MSCOMAutoPtr<T,T_IID>::VD_MSCOMAutoPtr(const `anonymous-namespace'::VD_MSCOMAutoPtr<T,T_IID> &)' : cannot convert parameter 1 from 'int' to 'const `anonymous-namespace'::VD_MSCOMAutoPtr<T,T_IID> &'
1> with
1> [
1> T=IMoniker,
1> T_IID=& _GUID_0000000f_0000_0000_c000_000000000046
1> ]
1> Reason: cannot convert from 'int' to 'const `anonymous-namespace'::VD_MSCOMAutoPtr<T,T_IID>'
1> with
1> [
1> T=IMoniker,
1> T_IID=& _GUID_0000000f_0000_0000_c000_000000000046
1> ]
1> No constructor could take the source type, or constructor overload resolution was ambiguous
1> c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\utility(247) : see reference to function template instantiation 'std::_Pair_base<_Ty1,_Ty2>::_Pair_base<_Ty,VDStringW>(_Other1 &&,_Other2 &&)' being compiled
1> with
1> [
1> _Ty1=`anonymous-namespace'::IMonikerPtr,
1> _Ty2=VDStringW,
1> _Ty=int,
1> _Other1=int,
1> _Other2=VDStringW
1> ]
1> source\cap_dshow.cpp(1635) : see reference to function template instantiation 'std::pair<_Ty1,_Ty2>::pair<int,VDStringW>(_Other1 &&,_Other2 &&)' being compiled
1> with
1> [
1> _Ty1=`anonymous-namespace'::IMonikerPtr,
1> _Ty2=VDStringW,
1> _Other1=int,
1> _Other2=VDStringW
1> ]
========== Build: 0 succeeded, 1 failed, 2 up-to-date, 0 skipped ==========
|
Does anyone have any idea what this means?
In order to get this far, I had to find a copy of qedit.h, as it no longer ships with the DirectX SDK, and also use the dummy dxtrans.h mentioned in the first post.
David |
|
| phaeron |
| Posted: Aug 23 2011, 05:50 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
The next version of VirtualDub is going to have fixes to bypass the annoying qedit.h header problem and compile on the Windows SDK v7.1 out of the box, although it still won't have VS2008/2010 project files.
| QUOTE | | I'm now trying to compile VirtualDub with the latest VC++ 2010 and the latest SDKs, but I've run into a problem I can't understand when trying to build the project "Riza": |
Please indicate which version you are trying to compile when reporting problems. It's hard to match line numbers to source code without this information.
For the cast problem, you need to insert a cast into the initializer expression:
| CODE |
mAudioDevices.push_back(tDeviceVector::value_type((IMoniker *)NULL, VDStringW(fi.achName)));
|
|
|
| david.horman |
| Posted: Aug 23 2011, 06:12 PM |
|
|
Member
Group: Members
Posts: 15
Member No.: 26332
Joined: 18-October 09
|
| QUOTE (phaeron @ Aug 23 2011, 05:50 AM) | | Please indicate which version you are trying to compile when reporting problems. It's hard to match line numbers to source code without this information. |
Oh yeah, sorry, that would have been helpful! :*) I'm compiling from the 1.9.11 (x86) source.
Anyway, thanks phaeron - that cast did the trick. Well, for that bit anyway - VC++ 10 makes compiling VDub a lot more complicated. I had to put src/ in the root of C:\ to get anywhere - some kind of path macro problem? I also had to run all of the "asuka.exe psa" commands myself on the command line, because they all "exited with code 1".
I was going to write some proper notes like the top of the thread, but I think I'll wait until the next version progresses to stable.
By the way, is http://www.virtualdub.org/docs_compiling.html very much out of date?  It says to use Visual C++ 6.0 (and I actually got as far as installing it first time), while the download page suggests Visual Studio 2005.
David |
|
| XL-DJK |
| Posted: May 24 2012, 06:46 AM |
|
|
Newbie
Group: Members
Posts: 1
Member No.: 34928
Joined: 24-May 12
|
@dloneranger
What psa commands are you referring to exactly? I'm trying to compile vdub and I am at this (what I hope) is the last step as it's the only error I have left to resolve |
|
| dloneranger |
| Posted: May 24 2012, 08:07 AM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
It's david.horman that mentions pas
I use VS2008 to compile it with, and don't remember having any problem like that though sorry
As far as I can see it's to do with PSA.rules, a custom build rule
So I'm guessing that he just ran that manually from the cmd prompt
You should be able to work out the params from the compile log, where it fails?
[edit]
The virtualdub project "pixel shader assembler" section shows this generated from the psa.rules file
Output path -> $(ProjectDir)\autogen\
command line -> "..\..\out\Debug\asuka.exe" psa "f:\VSProjects\VirtualDubProjects\Virtualdub\src\VirtualDub\VirtualDub.vcproj" "f:\VSProjects\VirtualDubProjects\Virtualdub\src\VirtualDub\\autogen\\VirtualDub.inl"
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| levicki |
| Posted: May 24 2012, 10:07 PM |
|
|
Advanced Member
Group: Members
Posts: 167
Member No.: 22605
Joined: 13-December 07
|
One thing worth noting when compiling projects with VS2010:
If you use external command-line tools for pre, custom, or post build steps, and if those command line tools return anything else than 0 then the build will fail because MSBuild is checking the return value.
Updating and rebuilding those tools so they return 0 on success is the correct way out of that problem. |
|
|
