Keyword - Windows

Entries feed - Comments feed

Friday, October 3 2014

Second VLC for WinRT release

A new release

Now, you should see a new release of VLC for WinRT on the Windows Store: 0.1.0.

This is the second major release of this application. While still beta, it should be way more stable than the previous one.

The major changes are:

  • using libVLC 2.2.0 core,
  • redesign of the interface,
  • huge performance improvements,
  • use of Winsock for networking instead of WinRTsock,
  • use of Windows 8.1 widgets,
  • move the interface code to Universal to prepare Windows Phone 8.1 port.

To get more stability, the performance improvements and the preparation to port for WP8.1, we had to move the application to Windows 8.1-only.

Be careful, this is still not as perfect and stable as the desktop release.


While this release is still x86-only, we've made great advances on the ARM port. More news soon.



Home.png Home JP


Videos.png VideoList JP

Video playback

plyingvids.png Video JP


MusicAlbumList.png MusicAlbums.png AudioList JP MusicAlbumWithFlyout.png musicAlbumsPlaylist.png Audio JP MusicSongs.png Playing.png


Half_Snap.png Snap.png

Windows 10

Windows 10 windowed


Get it on the Windows Store.

Saturday, March 15 2014

Second build submitted to the store

After the first beta release a couple of days ago, a second build fixing the most important crashes has been submitted to the store, for certification.

It should notably fix the crash on start, on some machines, but other stability issues, on the music side too!

We'd like to thank the new contributors that helped.

It should appear automagically in a few hours on the store.

Next release, next week!

Have a nice week-end!

Monday, March 10 2014

First achievement unlocked!

Oh boy, this has been a long and bumpy ride!

Today, the first Beta of VLC for WinRT is getting deployed on the store.

As many of you know, the road to come to this point has been long... Very long.

I've been driving or helping some ports of VLC on mobile, but this port has been the hardest, by an order of magnitude.

I'll speak a bit more about the lateness of this port, another time. Today, I'll introduce a bit to this application.

Continue reading...

Tuesday, February 12 2013

Technical update on the WinRT port


So, a few weeks have passed, and I have not spoken a lot about the port on WinRT/Metro/Windows RT/WP8.

Of course, some of you will complain, but the main reason for that, is that I've been very busy on VLC :)

So here is what we did :)

VLC engine

The biggest part of the work resides in the port of the VLC engine to a WinRT compatible runtime.

A lot of the work we've done so far has been on that.

More specifically, we have:

  • ported VLC APIs call to UNICODE (wide chars),
  • allowed VLC to be compiled for Windows 8 API targets,
  • upgraded some VLC Win32 API calls,
  • removed some code-path when compiling for WinRT,
  • fixed some issues on mingw-w64 toolchain for Windows 8,
  • prepared a compatibility library,
  • changed our packaging for WinRT,
  • improved our audio output for Windows.

Winstore compatibility library

A lot of work has been and will be on this library, so let me speak a bit more about it.

Instead of ifdef-ing the VLC code everywhere for WinRT, we decided to reimplement the forbidden calls in a library that would expose the same old Win32 functions, but implemented with the allowed APIs.

The biggest advantage of this approach is that you don't need to modify a lot of your common codebase, and that you don't need to hack all the libraries that are linked to VLC. And this would have been a huge task. Moreover, it allows to adapt to newer versions of Windows more easily. Moreover, this library will be usable by every other project.

But as you can imagine, doing that is quite tricky, since we don't modify VLC, we don't modify the headers, but we insert it at link time...

We have done some of the work, but we still have a huge amount of work to do, notably on threads and Winsock reimplementation.

This library is hosted in the mingw-w64 repository and will be my focus for a bit of time.


Above the VLC engine (libVLC), we have a CX/C++ wrapper, in order to expose VLC functions to the application, since libVLC is plain C, and it is compiled in Visual Studio.

Above the wrapper, we have the main application.

This application is written in C#, compiled in Visual Studio, and uses the wrapper in order to access playback functions.

So far, the application has a basic media library, and playback support using VLC engine. The media library UI follows more or less what we've shown in the KickStarter. The player UI wasn't shown, but it looks a bit like the normal Video application, in order to match the official style.

The video, so far, is rendered into a memory buffer from libVLC and then is displayed using Direct2D in a video surface. This is not yet the best method, but it is good enough for now.

