Comment by jbk | Hacker News Reader

Comment by jbk | Hacker News Reader

Parent Full thread

Well, no, this is not too much.

This is an excellent question.

Designing a UI above VLC for Metro is quite easy, and we've already done some proof of concept. Finding a designer would be simple and 1k$ for the project would be too much already :) It would take a couple of months and be done with it.

The issue is to get on the store. And this is hard.

Why is that?

VLC (and its underlying libraries, including codecs, networking and demuxers) represents around 7M LoC of C, C++ and ASM. All of this is very C99 code and inline ASM. Visual Studio cannot eat that in any way. Believe me, we tried. A lot. So we need to compile the VLC for Windows on Linux, using gcc+mingw.

Unfortunately, this does not work on WinRT ("Modern UI" or whatever you like to call it). WinRT restricts a lot the Win32 APIs. And only Visual Studio knows which ones. Oh, and the BSD sockets are gone...

So, we need to change and update the toolchain, fix MingW for WinRT, rewrite the code that is using Win32 APIs since 10 years (and in all underlying libraries too...), write a new UI above this, fix the code using HWND for rendering, port the audio and video outputs, work-around the sandbox for DVD playback, probably write a WinSock2 replacement library to build all the cross-platform libraries that expect a BSD-socket-like library, etc...

Add to that the need to modify MingW to output dlls that we can load on ARM (Windows RT) and fix all the same different APIs for WP8.

Of course a lot of the work is not really on VLC, but on being able to compile for WinRT with open source tools, and a lot will be re-usable.

So, yes, we will need quite a few developers, and therefore money.

It sounds like it's going to be a real challenge, then. Much of the restriction around API usage is related to IO and other things that can block for more than about 50ms. As you know, the APIs that are allowable have been converted to be asynchronous, or have been replaced entirely with an async equivalent (more or less). This will make it difficult to just link with a gcc lib unless it's been purged of these references. In addition, there are no database APIs, for example. So it's really a crap shoot about how much difficulty a given project will take to port.

Async comm is relatively easy to deal with in the context of media players than it is in other applications because in media players there is a fairly direct flow of information from a file or a network connection to the video and sound subsystems.

If you're building the kind of app I was building a few years ago, such as semantic graph editors, where a change in one UI element might have effects that propagate to other UI elements in an uncontrolled way, then, yes, the async comm in Windows 8 (the same problem that exists in Javascript, Flex and Silverlight) requires you to have a systematic approach to how information gets into the app.

(One thing I'd definitely note is that the Windows 8 apps like "Photos" and "Mail" are really a joke when you compare them to the Windows 7 era "Windows Live Essentials", which are really competitive -- Windows Live Essentials can handle mail spools on my crappy 2GB shojou netbook that destroy Thunderbird on a 32GB machine. My experience is that async I/O sets an upper limit on the complexity of what you can do)

VLC will have the option of bending their UI to be something that fits the Metro mold easily, so async I/O and comm should not be such a big deal.

You make a good point about the linear flow that's typical in media players. I haven't looked at the VLC source, so I'm not sure about how it's structured. With 7M LOC, I'm guessing that there might be some entanglements. The async model causes the async pattern to propagate all the way up the call chain. The I/O and other async dependencies would have to be decoupled from the gcc library to minimize impact on the existing code base.

The asynchronicity stuff has made it into many a presentation, but it's not really about that. If it were all about async maybe someone can tell me why they're not allowing I/O completion ports and APCs. It's about not trusting developers, and rooted in an overreaction to the perceived problems in the existing Win32 ecosystem. You can do async I/O with Win32 just fine, but Microsoft now believes you're too stupid to do it.

Also, there is a port of sqlite to WinRT.

You're right, that's not the only issue. The "Windows Store" apps are limited to a specific subset of what we're accustomed to coming from Win32 and COM. Much of this is designed to sandbox applications.

So there's a new API and the new API is async all the way through. The async aspect gets a lot of attention because it's so pervasive, and can require some adapting. But you're right, the limited API can have a larger impact on a porting effort.

BTW, my point about no database API is in reference to the lack of System.Data (ADO.NET). The assumption is that people are expected to consume data through Web services. It's great that SQLite supports WinRT, though. That definitely fills a big need.

> It sounds like it's going to be a real challenge, then.

Yes

> In addition, there are no database APIs, for example. So it's really a crap shoot about how much difficulty a given project will take to port.

We will do the database APIs, in fact :)

Wow. Sounds like anyone who's ever made Windows software and wants to port it to Windows 8 store is going to have to go through a lot of pain.

If it's not very computationally intensive program, using javascript/html is starting to make a lot more sense

Agreed. But multimedia is computationally intensive program.

Do you think VLC will be the better for it?

Considering Microsoft's actions with Windows 8 for ARM (Win RT), the classic desktop is probably going to be depreciated in the future. This kind of work needs to be performed at some point, and being allowed in the Windows Store is also a very nice payoff. I don't know how much work would be required for Windows 8 ARM support for VLC, but this work definitely gets it closer (knowing your UI will work is a good motivation to get the backend sorted).

And knowing Microsoft's track record with new APIs (cough Silverlight cough WPF cough COM cough), WinRT should be deprecated in, what, 5 years?

Reply on news.ycombinator.com