3 ms·

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

by Todd 14y ago

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.

PaulHoule 14y ago
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.
- Todd 14y ago
  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.
asveikau 14y ago
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.
- Todd 14y ago
  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.
jbk 14y ago
> 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 :)

by Todd 14y ago

PaulHoule 14y ago

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.

Todd 14y ago
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.

asveikau 14y ago

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.

Todd 14y ago
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.

jbk 14y ago

> 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 :)