What's next

So, what are we going to work on now:

  • the winstore compat library
  • the winstore compat library (threads) ,
  • the winstore compat library (MSVCRT),
  • the interface, in order to match our promises,
  • the audio and video outputs, to go faster.

A lot of the work is going to go faster now that we have done correctly the beginning and a beta as soon as possible for our backers.

Tuesday, December 11 2012

Why we need a KickStarter for VLC on Metro

KickStarter for VLC on Metro

As you might have heard, some developers of the VideoLAN team have started a kickstarter quest to crowdfound a port of VLC on WinRT.

The reason for this kickstarter is that porting VLC to WinRT will be hard and long, if we don't speed it up.

And yet, quite a few people seem to think the task will be simple, like on neowin or Hacker News.

I'm all for funding 40k pounds for VLC (they deserve it), but 40k under the guise of Metro seems a bit much, no?

I dont know but just creating a metro UI shouldn't be that hard should it?

The Windows RT app should be trivial to make... As long as they aren't using Win32 API's, it should just be a matter of recompiling for RT and correcting whatever few bugs they encounter.

Well, no, this is not too much.
We are not the kind of person asking money for nothing, I think we've proven that during all those years.

Let me explain why.

Why we need a KickStarter for VLC on Metro

Designing a UI above VLC, for the "Modern Experience" is quite easy, and we've already done a few proofs 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 we would 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 access or demuxers) represents around 7 Million Lines of Code in C, C++ and ASM languages. And all of this code is following C99 standard and has inline ASM.

Visual Studio cannot eat that code in any way. Believe me, we tried. A lot. So we need to compile the VLC for Windows on Linux, using gcc and 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 the Windows Store knows which ones are allowed.

For example, the BSD sockets are gone... Yes, this is not a joke.
They work on Linux, Windows, Mac, iOS, Solaris, Android, QNX, WP8, WinCE but not WinRT.


So, we need to:

  • change and update our toolchains,
  • fix MingW for WinRT, in the best way we can,
  • link to the newer Windows runtime,
  • list the problematic APIs,
  • rewrite the code that is using Win32 APIs since 10 years (and in all underlying libraries too...),
  • drop some modules or isolate some code,
  • write new replacement code,
  • write a new interface above all this,
  • design the interface correctly,
  • fix the code using windows HWND,
  • port the audio and video outputs,
  • work-around the sandbox for DVD and BluRay playback,
  • probably write a WinSock2 replacement library to build all the cross-platform libraries that expect a BSD-socket-like library,
  • port to ARM,
  • etc...

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


As you can see, a lot of the work is not really on VLC, but on being able to compile for WinRT with open source tools, since Microsoft tools are not enough. And a lot of work will be work-around the limitations of WinRT.

Of course, a lot of the work will be re-usable to other projects.

So, yes, we will need quite a few developers to do all that. We can do the Android route, and it might take a couple of years to get it there, or we can try to get some money to speed it up...

Thursday, November 22 2012

Windows Store and the GPL

FOSS and AppStore

As more and more software distribution are going through so-called App Stores, the question about the compatibility of their terms and conditions with the open source licenses, notably the GPL, often arise.

Personally I don't like those, but I can understand why they are popular and will continue to be popular.

So far, the Android store is open source friendly, and Apple one is not yet open source friendly.

But there is a new one in town, so I will look at the new Windows Store, that will ship WinRT Metro and Windows Phone 8 applications.

I will look at the 3 main liberties (copy, modify, redistribute) and the unrestricted usage liberty.

Legal analysis

Part 1: Store terms of use for users

The referent document can be found here.

The first reaction that those terms of use are way better than the ones from the competition. I don't really like Windows 8 but this is very well executed.

In section named What are my rights for apps I get from the Windows Store?

All apps made available through the Windows Store are licensed, not sold, to you.

This is quite normal for software.

In most cases, that license includes the right to install and use your app on up to five Windows 8 enabled devices simultaneously. If you try to install an app on more than five devices, it may be deactivated automatically from one of these devices, so that no more than five instances are activated at any one time.

5 device limitation, for most cases. This needs clarification for what other cases are. (see the bottom of this mail)

In limited circumstances, such as when a publisher designates the app as eligible for use on only a certain type of device, apps might not install on other types of devices.

