§ ¶VirtualDub 1.10.2 released
Version 1.10.2 is now up on SourceForge, and adds a couple of features while fixing a number of regressions. One of the new features is that you can now relocate the program-relative files, like the job list and the crash dump location, to the user profile. Part of the reason I hadn't done this previously is that I've actually never released a version of VirtualDub that installed into Program Files -- it's always been a portable .zip release. Problem is, other people packaged it into installers that did a system-level installation instead of a user-local installation, or worse, users themselves copied it into Program Files. VirtualDub now supports operating in both modes and there are both UI and registry-level ways to switch to the user profile.
There are also a number of fixes in this release for filter issues that were introduced in 1.10.1. This was due to a big push I made in that version to hoist all internal filters up to current specs. Some of the filters in VirtualDub date back up to ten years, and you could tell by the source code in previous versions which filters were older because they were written procedurally, relied on assembly language routines with no C fallback, or just had generally nasty UI dialog code. I ended up rewriting a number of these filters either to enable them on x64 or to allow them to run on the latest filter API (unlike external filters, all internal filters are always on the latest API version, which caused problems). I unfortunately missed a few conversion problems in 1.10.1 which caused a few of the filters to break; these should now be fixed in 1.10.2.
A note on building the program: it can be a bit tricky to build VirtualDub due to the build configuration you need, and because there are some old docs on this website that I need to clean up (there's never enough time). Part of the problem is that I still use Visual Studio 2005 and a fairly old set of SDKs to build, because there are many backwards compatibility problems introduced by using newer compilers or SDKs. Long story short, the most likely build configuration change that people will try is to use VS2010, and if you try that, you will have more success with 1.10.x than with 1.9.x. The reason is that there are a ton of bugs in the VS8/9 project converter in VS2010 and the 1.10.x branch contains some mitigations for those problems.
Change log after the jump.
Build 34807 (1.10.2, experimental): [June 3, 2012]
* Added option and /[no]useprofile switch to store configuration files
under the user profile.
* Added option for fully buffered write I/O.
* PluginAPI: The preferred fccHandler supplied by input plugins is now also
passed through to output files.
* Decoders: Relaxed size restrictions on MJPEG decoder since a more
flexible conversion blitter is now being used.
* The priority of the ASF pseudo-handler has been reduced to allow plugins
to handle the format.
* Fixed .exe manifest embedding error.
* "Export raw video" command now saves properly in job scripts.
* Fixed inversion when reading TARGA images (regression from 1.10.1).
* Fixed bug that caused occasional truncated audio when writing segmented
* ExtEnc: Fixed omitted parameters and occasional extra commas when
* Filters: Fixed artifacts in 2:1 filters in 64-bit build.
* Filters: Fixed logic errors in HSV adjust and emboss filters.
* Filters: Lowered GPU priority in D3D9Ex acceleration mode to improve
* Filters: Restored missing perspective filter.
* Filters: Fixed chroma smoother filter.
* HexViewer: Fixed incorrect text label for fccHandler stream field.
* Capture: Added timeout check for screen capture driver to avoid locking
up program totally when capture load is too high.
> or worse, users themselves copied it into Program Files
Worse how? That's where programs *go*. Of course we're going to copy it there. I don't want random programs installed in weird places.
Glenn Maynard - 08 06 12 - 07:44
Program Files is where installers are supposed to *install* files. As far as I know, regular users by default don't have rights to mess with files there, installers have elevated rights and are supposed to do it.
So because of possible issues with users rights/permissions it doesn't make sense to me to copy manually something there. I usually create a folder titled "Programs" and "install" stuff there.
marius - 10 06 12 - 05:15
Phearon you are right.
I created several folders where I "install" (unzip) software manually.
I even temporarily install different versions of JDK and JRE, copy the files into one of the manual install folders, then uninstall again.
The windows concept of installing software sucks.
Have got 3 pages of entries in Start Menu/Programs, and nearly 200 folders in "Program Files".
Most of them using the company name. Who the hell knows the company name?
They tried to solve this problem in Windows 7, but I will move to linux, not Win7.
JPT - 10 06 12 - 23:18
> Have got 3 pages of entries in Start Menu/Programs, and nearly 200 folders in "Program Files".
> Most of them using the company name. Who the hell knows the company name?
... Then you should specify the folder name you want the installers to use instead of complaining afterwards.
Also, nothing prevents you from having start menu shortcuts organised by relevant, manually created category folders.
Don't blame the tool when you're not using it right.
ParkerLewis - 14 06 12 - 05:42
It would be nice if VirtualDub had an option to preallocate estimated file size on disk at least in case of writing multi-gigabyte uncompressed avi or any other constant-bitrate files, using instant SetValidFileData function, because currently those large files have hundreds or thousands fragments which considerably slows down their processing due to an unneeded extra disk load.
wOxxOm - 14 06 12 - 20:52
I always copy portable applications into "Program Files" or "Program Files (x86)" (for 32- or 64-bit distinction) and made a short cut/quick launch depending on how frequently I use it - and never ran into any problem.
Why would I need a separate "Programs"-folder for that, just to split it up even further...?
Atez - 14 06 12 - 20:53
"Why would I need a separate "Programs"-folder for that, just to split it up even further...?"
Because like I said, for one thing the "Program Files" folders are a bit "special", they have different rights compared to a folder you create by yourself.
And second, though it may no longer apply so much nowadays, I still happen to stumble upon software that has issues with spaces in the folder names (or other unicode characters). If not in the software itself, often it happens that they generate queue files, batches, scripts in which they don't write the path properly if there's a space involved.
It's just much easier for me to save myself the testing time and worrying by just avoiding to use "program files" which has spaces in it, and I just use "Programs".
It's sort of one of the minor motivations for why Microsoft reverted back to "Users" from "Documents and Settings" (though a major reason was to shrink the whole path down, as file paths were getting close to the 257 or so character limit and some apps were crashing or experienced bugs)
That's just how I learned by myself, I couldn't tell you now where I read in MSDN or in some Microsoft guides, that in Program Files only installers that have elevated rights should install applications.
marius - 17 06 12 - 04:20
I've gotten in the habit of creating a C:\bin folder. I put all of my portable applications in there. (including VirtualDub) I then created a reg file that registers any files types for said applications. New install, copy bin, merge reg, all my programs are ready to go. A lot easier than installing each manually. Although it wouldn't be as necessary if I didn't rebuild my PC a couple times a year. :)
If I copied all of these files into the Program Files folder, then fishing them out from the installed applications when rebuilding or setting up a new PC would be much more difficult. Keeping them organized in one folder makes them more portable. Which is kind of the idea.
Billy - 19 06 12 - 06:21
May I be so bold as to request a command line switch to specify opening via DirectShow drivers?
Paddy - 22 06 12 - 00:50
@Glenn Maynard , marius
I don't give a damn about where YOU want to install programs.
*I* Want to install them OFF the Windows Partition - it makes no sense to install everything there. Portable programs is what makes sense.
So hurray for Avery Lee!
And many cheers for still finding time even if you have left College :)
Pete - 29 07 12 - 12:26
But what's the default for /[no]useprofile?
LWC - 10 08 12 - 20:04