|
|
| mil_alex |
| Posted: Nov 4 2002, 02:31 PM |
 |
|
Unregistered
|
Unfortunately, Microsoft Visual C++ compiler is not a free nor open source neither GPLed software. To rebuild VirtualDub you must buy it, Ok?
A few days ago I tried to compile one of Donald Graft filters using Borland free command line tools (AKA BC++ 5.5, nearly the same as one found in Borland C++ Builder 5 and newer) and it failed to run (I mean, my filter + VDub). Funny but W98 went to a black screen (not even BSOD) and neither of VD exception handler or standard Windows handler popped its window up. I have traced the problem down and I found that Avery used very uncommon MS VC++ extension: IFilterPreview member functions with fastcall modifier, not a standard stack based C or Pascal calling conventions. This results in impossible to use preview feature in your filters unless you're using Microsoft C++ to develop filters.
Is Avery Lee some way affiliated with Redmond? What the other development tools do you suggest?
|
|
| Stefan |
| Posted: Nov 4 2002, 04:10 PM |
|
|
Advanced Member
Group: Vdubmod Alpha Testing Team
Posts: 215
Member No.: 142
Joined: 27-August 02
|
Had same question some time ago...
Migration from one compiler to another is not an easy task and the task is complicated when you use many M$ DDK / SDK files.
VC++ 6 is a nice development environment. Source code debugging is easy and you can use MSDN information... There is a nice integration of all tools. But you are right the package is rather expensive.
Then i found and bought a book with an authoring edition / version of VC++ 6. This version is limited in some ways, but can be used for the compliation of VD. Man, it was cool to produce the first personal version of VD ;-) Main limitations are one nagscreen at startup in compiled programs, no licence to sell compiled programs and less code optimization. Nothing of big importance in a GPL project when you give away source either.
I got the taste (VD and VC++) and currenty i am looking for a second-hand version of VC++ at EBay.
Stefan
|
|
| mil_alex |
| Posted: Nov 4 2002, 08:48 PM |
|
|
Unregistered
|
Thanks for tips, Stefan. Maybe someday I'll try one...
Actually, I worked around it (BC++ vs. VD incompatibility) by number of ways.
- I have used __msfastcall modifier (this is BC++ feature) to member functions prototypes given in filter.h (VD filters SDK) to have this-> to be passed through ECX (the way it is expected on VirtualDub' side), instead of EAX (for "conventional" fastcall method).
- unfortunately Borland tries to pass the rest of arguments via EDX... etc. while VirtualDub expects them on stack (like C calling method) - it's the bomb mix 
- ok, I asked BC++ to write out assembly source code for me ( -S option). Then I have "PUSH-ed" any passed extra argument except this-> to reach this "super compliance"... Really annoying.
- finally, I made a very tiny wrapper library to pass required calls to IFilterPreview member functions through. I'm sure it is still ugly way, but it works. It is just curious to see whether the Virtual Dub can be compiled with gcc or lcc.
On the other hand, thanks God we did not need any performance critical job near this bottleneck, otherwise these "wrapped" calls would cost too much. |
|
| Neo Neko |
| Posted: Nov 4 2002, 08:59 PM |
|
|
VirtualdubMod Alpha tester
Group: Vdubmod Alpha Testing Team
Posts: 474
Member No.: 24
Joined: 11-July 02
|
Avery has mentioned in the past on his news page he would like to have Virtualdub for Linux. The first step in this would seem to be stepping away from MS specific coding. But this could be a hard task indeed. I am sure he would be open to input/help on the matter. We don't always have time to do what we wish to do. |
|
| mil_alex |
| Posted: Nov 4 2002, 09:21 PM |
|
|
Unregistered
|
This time I have no desire to port VD to Linux. The reason is that in addition to tweaking caused by compiler change there will be critical lack of MS VfW API (aka Video for Windows). This can't be just "worked around". Or this will be not Virtual Dub anymore...
The other real problem is that if someone recompile VD using as little MS VC specific features as possible, (including plain vanilla C calling conventions for class member functions), then all current external filters will be rendered to trash. They will require a recompile with the same VC options, or with third party compilers. Neither is easy.
On the other hand, current dependence of VC++ code generation reduces the chances to anyone to build new filters for Virtual Dub. |
|
| phaeron |
| Posted: Nov 5 2002, 04:08 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Erm...
IFilterPreview methods are not called with __fastcall. They are called with the implicit "thiscall" calling convention:
* 'this' is passed in ECX.
* All parameters pushed on the stack.
* Called function pops parameters.
__fastcall will not work for methods that have parameters since __fastcall pushes the second parameter in EDX instead of on the stack. A compiler that does not support the implicit 'thiscall' calling convention properly cannot be called a Windows C++ compiler since it isn't ABI compatible and won't work with some core Win32 libraries, such as D3DX. Note that VirtualDub's headers assume a __cdecl default calling convention, so compiling your filter with __stdcall or __fastcall as the default will likely result in runtime errors or stack leaks.
Like it or not, Visual C++ is the primary compiler on the Windows platform. I resent your implication that my coding style is indicative of a covert agreement with Microsoft -- if I really wanted to screw people over I would have already switched to Visual Studio .NET and the CLR.
|
|
| mil_alex |
| Posted: Nov 5 2002, 06:44 AM |
|
|
Unregistered
|
Thanks for your reply.
When I saw the member proto's in filter.h (SDK) I had no idea about the used calling conventions. It looks like some global settings for entire project make VC to compile this code the way it does it. Probably some remarks regarding calling conventions would be useful in there.
BTW, it is rather bad idea to have third parties to call members of your classes, unless you both have the same development environment for sure. The problem would never occur if you used plain pointers to cdecl functions instead of building a class. This wouldn't add any run-time penalties too (I mean, performance etc.)
We both know that Microsoft would like to call only one true Windows C++ compiler:( and it wouldn't be Borland. You always can invoke D3DX and other API from assembly language (including TASM 5.3 for example) wrapper libraries, even made for BC++, so this isn't very important. Just a sad thing.
Me personally, I dislike MS VC++ to be a primary compiler due to low robustness of code generation. Yes it is often a fastest code (vs. Watcom and Borland) but you anyway used assembly  so why bother about the best possible C-compiled code...
Consider my post about your relations to MS as a rough joke. In fact, I do not think you would move to .NET unless there were no performance decreases. We all respect the video processing speed and currently it would be low if using .NET. On the other hand I'd like to get your attention to the coding style importance and I think I succeed with this
Thanks. |
|
| fccHandler |
| Posted: Nov 5 2002, 08:06 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
Do I smell a flame war brewing? mil_alex vs. Avery Lee! Get your tickets here, folks!
Relax, dudes. VirtualDub is open source, and anyone who doesn't like the "coding style" has a perfect legal right under the GPL license to modify that style, or even rewrite the whole program. For that I think we owe Avery Lee our eternal gratitude.
--------------------
May the FOURCC be with you... |
|
| mil_alex |
| Posted: Nov 5 2002, 08:34 AM |
|
|
Unregistered
|
Guys, I do not want holy wars 
The real problem is our total work time spent to misc. features. fccHandler - you're right I could make my own build that works for me. You too. Also Avery can have his own build. Each time you will do something already made by others again. There shouldn't be many incompatible Virtual Dub copies at the same time, or we seem to spread forces on the wind.
Sorry if I was offending. |
|
| Stefan |
| Posted: Nov 5 2002, 01:24 PM |
|
|
Advanced Member
Group: Vdubmod Alpha Testing Team
Posts: 215
Member No.: 142
Joined: 27-August 02
|
@ mil_alex
Perhaps these URLs are useful for VD developers with Borland C++:
Creating DLLs in BCB that can be used from Visual C++
DirectX 8 Borland LIBs
Stefan |
|
| phaeron |
| Posted: Nov 6 2002, 03:32 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
You are no safer calling a standard cdecl function than you are calling a class method -- either way you are subject to problems if the ABI for your platform changes. As it turns out, the C++ API for calling pure virtual methods without inheritance is very stable on Windows. If it were not, everyone writing COM objects would be in trouble.
Trust me when I say that binary compatibility is not an issue; in the worst case it would be trivial to write the necessary assembly stubs to marshal parameters across an ABI change.
|
|
| mil_alex |
| Posted: Nov 8 2002, 06:24 AM |
|
|
Unregistered
|
Sorry for no quick reply, I'm not every day on-line.
Stefan, I wish I knew these links before I started writing; these are "must read" ones. Though, they "cheat" a little, they do not trick around the all possible calling conventions but cdecl and stdcall. Anyway, very good explained.
Avery, I agree it's easy to make stub/wrapper once and forget about it.
BTW, the stability of COM code is probably high due to nobody uses development tools other than MS VC++ for object creation  .
Regarding fn call vs. class method call safety, please remember that we should pass a pointer to self when class member fn is called. This adds some inconvenience if calling conventions are unknown or differrent. |
|