Publishers can be assholes or have not ported to ARM or whatever stupidity we add later on, on our devices.

We provide the name of the app provider licensing each app, which may be Microsoft or a third-party app provider."

Microsoft will always tell you the name of who actually licenses the application.

All apps are licensed to you under the Standard App License Terms at the end of these Terms of Use, unless the provider of an app provides you with access to separate terms or agreements in the app listing page, in which case those terms will apply.

Either there is a correct license, or we force our broken terms.

Those terms might also include a privacy policy. The app publisher is the seller and licensor of the app.

Microsoft is not the seller or licensor, they act as a store.

When a third party is the app provider, Microsoft is an agent of the third party that provides the app to you, but we aren’t a party to the license between you and the app provider, and our privacy statement doesn’t apply to treatment of information you might exchange with the app provider when using the app. In such cases, Microsoft isn’t responsible for the app or its content, your use of the app, any warranties or claims relating to the app, or customer support for the app.

Microsoft is not responsible for 3rd party apps, and does not apply neither its terms of conditions nor privacy policy, if there is a license.

But your relationship with Microsoft and your use of the Windows Store will still be governed by Software License Terms for your Windows operating system and these Terms of Use. Because Microsoft processes the app purchase or, in some cases, the in-app purchase transaction as the agent of the seller, you might see Microsoft listed as the seller on sales records.

But even if it is the case, the Microsoft Store software and Microsoft software are govern by Microsoft SLT.

The rest of the terms is not about apps, and then there is their SLT which is clearly not open source, because of the section 3 that forbids the 3 main liberties.

Part 2: Application Developer Agreement

The referent document can be found here.

The important part is named: 3) g. License to Customer for Windows Store apps.

You, not Microsoft, will license the right to install and use each app to customers. You may provide a license agreement to the customer for your app.

Same as above, restated as a developer point of view.

That license agreement or other terms that govern a customer’s use of your app (including any privacy policy), or a link to them, must be delivered to Microsoft for publication via the product description materials you provide to Microsoft.

You must share the license to MS,

If you do not provide such materials, then the Standard Application License Terms, attached as Exhibit A, will apply between you and customers of your app.

or the SLT will apply, automatically.

If you provide your own license agreement, your license must, at a minimum,

Your license must allow, at minimum (so more can be allowed):

(a) permit the customer to download and run the app on up to five Windows 8 enabled devices that are associated with that customer’s Microsoft account, without payment of any additional fees to you (from either Microsoft or customer),

At least 5 devices.

(b) include "disclaimer of warranty" and "limitation on and exclusion of remedies and damages" sections that are at least as protective as Exhibit A


Usual "NO WARRANTY" section.

(c) disclaim any support services from Microsoft and the customer’s device manufacturer and network operator (if applicable).

Be clear on support services and who is in charge of the support.

Your license terms must also not conflict with the Standard Application License Terms, in any way, except if you include FOSS, your license terms may conflict with the limitations set forth in Section 3 of those Terms, but only to the extent required by the FOSS that you use. "FOSS" means any software licensed under an Open Source Initiative Approved License.

Your license should be compatible with the SLT, except if you include FOSS, in which case you can violate the part of the SLT that disallow reverse engineering, decompile.

Here is the part of the SLT that you can explicitly violate:

work around any technical limitations in the application;

reverse engineer, decompile or disassemble the application, except and only to the extent that applicable law expressly permits, despite this limitation;

make more copies of the application than specified in this agreement or allowed by applicable law, despite this limitation;

publish or otherwise make the application available for others to copy; or rent, lease or lend the application.


Technically, a contrario from what Microsoft is trying to explain people, WinRT applications are Win32 applications, that have artificial limitations imposed by the Windows Store submission process.

They are usually linked to MSVCR110 for standard calls, which is a major component of the operating system on which the executable runs. Those applications don't ship anything else than the usual executables and a few .xml crap.

tl;dr: Summary

Your usages are not limited; except you cannot use the application on more than 5 devices, unless the license clearly says you can use it on more devices. That might need an extra clarification, to check if you can have unlimited devices.

You can reverse engineer, decompile, disassemble the application, make more copies of the application, publish, distribute, rent, lease or lend, as long as you are FOSS.

Therefore, I think it is quite safe, now, to publish a FOSS application on the Windows Store.

- page 1 of 3