dpJudas wrote:When it comes to UWP, I am deliberately not writing any such apps. It could very well be that Microsoft is still trying to push it, but I will do my part making sure it will not replace Win32.
Seeing that UWP is a system made for toy apps it will never replace Win32. Even on macOS all the sandboxing rules basically mean that some real productivity apps cannot be distributed via the app store, and here it's even worse because the API is so crippled.
I am sure that UWP will be popular for the kind of shit stuff aimed at unsuspecting customers but the entire system basically ensures that everything with some cross-platform design or things targeted at power users would be too confined by the strict rules and limitations. And if that kind of shit software now gets made for UWP, nobody will really miss it.
The only contact I had with it was some years ago when I had to port a game for the Windows Store.
dpJudas wrote:
As for asynchronous I/O, I find this to be a solution causing more problems than it solves. Same thing with system thread pools for that matter. They can try to push it all they want, but that won't be enough to get me to use it.
What's the point of an asynchronous API anyway? The iOS app I am working on is doing a lot of asynchronous I/O - but that is being done by launching a worker thread that controls the entire thing from top to bottom without such nonsense as having to wait for futures for single operations, etc. Since it is a single continuous thread it's easy to debug, unlike the asynchronous API, and the end result is the same - I/O runs in the background without stalling the app - once it is done I call a completion function to wrap it all up, instead of some insane construct where each I/O call results in a completion callback starting the next slice, and so on, and so on...
The web access in the app needs to be done with an asynchronous API on the other hand - and calling that code "messy" would be an understatement. I'd rather do it the same way as the file I/O: Fire off a worker thread that synchronously executes the request so that I can keep full contol over it instead of having to rely on a badly designed callback system. But no such luck here...
About system thread pools, that's something hard to avoid on iOS, though. The entire system is built on this concept. But on Windows the entire system for the thread pools is a medium-sized disaster where the boilerplate to get things running exceeds all sane conventions, so why use it...?
dpJudas wrote:When it comes to Windows and Unicode, I find it works perfectly fine converting between UTF-8 and UTF-16 for everything except the console. Yes it would be nice if the ANSI functions in the API could be changed to accept UTF-8 directly, but I'll survive without it. As for the console, eventually they will do something as their Azure stuff means they really could use a better console themselves.
I think they are already working on something here, but as that WSL issue suggests, it's not quite finished.
[quote="dpJudas"]When it comes to UWP, I am deliberately not writing any such apps. It could very well be that Microsoft is still trying to push it, but I will do my part making sure it will not replace Win32.
[/quote]
Seeing that UWP is a system made for toy apps it will never replace Win32. Even on macOS all the sandboxing rules basically mean that some real productivity apps cannot be distributed via the app store, and here it's even worse because the API is so crippled.
I am sure that UWP will be popular for the kind of shit stuff aimed at unsuspecting customers but the entire system basically ensures that everything with some cross-platform design or things targeted at power users would be too confined by the strict rules and limitations. And if that kind of shit software now gets made for UWP, nobody will really miss it.
The only contact I had with it was some years ago when I had to port a game for the Windows Store.
[quote="dpJudas"]
As for asynchronous I/O, I find this to be a solution causing more problems than it solves. Same thing with system thread pools for that matter. They can try to push it all they want, but that won't be enough to get me to use it. :)
[/quote]
What's the point of an asynchronous API anyway? The iOS app I am working on is doing a lot of asynchronous I/O - but that is being done by launching a worker thread that controls the entire thing from top to bottom without such nonsense as having to wait for futures for single operations, etc. Since it is a single continuous thread it's easy to debug, unlike the asynchronous API, and the end result is the same - I/O runs in the background without stalling the app - once it is done I call a completion function to wrap it all up, instead of some insane construct where each I/O call results in a completion callback starting the next slice, and so on, and so on...
The web access in the app needs to be done with an asynchronous API on the other hand - and calling that code "messy" would be an understatement. I'd rather do it the same way as the file I/O: Fire off a worker thread that synchronously executes the request so that I can keep full contol over it instead of having to rely on a badly designed callback system. But no such luck here...
About system thread pools, that's something hard to avoid on iOS, though. The entire system is built on this concept. But on Windows the entire system for the thread pools is a medium-sized disaster where the boilerplate to get things running exceeds all sane conventions, so why use it...?
[quote="dpJudas"]When it comes to Windows and Unicode, I find it works perfectly fine converting between UTF-8 and UTF-16 for everything except the console. Yes it would be nice if the ANSI functions in the API could be changed to accept UTF-8 directly, but I'll survive without it. As for the console, eventually they will do something as their Azure stuff means they really could use a better console themselves.[/quote]
I think they are already working on something here, but as that WSL issue suggests, it's not quite finished.