Developing a new media player

[Lord Darius]

Some people are starting to talk about developing their own media player for the Windows platform, so I thought it would be interesting to share our views about the design guidelines of such an ambitious project.

First of all, the choice of the language...
What would be the best ? C, C++, .NET, Assembler, D ?

As discussed there (http://forums.winamp.com/showthread.php?s=&postid=1524524#post1524524) I'd tend to develop in C/C++, for a good deal of control over the code, speed, and features of the language.
(When I say C/C++, we can understand a subset of C++ using features like classes, inheritance, but no templates, STL and other exotic features like functors, operator overloading..., my preference going to the use of good old C routines for low level tasks).

What are you, fellow developers, thinking about it ?

[shaneh]

Well C/C++ is the logical choice for the actual decoder and other heavy IO stuff. But there are advantages in mixing this with a .NET frontend, especially if you are targetting a couple years from now, where Longhorn would be heavily .NET based, and all the runtime stuff would already be loaded so another .NET app wouldnt cause much overhead. In fact, it may even cause less overhead, as all the GUI etc and libraries would be shared in memory amongst other apps.

.NET offers a lot of advantages, and if Longhorn ever makes the light of day, will be what a lot of apps are developed in in the future. For example doing that 'ActiveWinamp' plugin would practically be automatic under a .NET app, just by setting a few flags.

People would like making plugins with this player too, as thats what all the kids are learning these days. Plus .NET allows for easier plugin extensions like this without dll and wndproc hacks etc, and you obvioulsy have your choice of language to develop plugins. A bit like what my ActiveWinamp plugin allows.

Using .NET means youd have the advantages of what that platform would make available in the future. eg. imagine the player having a skin which sits in the stupid taskbar thing on the side of longhorn. I dunno much about longhorn, but I suspect that would be easier to accomplish with a .net app.

And where is a decent .NET media player? If theres room for a media player, thats where it is. Why re-invent another C/C++ meida player when there is so many already.

That said, I wouldnt use a .NET player :P... but maybe in a couple years when everything will be .NET.

[CraigF]

Originally posted by shaneh
And where is a decent .NET media player? If theres room for a media player, thats where it is. Why re-invent another C/C++ meida player when there is so many already.

as someone pointed out in the other thread, the consumer doesnt care about the language its written in (aside from peoples hate of .net right now due to the 26mb required download and the slow startup as the jit compiler kicks in), thus, there isnt really a "room" that is language specific.

[shaneh]

Well from a development persepective there is a "room" for .NET Id say. .NET allows you to wire your apps together a bit like COM, and run in sandboxes, embed in other applications and documentes etc.

In the future Id suspect people would start to expect these sorts of features from apps as standard.

For example the 'dock-side-bar' thing I mentioned, you could write an extension in .net that allows you to basically just drag the .dll onto the dock. If the .NET app exposed a 'docking' interface or whatever, it would just all happen automagically. Im not saying this is necessarily the case, but just an example.

EDIT: Its also worth pointing out that .NET isnt really a 'language', its a runtime environment. Almost like a mini OS running within an OS. So theres 'room' for a .NET player, just like theres 'room' for a Linux player, or Java player or whatever. It would also let you port to Linux, handhelds etc quite easily.

And while people dont want to download the runtime now, in 2 years time, any half decent machine will probably have it installed.

[Lord Darius]

I'm not ready yet to make a step towards .NET
As you say, it's a runtime environment, a virtual machine, built upon COM, which I don't like much anyways...
Not that COM is a bad idea, just the opposite, but there are some oddities that are just scary. (I once read a book about developing with COM and ATL, hoping to better understand all of it, and I ended up closing the book with disgust because of all the "patching" needed in the source code to make things work ok.)
Btw, I don't see the point of relying in a heavy runtime like .NET while some compilers will soon be able to directly embed all the services needed for native executables like automated memory management.
As an example, I can talk about the D language ( http://www.digitalmars.com/d/ ) that aims to be the successor of C++, by producing small and fast programs with integrated garbage collection and has advanced features comparable to C#.

And while we're talking about high-level runtime, what about languages like Python that are fairly fast, portable, and come with a lot of built-in modules and services, and start being widely used ?
(for instance, a lot of parts of Fedora Linux are written in Python, even the OS installer !)

[herd]

Why start a new project? There is already an open source player where you could join: Foobar2000. They are using VC++6 - no dotNet - and have no usage for ATL/COM altogether.
A player should consume the least possible amount of memory and CPU cycles - "fairly fast" can't be fast enough. As long as there are no device drivers written in Python, media players in 100% Python will remain unlikely.

[gaekwad2]

foobar2000's core isn't open source.

But it is very modular so you could write a more polished and newbie friendly UI for it (and even include a volume slider :p).