|
jeffery c wrote: using virtual box with the windows phone image
That would be worst thing to do. Don't do it. 
1) It would be extremely slow.
2) Even if you could get something like x86 around with that, there would be a lot of consequences.
3) Those who do it, are IT guys. They don't know anything of programming. All they care about is that blue logo of Windows.
In case if you really have to, consider Hyper-V, as that is the platform they require you to use, and there is a method where you can setup booting where you can (when working) boot with Hyper-V enabled, and (when at home, or not working) boot with Hyper-V inactive. Otherwise, consider an online solution.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Afzaal Ahmad Zeeshan wrote: The thing is, that entire of the Windows Runtime was developed on top of async/await pattern
I thought that was a fantastic improvement, but the fact that it only runs on W10 (I finally have a laptop that uses W10 that I purchased a couple months ago) was a total showstopper for me in bothering to even learn more about it.
Marc
Latest Article - Merkle Trees
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Marc Clifton wrote: bothering to even learn more about it.
Let me tell you what I learnt in my past 6 months, or literally-hair-pulling-ly-rough-experience, it works fine and in 2 different ways.
- You don't use async/await at all. You perform all the operations synchronously.
- You write every function call, with an await operator. That way, most of the errors (such as Illegal operation, Invalid state) etc would go away.
I would go with the second one, but like you said, it still requires us to learn more about it. I built one of my application, 1.5 years ago, which had 0 async await applied, because I did not know anything. But, I was working on another application a few weeks back, and since I knew async/await, I mistakenly added a few function calls as awaited. After that, it forced me to make sure every call in the stack was awaited, otherwise,
- Illegal state
- Invalid operation
- Infinite loop
Were only a few of the problems to tackle and work on. I think, in the next update Microsoft should work on these things, to make sure asynchrony is managed by OS itself and even being a feature of language, stays as a pain of the kernel only.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Afzaal Ahmad Zeeshan wrote: I think, in the next update Microsoft should work on these things, to make sure asynchrony is managed by OS itself and even being a feature of language, stays as a pain of the kernel only.
I'm not convinced this is reasonably possible. I assume when you say "asynchrony is managed by OS itself" you are saying the OS should re-use a blocking thread's time-slice? How would you maintain state then for the blocking code? If you save the stacks, registers, etc before loading the new code then you're still basically performing a context-switch with even more overhead. The OS/hardware is already both asynchronous and multi-threaded from its standpoint. The hardware has a specific number of cores ("threads") and the OS switches out kernel threads ("tasks") to make best use of them including suspending blocking kernel threads. Abstracting out these kernel threads into another thread/task pattern is of no concern to the OS and rightfully so.
The language being asynchronous would be possible but I'm not convinced it would be a benefit. Multi-threaded applications might rely on the main thread being synchronous which would no longer be a guarantee. Just enabling asynchrony by default might be an alright idea. You could just wrap the return in a Task<T> under the covers. If the function doesn't use await then it'll just run synchronously.
public class Whatever
{
public async Task<int> ReturnTwoSynchronously() => 2;
public int ReturnTwoSynchronously2() => 2;
}
At the end of the day though, is it worth the effort? My opinion - probably not.
modified 22-Apr-17 22:46pm.
|
|
|
|
|
Oh, some good points. 
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
For you old C/C++ devs: await is the new const correctness.
|
|
|
|
|
To answer the question of what I think about UWP, I think that it is built upon legacy technology. It is my understanding that the async/await mess is partially the result of the limitations of the message loop. If someone can explain async/await in a manner that makes clear when we need to use it then that will be popular. For example the clipboard in UWP requires async/await in many places but everywhere else the clipboard does not require threads or waiting (except waiting on the user). I don't understand why UWP needs async/await so much except (1) the message loop for some reason and (2) it is in a separate environment that requires additional security beyond the classical Windows process.
I think Java also has async/await; does it? Is it as confusing as UWP is as far as async/await?
The requirements for UWP probably go beyond the current design of Windows. Probably Microsoft needs to write another operating system to support the requirements. IBM has developed many operating systems but Microsoft has designed, at most, two operating systems. IBM had an operating system they called the Event Driven Executive; it is probably not relevant here except that the concept of being event-driven is not new. In many ways, Microsoft's technology is behind that of half a century ago and UWP is weighed down by that.
|
|
|
|
|
Sam Hobbs wrote: In many ways, Microsoft's technology is behind that of half a century ago and UWP is weighed down by that
LOL, reminds me back in my younger days [as an employee] was often required to attend microsoft presentations. I recall one in particular when they introduced "multithreading" (demo: one window set to crash, the other carries on.) (This demo of "brand new tech" was about 10 minutes into an after lunch presentation - at that point I shook my head and left - not back to the office but went home)
It was something I knew was already 25+ years old (FFS I had a 'nix running on my own home pc).
What sticks in my mind though is the room full of people oohed and aahed over that demo, and were still talking about it the next day back at work.
so while true that ms never bring anything new,
where they usually [too often] excel is in bringing these things to the market.
usually excel as in: there are items even in android/iphone that ms did earlier (not first), .... but they lost the phone battle.
(OT - rant: it was 100% their sucky interface that looked just like the same sucky interface on windows 8 (was that uwp 1.0?) that failed their phone. Today it's the win 10 uwp (2.0beta?) that is mostly responsible for hobbling win 10 adoption and killing pc sales; it will also [if not -has already-] wreck their next attempt at a phone. Yes some people like the look, but then again some people drive pink cars. nad's biggest fail is and always will be this insistence on keeping this fugly uwp.
Sin tack
the any key okay
|
|
|
|
|
Looking in Wikipedia (which is not always reliable but is useful for this) multitasking was available beginning about 1964. Even back then, processors were faster than peripheral hardware so the benefits of multitasking was obvious.
Not relevant to Microsoft, but I once saw a presentation for Artificial Intelligence programmers about a new way to design software. It was old stuff for other types of programmers.
Microsoft's tendency to deliver things to the world is not always good; their focus on Basic instead of superior technology, such as Pascal, is unfortunate. If I had a choice of Basic or COBOL as they existed at the time, COBOL was far superior. If performance was the consideration, Pascal was explicitly designed to show that something better was possible that could perform equivalent to Basic.
Most people do not realize how much of what Microsoft developed in their earlier years came from outside Microsoft, such as from IBM and Unix.
The one innovation that Microsoft did help with could be dynamic linking. Unix did not have it at the time; I forget if OS/2 did but it probably did.
As I mentioned previously, and in the context of UWP, I wonder how much of the async/await mess is unique to Microsoft.
|
|
|
|
|
I am sure many people here would read your articles, and learn from your experiences !
The questions always on my mind are:
1. what does it offer me now, and in the future ?
2. what does it cost in terms of "learning curve," set-up, deployment ?
3. what resources are available to get oriented, and start developing ?
4. to what extent can current skills be re-used ?
cheers, Bill
«When I consider my brief span of life, swallowed up in an eternity before and after, the little space I fill, and even can see, engulfed in the infinite immensity of spaces of which I am ignorant, and which know me not, I am frightened, and am astonished at being here rather than there; for there is no reason why here rather than there, now rather than then.» Blaise Pascal
|
|
|
|
|
Sorry bill about the mess (flips his coin like Han solo in the cantana to bill), I will make up for up for it with an article here soon. Some people here must be older programmers to know what the nuclear systems are written in.
jeffery
|
|
|
|
|
NASA had to re-purpose its existing computers whenever a new satellite was launched.
I know for a fact that these were programmed in assembler as that is the fastest language to execute programs in.
The programs that processed the data streamed by the satellites were themselves written in assembler.
In addition, real-time operating systems were written for machines that you could swear couldn't support such OS for lack of even minimal hardware support.
All of this in the 1970s.
Been there, done that.
|
|
|
|
|
jeffery c wrote: If I post some code here and articles would people be interested in UWP?
Yep, definitely. I've got an existing Xamarin app that runs on iOS and Droid, but I've been toying with the idea of creating a UWP app with it as well (for desktop/laptop machines).
I don't know much about UWP (been a bit busy with porting my ASP.NET app over to .NET Core and coding the Xamarin apps) so it'll be interesting to see what it can do and whether it's suitable for my needs.
Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
It's not popular and is used by very few people/companies today. I had considered writing an article series on it last year and then decided against it. If you've got them drafted already, I'd say post them - don't expect a lot of feedback though, outside of casual 5 votes.
|
|
|
|
|
I like what Microsoft is trying to do with UWP apps. It's the only game in town if you want to run the same application on both your desktop and mobile device. The only problem is that there aren't enough Windows 10 Mobile users to drive the demand for UWP apps. If Windows 10 Mobile could get just 20% of the mobile market it would change everything.
|
|
|
|
|
With Windows Phone completely dead right now, my personal opinion of UWP / .NET Native is that it's a huge pain in the ass and not worth using at the moment except for very limited use cases. I'm personally of the opinion that WPF is a better solution for *almost* every application with many less "gotchas". As you've noted, you can still get it into the store with their converter.
The thing that really kills UWP for me is lack of emit and code gen, which I use extensively. Reflection also becomes painful.
The desktop to store app converter is pretty brilliant. It's great.
I wish they would kill UWP / .NET Native and put the resources into coming up with a better solution that doesn't rely on native compilation. Android seems to be doing just fine without it.
|
|
|
|
|
go ahead, post!
I am currently doing a lot of iOS and Android development, always hitting the same backend, so lots of redundant code on the client, so I started to develop on Xamarin. Well, I love it, so I might post on that. While creating a new project, it also creates an UWP poject, and I always dismissed it with a meh!
Big mistake, I am enjoying (and making money) creating the Win 10 companion apps to my iOS and Android apps, my clients love it!
|
|
|
|
|
Hey,
I wanted to share this story today with you as it is a very special milestone in my career as a developer.
Recently (say, about a half year ago) I got the chance to start working with a rock band here in Austria. They are no newbies, having already 5 albums produced, are performing live really great, they played on the "Donauinselfest" in Vienna, a Rock Festival with more than a million visitors in only two days; they have their own studio and make really great music.
It happened that I know their lead guitarist personally but I didn't know that he was a musician, he was never bragging around or behaved as he was "someone special". One day of course while we were talking, we had the point where he told me, what he was doing in the evening ... And so one thing led to the other...
My daughter and I joined them in their studio, she even could sing a duet with the lead voice of the band (I have the video here... an amazing experience for a 14-year-old-teenager girl!)
And during a break that evening we talked a bit all together, I told them that I am a mobile developer and so I got the chance to create their App! They wanted an official content App, containing their albums, songs, lyrics, embedded youtube videos from their channel, live concerts, biographys, a contact option, and..and..and.
Today we are only a few weeks away from the launch party (they play a concert just to introduce the app to the world!) and as we had some good chats the last days, doing the roadmap for the launch, finalizing the content in the app and all that stuff, I am getting really excited by now
I must say, after almost 30 years as a developer, the last months working with those guys was something new and amazing for me! This is gonna be a very special app for me as it really feels, that I "helped" somebody, that I could do things someone really needs.
While some xml-layouts and fancy animations here and there are nothing very special to ME, they earned a lot of "ooohhh's" and "aaaah's" from the band. For them, this is something "yeaaaah baby!" 
This project just makes me feel sooo good. Something I missed (or lost) during the years, doing one project after the other...
This one is special. I love it. And thats why I share it with you!
Thanks for reading!
Cheers, Mike
And: ROCK ON!
|
|
|
|
|
Huh. I didn't expect to read a post from a fellow 'Wiener' here
Nice read, surely fun to work on something without stress, corporate guidelines and standards forced upon you
|
|
|
|
|
*winkt zurück* Servus 
Yes it is - I am getting a bit nervous as they told me that they will "call me up to the stage" during the concert to present the author of the app... 
Second thing that makes me nervous is... I am a hobby-drummer, played for years and of course they know that... Might well be, that I will take the drums for a song during the concert to play along with them... Now THIS is a bit a scary imagination... on stage... oO
|
|
|
|
|
Whhooo! You better practice their songs, nothing messes a band up like a drummer that's off time...
Good luck - and post a video!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
nothing is more funny 
modified 19-Jan-21 21:04pm.
|
|
|
|
|
What's the difference between a drummer and the rest of the band?
About half a count 
*Ba dum tsss*
|
|
|
|
|
A band consists of musicians and a Drummer, I was told
modified 19-Jan-21 21:04pm.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
