Richard, where did .NET come from? Let's talk about that. Hi, welcome to Visual Studio Tillbox. I'm your host, Robert Green, and joining me, Richard Campbell. Hello, friend. Hey, Richard. Good to see you, man. We just saw each other last week. We did. Yeah, down in San Francisco. And then you said, or I said, you should come on the show. And then it occurred to me that you've never actually been on this show. No, and you've been on mine, although I was not co-host at the time. Show 43. That's the .NET rocks we're talking about, by the way. You were in the original 50. The first 50 shows, that's like December of 2013, and the co-host was Mark Dunn. All right, and then Mark stepped away at the end of the first 50. And the second co-host was Rory Blythe. Cool. And so Rory, and then Rory joined Microsoft. Yeah. And then, you know, Microsoft kind of eats up a lot of your energy. Yes, it does. So I came on board with .NET Rocks at show 100. OK. And as a recording of this, we're at show 1594. Sweet. And this show is like, I think we're at about 270 or so. So you're in rare. So I don't have to feel as bad about waiting 15 years. You should be back, because I think you work on great stuff. But, you know, you've been through everything, right? Like you used to be a Fox guy. I did. And when I was on .NET Rocks, it was on Visual Studio Tools for Office. Right. Or the official name, the Microsoft Visual Studio Tools for the Microsoft Office system. Yes. Because naming is hard. Yes. So in addition to co-hosting .NET Rocks, you are working on the definitive history of .NET. Yeah, I kind of fell into it. And our mutual friend Beth Massie reached out to me back in 2017. And there was a 15-year ship party. Yes. So it had been 15 years since .NET had shipped. And they were throwing a big party. And she asked me to help out. Which means it was about 20 years since it was invented. Yeah. Something like that. Was it five years before it actually shipped? That's a fascinating question. Because the more I explore it, the more I realize, there was no intent to make .NET. It emerged. It emerged from a bunch of different problems being worked on, and then eventually people find each other. That, to me, was fascinating, that the runtime was one thing. This whole problem of you had the C++ stack, and you had the Visual Basic stack, and other languages, and how Windows features surfaced in that. As new versions of Windows coming out. And you think about back in the 90s, when Microsoft was putting out literally two lines of Windows, the NT line and the 9X line. And it was every couple of years. And so they would make improvements to the operating system. And as developers, we kind of wanted access to those. And each runtime took effort to implement those features, and took time, and the interpretation buried. Yes. And so the idea of a common runtime was trying to mitigate a bunch of that pain. Mm-hm. The other aspect of it, I find fascinating, is what became C-sharp. Because up until then, Microsoft had never invented a language. Microsoft took other existing languages, basic and so on, and did their own implementation of it, quite successfully. One would argue that Gates' original vision was uncoupling the language from the machine. If you go back into the 70s when Microsoft started, and even the 80s, where computers are iterating so rapidly that the software included with the machine was so bound to that machine, when the next machine came out, you sort of started over. Microsoft always had this angle of your programming skills using Microsoft versions of these languages work across these machines. So you're more productive as a developer. But Microsoft had a phenomenal version of Java. The J++ was wildly successful. One would argue, do successful. Plus, as the dominance that Windows had at the time, as Microsoft started tuning J++ to optimize for Windows, that became a problem for some microsystems. And so there was a pushback in the form of a cease and desist. And ultimately, they ceased and desisted. But that group of people that worked on the J++ tooling, and it's, I mean, some of our market, not just Anders Halsberg, who's extraordinary, but also, I've had, and Patrick de Sade, who was one of the key people behind the JVM implementation that Microsoft did, also heavily involved. He was the advocate for garbage collection for the CLR as well. In a company that was largely a reference counting company. And so again, it's these different pieces of, okay, well, we can't work on Java anymore. We need an up-pure object-oriented language. And we have a potential of a runtime. And those things come together. And then throw the web in. Because it was kind of a thing. J++ had one of the coolest t-shirts ever. It was a box of J++ spilled open with coffee beans. And it said, you know, our Java's the best. And then there was the legal disclaimer about what Java we were talking about. That's just, I think I still have that shirt. It's a little worn and ragged. And I'm not, I don't think I'm allowed to wear it in public, but I still have it. But also, there's lots of other projects that went on in those late stages of the 90s that was really an exploration of what do enterprise developers need? What will make them more productive? What will build software quickly and reliably in the constraints of the typical enterprise? Which is a different set of problems. And .NET came out in the internet revolution when it wasn't just, you know, com worked well, across machines or in a network. Now you have this web-based world and then you have Java's the enterprise language that's going to kill Microsoft.  And I don't get all the murder parts of this, right? It's like, yeah, you know, if there was one right way, we'd all be doing it. There's many ways to be successful. Yes, I mean, if you've learned anything is that you can become a market leader, but it's an unbelievably competitive market, right? Sure.  No.  Nothing, code never dies. No, it really doesn't. Things get matured. Matured as a verb means we're not gonna really work on it anymore. But you look at the demand for Java developers today, you know, I don't know how much Greenfield Java there is, but the Brownfield Java is an epic space. It's a tremendous amount of work and the demands continue to expand. So it's an ongoing effort one way or the other, but as I dug into this story and certainly all of those early stage charts are really fun, you know, I kind of look at this as four acts, right? So there's that preliminary emergence of we need to make a thing. And then you have the second act which really comes with ship data 2002 for version one, then 1.1 and even up to two in 2005. As I think the versions where you actually made the thing you meant to make, right? This idea of a development environment that's efficient in the enterprise, it's heavily integrated, can work on the web and work on the desktop, like you look at 2.0, there's lots of people who still believe like that, we nailed it, like there was the one, it was robust, it was reliable, you could run it on a web server well, you could run it on a desktop well, like it was great. And then the third act is hard. You know, the third act is a tough time at Microsoft with Vista and a tough time around the emergence of mobile and how we're gonna deal with that. So talk a little bit about how the operating system affects how I think about .NET as a developer, right? Because unless I'm writing code that calls into operating system functions, right? And we talk about, well, we released a new version of Windows, it's backwards compatible, everything that runs in the previous version will run on this version. So I'm working on my application, I'm upgraded to Vista, which I may or may not, I've enjoyed that experience, but abstracting from that, I've still got Visual Studio, I've still got my application. What difference does that make? And I mean, we talk about one of the strengths Microsoft's always had, it's that that upgrade path was pretty painless. But it was also I think a frustration on the Windows side because often that upgrade met you never took advantage of the new features. You almost had no visibility into them. That's true because in marketing, and I was in tools marketing at the time, we had to include taking advantage of Windows features like jumpless and whatnot. And to be honest, it felt kind of paying the tax, right? Yeah. Oh, now let me shift gears entirely and show you a cool demo of something you may or may not be interested in that takes advantage of the feature in Windows and people would look at that and some people would say, oh, cool, I want that. Others would look at that and go, oh, cool, I don't think I'll ever do that. And others would look at it and go, why are you doing that? And one of the challenges there is as soon as you start talking about features like that, you're talking about changing people's workflows and people don't like that. They kind of want to keep working the way they want to work until you get a major milestone, like I need this to work on my tablet, I need this to work on my phone. And they're now prepared to make that jump in workflow and you got to kind of grab all those bits and look where. Or I need this to work on Linux. Yeah, well, if the operating system still matters, I would argue maybe this is jumping to the end of the story as I'm still gathering this history, is don't we hit a point where the operating system just doesn't matter anymore? And I think the cloud is a big part of that. It's not just the programming environment, the programming environment was ultimately influenced by the demands of people. It's that operating systems are abstracted enough away from us, we're starting to care about them just about as much as we care about the BIOS in our operating, in our machine or the microcode in the CPU. Like they're just expected to work. And so bit by bit, I think OSs have become part of the plumbing. Yes, but at the same time, if you think about Windows as an app, it takes advantage of new Windows features, right? It does. Like timelines and whatnot. And that stuff is available for you to take advantage of in your applications. We tend to think, oh, there's the apps that I use that are built by Microsoft. Oh, I expect them to take advantage of all the new features in Windows. Forgetting the fact that those are just apps calling it the API is the same way you could as well. And I think it's one of the challenges you have with an operating system today is what's operating system and what's app? I mean, I appreciate that Windows had over the decades consistently taken what used to be an add-on and turned it into part of the operating system. I mean, a clear example, that would be networking. I mean, once upon a time, you bought PCs that had no networking. And when you wanted networking, it was a separate product that you paid for. Windows for work groups. Windows for work groups. Now, I was a network certified installer. That was like Windows addition. Exactly. Yes. But eventually recognize that networking is plumbing. It should be part of the system. It's just included. Once upon a time, installing a sound card and configuring it was a thing, then it was just part of the operating system and part of the hardware. So, bit by bit, the operating system surface area grew. But at the same time, we also decorated the operating system with a lot of stuff. And you can call it part of the OS, but is it really or is it just more apps? And yeah, you want those things to interplay and see what's valuable. But it made the operating system as large as it is. So, is the .NET runtime part of the operating system? Well, that's a great question. I mean, one of the things we know for sure is that Microsoft tends to maintain support for a long time. The VB6 runtime, last updated in 1999, is still included in Windows 10. Right. Because it ships with Windows. So, it ships in the box. In the box. Not that there's boxes anymore. Because ships in the box and therefore. But it still speaks to a philosophy of, you don't break people's stuff. Right. You try and find a way forward. And when you do break people's stuff, your answer is, oops, we better fix that. And I'm, you know, I would hope you never break things, but we happen to know you do once in a while. Like stuff happens, but the reaction is all, is not working as intended. It's, oh, that's a problem. We're going to fix that. Working as intended is the software keeps running. One way or the other. But adding that surface area, I think is a very challenging part of the overall equation. So when, and when I talk about the operating system becoming less relevant, I'm talking about the plumbing parts of the operating system. Right. That networking is networking. It's all TCPIP today, right? Didn't used to be. Yep. You know, we used to have a debate about that. And virtualization is part of the operating system. So there's a couple of ways to, to think about the act of programming. One is that you type in a particular language, which may be a new language and maybe a language that looks like a language that you're familiar with, but it's basically, you type words and commands, and then there is a runtime that executes that, right? And that's all plumbing. And whether it's com or .NET or whatever comes after that, I assume there's always some type of runtime environment. I assume there's always a language that I either know or can learn to do the exact same thing, right? Every app we've ever written, you can think about it as a line of business developer. It does the exact same thing. There's data that you're managing. There's a UI which displays it and then there's code in between to marry the two, right? So no matter what you're doing, it's the exact same type of app only different because there's a different runtime, different language. So. The missions don't vary that much. And you're always interacting with underlying software that you didn't have to write. How far that abstraction goes up or down is a separate question. Right. To the extent that when we moved to .NET and we did and many people moved from VB to C sharp took advantage of all this new abilities. Yeah. To what extent do you think .NET changed how that happened or did I just do the exact same things with a different set of commands with a different runtime and what's the difference? Well, in Marshall McLuhan's great quote is first we shape the tools, then the tools shape us, right? And if you actually look at the progression of .NET you see those tools ultimately shaping us too. So right off the bat, when you think about moving to .NET and all the struggles that was surrendering ownership of memory because you don't want on it. It's a problem, right? Easy to create stuff, we'll do the cleanup for you. So a whole class of memory leaks went away. A lot of respects to say that concept went away when we stopped having responsibility for memory. Abstracting away from CPU architectures. The whole thing about just in time compilation is that it was able to say, what am I running on? Okay, let's run on that. So that problem went away and I only became aware having done long interviews with a bunch of the CLR guys about how many other processor architectures they implemented in the CLR that we largely never saw. They had a plan for Itanium. We were going to be able to simply compile to Itanium in a .NET. We ended up not needing it because Itanium didn't go anywhere. But that work got done. For the brief period that we really cared about the ARM chip set, we had to compile to ARM. That option existed. So it's funny that the power of .NET that we pretty much got in 2002 was essentially so transparent to us we almost immediately forgot about it once we stopped fighting with it. But there's subtler things. Having talked to folks like Dawn Simon, Anders Halsberg, and Mads Torgensen, the work that was done at the very beginning of .NET to support generics. And they were absolutely informed by the struggle that the Java world had had not thought early enough about how they were going to be able to do those kinds of functions. And so that they, while they didn't get it really implemented until two and we didn't get linked until three and three, five, they were thinking about that before they shipped in 2002. And that set of thoughts introduced a whole class of programming that it was even hard to explain back then. Now, one of the upsides for me being part of .NET Rocks is I remember knowing that Link was coming a year in advance. And so starting to, not that I could tell everyone, hey, this thing is coming. They want to have their launch the way they want to have their launch but that I could start preparing people. That we could start talking about lambdas and generics and mechanisms you could use around that and what advantages they were. So when the great announcement landed, folks knew they knew what to do. Oh, I see, I know how to do that. I've learned about this already. Now I see value there. This is a level of abstraction and programming where we spend fewer, fewer time typing about plumbing and more time talking about the business value that our software adds, right? What is a Link expression except a very summarized form of an important business activity in some form? And more and more that close plumbing pieces get pushed down. They're part of our base class libraries. They're part of the framework and this tooling simply means that the code that I see every day and the code that I actually type is the business value that I'm adding. So the fact that things like that are runtime or .NET features that are implemented in various languages and sometimes in both and sometimes in one or the other. And we've gone back and forth on that, right? There wasn't going to be language parity then there was going to be language parity. Now we've decided that we don't literally need 100% language parity but it's all basically runtime features which means that any of the languages are then capable of taking that on and having it part of the language. Yeah, for better or worse, it compiles all to IL. Right. And I think the real clever trick is if you look at IL, it is inherently object oriented. And here we are in F sharp writing functional expressions. And if you look at the IL that generates and I'm not encouraging that because it's hard on your brain, it's tough to do a great functional translation. They're doing it and it's quite efficient. And it's interesting that the effects of functional programming have influence C sharp programmers too that you can write quite functional C sharp as well. It sort of speaks to the flexibility of CLR. It's interesting to consider the idea that there is a fundamental bias in everything we do in .NET because of the way the runtime ultimately consumes the code. Right. So we have had, there's obviously the languages that we create here at Microsoft. We've had third party .NET languages, COBOL.NET, right, from the very beginning. There were 22 languages. Yes, there were. And of those 22, how many do you think succeeded? Succeeded meaning, reasonable amount of usage and enough justification to keep working on it. A few, like if you go to the marketplace, Fujitsu's still supporting COBOL. It's $700. You can buy it if you want. IBM's still supporting Fortran. There's a Fortran .NET. I think it's actually a 2017 right now. There was Scala, did that one? Scala didn't survive. So one of the things, again, I've discovered in the story and hopefully this will be in the book, is that part of making that list of 22 was reaching out to different aspects of software development to bring in those languages. So some of those languages came from significant language development shops. Like IBM and Fujitsu and so forth. And some of them came from academia. And so really the goal then was a group of graduate students doing an implementation against an environment they hadn't really experienced before. But once it was done, that was kind of it. So it was in the box in 2002, but I think especially in the case of the academics, many of them didn't proceed after that. So that doesn't say plus or minus on them. There was a Haskell implementation in 2002, which is interesting. Because we're sort of circling back on that. Now we recently did a show talking about programming in traditional Haskell against with VS Code rather than Visual Studio and using that as a form of services that I can run on the back end against the .NET application. And you could presumably take any language today and create a .NET version of it. Could you create a go.NET if you were so inclined? Absolutely. One of the first times I ran across Don Syme when he belonged before F-Sharp. And he's been involved with Microsoft Research. In Microsoft Research, he's been involved with generics, although again, I found that out later. First time I ran across him in my capacity building .NET Rocks episodes was a paper he did sort of exclaiming to language researchers saying, look, every time you want to experiment with a language, you need an editor and a debugger and a runtime and so forth, like just dude in .NET, you get all these things for free. And then that, those initial thoughts and the experiments you're doing eventually evolved to what would be called F-Sharp. The extraordinary thing with F-Sharp is that it jumped out of MSR and into the actual mainstream engineering languages team to become a product. But you're totally right. This is a great land to experiment with language. And then how many different versions of the runtime have there been? There's been mono. Yes. There's obviously the .NET that we make. Were there others? Well, even when you talk about the .NET that we make, there were fragmentations of runtime within Microsoft. The Windows team ran a version of the framework versus the Web team running version of the framework. You could talk about the micro framework for the period that had impact. If you think back to Silverlight, there was a version of the CLI that ran on the Mac. Yeah. And there was a version of Silverlight that ran Win Phone 7. The fragmentation of the runtime, the base class libraries, the framework, and XAML got extreme. There was a point where we ended up doing shows about how hard you can learn XAML, but which XAML you learned. Exactly. You know, it got very fragmented and that came from people wanting to experiment. Like this is the downside to those experimentation is if they succeed in any way, you start having language differentiation and implementation differences. Certainly that was a challenge with mono. You know, mono after two was very selective of what got added. So it was never a parody with the traditional .NET framework. Right. Until the standards came along. Originally when those guys were at Novell, right? Yeah. Well, further back to that, and eventually that it would Novell. Okay. The first time I run across Miguel Diacasa in the gathering of the history is a talk he does at O'Reilly. In 2001, after .NET is announced and the ECMO specifications are published but before the product ships. And he says, I'm taking these ECMO specifications, I'm trying to do an implementation in Linux and people think he's crazy. But the experiment continues and does bear fruit ultimately. It's fascinating to realize that the hip new blazer actually depends on mono. Really? Because mono is written in C++. Okay. And ultimately the LVVM compiling stream into WebAssembly needs C++. Interesting. And Roslin's written in C sharp. Okay. So it's not that they couldn't use the Roslin engine, like they just had to be some interesting tricks back there. But Steve Sanderson's original implementation in 2017 that I saw at NBC in June, just over a year ago now, which is amazing that so much has happened. He was using a different open source implementation of C sharp in C++ that he found on GitHub. But as that started to iterate, Miguel got involved and they switched to mono because it was more completely was actually part of that standard. So it was a richer version. It's still experimental, but it's interesting when you realize there is value to these different incarnations. Right. As long as you can stick with standard. I think standard was a brilliant insight that we were better off writing a set of specifications we could all agree to and build independently to versus basically creating a gatekeeper through which everyone had to pass. It's just not scalable. Right. So mono beget Xamarin as well as Unity. Yes. And it's also a fascinating piece of the story is right at the time when Microsoft, you think about, when I think about the most difficult days of Microsoft, the 2010, 2011, 2012 period when the iPad ships. And then jobs, yeah. I remember. Yes. The first time I saw one of those, Mike I am our good friend, Mike I am comes to my house and he's got an iPad. Yes. And he's sitting at the dining room table and maybe 15 feet away is my tablet PC. One of the motion computing ones perhaps. Right. And I'm thinking to myself, dang. Yeah. Very differently. We could have had this first. I don't know that it was to be true because I mean, Apple's advantage was no legacy. Right. And they were aiming at a different space. And we, the tablet PC based on Windows meant that it had to be a business machine that ran Excel. Well, just the basic overhead of the runtime that is Windows, you know, it's not a small thing. I don't mean, you know, this isn't a criticism of leadership or anything. We were aiming at a different market but technology wise, right? The ability to have this small portable thing. It was extraordinary. I think it saved the laptop because at that time, the lap, we were trying to make a $500 laptop and they were terrible. They were so cheap, they were doing everything to pare down the price. And then along comes this $800 tablet that is gorgeous. And you can, now you can't even build a $800 laptop because it's not as nice as the iPad. So suddenly the base price of the laptop bounced about $1,200. And for $1,200 you build a pretty nice machine. And so some ways that I think it helped that but the hugest impact of the iPad, I think it's two-fold. One is Microsoft now gears up to try and build a version of Windows that's gonna compete in that space and that is not a trivial issue. And then Jobs puts out his thoughts on Flash Letter and basically says iOS is not gonna run plugins anymore through Safari. There was a workaround. There was another browser that you could install on the iPad that would run Flash. And it would murder the battery of the Flash of the iPad because that's what Flash does. But I think the real reason that he wanted to get rid of that is it was gonna make the iPad look terrible. He wasn't wrong about the plugin problems. He wasn't wrong about data vector for malware and so forth. And the white listing strategy was a good strategy that we're gonna validate software before it's installed in your machine.  But that's April of 2010 that that letter comes out. And at that point, Silverlight's got a problem. Now, for us out in the world, working in Silverlight, especially version three, like we were having a good time. We didn't know that, uh-oh, like, but internally the work was going on, that this is a crisis. And it sort of, that surfaces by the end of 2010. That's when all of that sort of comes out and the situation sort of appears and you have this battle of what languages make you, what is the true lingua franca in the heterogeneous world of operating systems. Recognizing iOS and Android and Windows and Linux are all legitimate operating systems just for different form factors of what are very personal computers. You know, you can't tell me, a smartphone's not a personal computer. It is a computer. It is not a computer, it's incredibly personal. This is a computer that I refer to as my phone to distinguish it from my surface. And I in fact spend more time on this doing computing things. And when I get a phone call, I view it as an interruption. Totally, and it's like the last thing you want on that. Which cracks me up because it's a phone to cry out loud. But it is the most personal computers. It's the only personal computer that your concern might give you cancer. That's pretty personal. So in that diversity of operating systems to step back as an architect and say, how do I program efficiently across all of them? That was, I think, a very significant crisis outside of Microsoft. The focus on JavaScript made a lot of sense and this is where things like when JS start to appear. But at that very same moment in 2011 is when not only has mono touch done well and that is the mono for iOS, but they ship mono for Android. And so at the same moment that Microsoft's saying, maybe C Sharp can't be everywhere, Miguel Diacasa says, would you like iOS and Android? How about that? And then Novell implodes. And so along comes Attachmate buys up the remains of Novell and says, this mono thing's not important. You could stop all of that. And Miguel, again, too, is credit, grabs that Friedman and they form Xamarin and in some serious negotiation, get those bits away from Attachmate and make this new company that says, you love C Sharp, go ahead. And it's brilliant. It's brilliant. It's very challenging. Of course it is challenging, but if you know C Sharp and you either know or can figure out XAML, which of course you can, then you know everything you need to know to get started building mobile apps that run on iOS and Android. Well, I believe that more today, but in 2011, 2012, you know what it felt like to me? It felt more like. Right, that was before they had Xamarin Forms. Yeah, before Xamarin Forms came along. If you knew. You had to learn the platform. You could take your business logic and write it on a different platform, but you had to learn the UI and then you had to learn underline. You had to learn under the platform. To a much larger extent. Well, and I hate to compare it to web forms, but the same kinds of traps. You know, web forms is original intent going back to 2002 was to take a group of WinForm developers and give them a similar experience on the web by abstracting the web's behavior from them. And that had consequences. I mean, it made a very smooth path for those developers to remain productive. But as we started to explore into the web world, pretty quickly web forms hit some rough patches. And so, you know, I made a lot of money cleaning up web forms apps. And generally speaking, I could open the conversation with congratulations, you have a good problem. Enough people are using your app that you care about the resources it consumes and the speed that it runs at. If nobody was using it, it would work great. But there's so many people using it now, we've got to think about it a different way. And I think you were running into exactly the same challenges here where we have to remind ourselves as programmers that our programming environment is not just language and it's not just tools. It is the runtons. And it is the library sets. All of those things matter. You know, for better or worse, .NET took a lot of conversation we used to have in the 90s off the table. You no longer were selecting a library. It's pre-selected for you. It's the framework. We're no longer even selecting base class libraries. They're pre-selected for you. And as soon as you jumped out of that pool, a lot of those questions got back on the table again. And we, in some ways, we'd forgotten or we may have never known.  And so when the world diversified on us, when these platforms expanded, we had to learn some new things. Yeah, and you got to the point where you didn't have to, you didn't really spend that much time thinking about what was part of the base class library and what was part of the C-Sharp and VB language. It didn't matter because you're just typing words. And whether that word lives in VB or .NET, that's interesting. It kind of tells you where to go, look it up in the docs. But at the end of the day, who cares? It's just a word-eyed type.  It's like, as long as it's only code, if in the midst of that you have a call that happens to append on a framework piece that actually calls to a Win32 call, you're going to have a problem with that call. And you, again, didn't need to think about it when you were living in the homogeneous world of it's windows all the way down. And in the heterogeneous world of this set of platforms, those conversations are- And you learned that, you certainly learned that when you, if you started doing Silverlight, you certainly learned that if you started doing anything on phone that there's a sandbox. You learned the concept of the sandbox. And a restricted feature set. XAML was much more simplified. Which is basically the universe of things that you can do. And a lot of them made sense. And a lot of them, you may have wondered why, but it's just a fact, Jack. It was sort of, we're dealing with some reality for you. Maybe we're still trying to protect you from some pieces as much as you can. But there are limits to what any of that stuff can do. Right. And in some cases, it was easier to jump all the way out and go, I'm just going to go native and learn all of those things again, you know? I don't know. I don't know, man. Have you ever, you've seen Objective C. Oh, yeah. It's not easier. But remember that Objective C was never meant for public consumption, right? Job said, if you're going to program on the iPhone, you're going to program a Safari. And what he was anticipating was HTML5 in 2007. He was years ahead of where the actual standard implementations were. And the only reason we ended up with Objective C is the phone got jailbroken. That the hackers wouldn't wait. We're going to program the way we want to program. And to sort of not lose control of his platform, they released their internal tools, which is why they were so terrible. They were meant to only be internal tools. And then the App Store became a necessity, you know, with maybe a billion-dollar business now. But back then, this was just them trying to keep control of the product and emerged a field, you know, that everybody now had to have an App Store. You know, Swift is far better, far, far better. It's still not my favorite language. But I can respect a cleanly written fresh language that is terse and clear, right? I got no complaints about that. But that's... But I love the fact that I don't have to learn that because I already know C-Sharp. Sure. And... As long as you're willing to learn the ins and outs of the way iOS should behave and... Of course. Of course. ...wherever you're going to hit those edges, then you can be successful. Right. And even if I decided to write native Mac UI and native Android UI, I still love the fact that I don't have to learn a new language. Right. Well, I also like being in a project. It's a project that, you know, when you talk about broader strengths of strategy, the idea of my project that goes to iOS and Android is literally the same project. When I write that feature, and it's 80% common code and 20% platform-specific code, but when we hit, when it hits the CI pipeline, it's going to both devices. Yep. So I've also seen plenty of organizations where the iOS team... There are all three devices. Yeah, three or four, how many devices make you happy? When the iOS... Well, if you're doing Xamarin development, even if you're not going to release the app on Windows, Right. You should have the Windows 10 project because it's the easiest way to test it. Sure. Well, it's certainly a quicker iteration around. You don't need a device. You don't need an emulator. You're already on Windows for no other reason than to make it easier to test you should do the Windows 10 project. No, I'm not going to argue with you. It's completely reasonable. But I've also seen plenty of organizations when they're working in native and they've got a strong iOS team and their iOS team is out running their Android team and new features appearing on the iOS device first and it's making customers angry. Right. And so I think part of creating a common pipeline for all mobile features that's going to build to all of those devices is that you maintain feature parity across the devices. Right. And I think that in the broader scape of not just I want to program my thing, but in the how am I taking care of providing value to my customers, that strategy is actually stronger. Right. And then you don't have to write the exact same code, the exact same features multiple times. Exactly. Right? Yeah. The SkyDrive, back when it was SkyDrive. Pulling out these old names. Next, we're going to talk about Metro. Oh, God, purposefully wrote the iOS and the Android, the Windows versions, all 100% natively for the best experience. Yeah. Although now I think there's Amaranabs, now that it's OneDrive. I think OneDrive is the Amaranabs. Yeah, I don't know the answer to that, but I appreciate that. But again, it's like how you, if in the broader scheme of actually taking care of my customer, maintaining feature parity is incredibly important. Mm-hmm. And so whatever tooling can do to help me that, to the other thing that I found I really appreciate about Xamarin as we spent time with it, absorbing the Android variations. Mm-hmm. Now it's not as bad as it used to be, but back in like the Froyo era, where you, and even when we were first playing with Xamarin, Froyo was still hanging around and it was like IE6. It was this old version that missed a ton of features, but a whole lot of cheap phones ran it. And so it just wouldn't go away. And the fact that Xamarin would absorb a lot of that, you wrote far less Android version-specific code, I thought it became a hugely high value proposition. So what role does, what does .NET Core fit into this? So there's an interesting period as the cloud emerges and as Scott Guthrie moves over to the cloud and the web team went with him. So while Win8 was gestating, and it was a big part of the .NET team that was involved in all of that and they were trying to make Win8 what it could be, there was this sort of isolated group off on the side and they were focused on Azure. They really weren't focused on operating systems. And a lot of the early experimentation into other ways of doing momentations should come from that. The open source movement internally to Microsoft been going on for some time. My best evidence of the sort of the first stages of open source coming into Microsoft back in 2007. NVC was really meant to be open source all along and it ended up a codeplex. Yeah. So we had these early activities already going on. But it's not, and then the same thing, you have the web team working on stuff to really support Azure and the evolution of Azure. The first incarnations of Azure, 2020, 2009, 2010, the funny part now of looking back on it because it was a struggle to use was they were proposing serverless. Web roles and app roles, right? Very off the bat. Now admittedly you paid for it as VMs, but the architecture was very serverless. We just weren't ready for it and it had its issues. But as Guthrie gets involved and Azure starts to transform, we start to have more of the websites, models and those sorts of things. It's this team that works a lot of that and that's where those early bits start to come from. It's not until sort of a post-Win8 world and Win10s being worked on, so now you're 2013, 2014, and Sachin Adella moves from the Azure team to the CEO role and Scott takes his position that you start getting all of those pieces together and saying, can we really do this? This makes sense. And so that that spawns up the .NET foundation and VS Code, those bits actually come first that we're starting to have more routine work by Microsoft folks in the open source community on a regular basis. The core doesn't actually appear until 2016, although it was clearly being worked on as far back as 2014 as Project K. So as a runtime, what role does it play in the world of development you see? Well, it's still early days for the traditional, for a .NET developer that's been working on .NET since the initial incarnation, so one, 1.12, especially if you were doing desktop work, the .NET course is still not on your radar in some respects. If you're a web dev, or more importantly, a modern services developer, so you've embraced web API and you've sort of liked building in that space and you've always had pressure from your organization that we'd rather not be running Windows on all of these things, then that opened the door for you. It's like, well, what do we need? What moves across? And .NET Core 2, which was the third version of .NET Core, just like the standard framework, because version numbers are hard, was really had enough of the feature set that you started really saying, okay, I can take work I've done and move it there, it makes sense to build forward, it's not gonna hurt. So it runs on Linux, it also runs on Mac, but importantly, it runs on Linux servers. So if you are now told we're getting rid of our Windows servers or we're gonna run Linux servers, you get to not be completely out of luck. Well, it's really, for running in VMs and we're paying licenses and our compute costs are relevant, the number of transactions per dollar, you can make some real improvements there when you look at Nginx and running in Linux VMs. It depends on your architecture. Of course, all of this is being disrupted by containers again too. So if you're at the edge of all of this, you're already pushing on what's next.  Well, containers, I mean, it's still true that a Windows container using .NET is about, relatively speaking, is about this big and the .NET core container can be about this big. Much smaller. And also .NET cores is dramatically faster, ASP core dramatically faster, right? Depends on what it's running on. I mean, they've done some great optimizations there, but you're also working on a narrower feature set. I got nothing to complain about. I built a lot of .NET standard websites that ran pretty well. It is easier to make lightweight fast websites in a Linux stack with core, because it's just a smaller surface area for you to tune against. The battle of the Windows container is nowhere near done. Like Windows containers are only just starting to get good. The announcements out of Ignite this year, now we can sort of circle back. For most part, when I find folks that are using containers for anything, they're using Linux containers. And they might be using .NET core there, but I think that's where the win is. I'm looking forward to late this year and sometime next year, seeing what .NET 3 looks like and based on the announcements at build, where we're going to start getting new versions of desktop-related SDKs that are meant to work against core. They're not part of core, because core is cross-platform, and there doesn't seem to be any conversation right now about a win forms for Linux, because that'd be weird. Isn't that Xamarin forms? Yeah. But interestingly, you started trying to rationalize XAML into a standard to sort of talk about what does that really look like, and you got to look across that in the first year. The first thing you'd need to do is rationalize XAML into a standard, right? Yeah, XAML was so many. My favorite line when Silverlight was new, when it was WPFE, we had Rocky Lottkern. And we're talking about how WPFE seemed to be taking off where WPF never had. And he said, the reason is that web developers are used to lousy tools. That we never had a designer for XAML like we had a designer for win forms. And so this iteration of I write a little code in XAML, and then I flip to an emulator view of it back and forth, web devs get that. Sure. Desktop folks are like, this is archaic. What are we doing? Like, what a waste of time. But now all these years later, when you're totally used to writing XAML by hand, right? Which we're in a different place now. The question is, if a designer was invented, would you use it? That was pretty good. Would I use it? I'm betting no. I don't know. Yeah, I'm betting no.  And no tool ever do a good enough job. Ever, ever, ever, ever, ever. See, front page dream weaver. I don't know. Like now, the machine-generated HTML, same problem. I think the- It depends on how well it works. Well, yeah, that's it. But it'll be a younger generation of devs. Says the man who thinks right click publishes a great invention. But it'll be a younger generation of devs. So Einstein writes the general relativity theory. And all of his contemporaries, all the senior guys, they don't like it. It's pretty weird. They're arguing over details on it and so forth. But the younger physicists are all over it. This is great. This helps all these problems. So we can explore astrophysics in another level and so forth. And a reporter goes to Einstein and says, you know, you've got acceptance from this group. You don't have access to that group.  And Einstein says, first the old physicists have to die. Right. And so we could go to design model of XAML. That's really great. But first the old developers will have to die. Yeah. Like the folks who got good at that other technique are going to resist it, right? Change is hard and they're productive as they are and they will find reasons not to use it. And then my experience with Microsoft over too many years now is you'll let them, right? That they will continue to be able to work the way they want to work. And the other guys will work the other way. And if those other guys can out compete them, bully for them. It's also, I think, much harder to do a good XAML designer. Hugely hard. Than everyone else to do a good windforms designer. Well. Windforms was absolute positioning. Yeah. I want this button here. Period. End of story, right? I don't think it's only that. So how hard is that? It was also. That was one of the things. It's certainly one of the things. But the other aspect of windforms is that we had strict design guidelines. File goes here. Help goes there. Toolbar goes here. And we've just never had that for XAML because XAML, arguably XAML punted. It's like, what would you like to do? How about a carousel? Like you have all of these choices. And so if you were really going to go down the designer path for XAML in a serious way, you would have to start thinking in guidelines that you're going to force people to fall into the pit of success. Maybe there's three or four or a dozen different templates, but you're going to follow certain metaphors. But we did come out with the metro guidance, right? There's UI guidance that came out starting in Windows 8. And there's fluid design. And people now have guidance. We have more guidance. I wouldn't say we have guidance. I'm going to qualify that. There are guidances. But there's the ultimate manifestation of guidance as tooling. So if we really have guidance nailed, we will have a set of tools that basically get you to follow that guide, perhaps even against your will. I don't think we're there yet. I think we're better. But there's a possibility there. Is it late? Might be a little late. Might be a little late. That's always a good question. There's almost a history of XAML that I can do. One of the problems I've got with this book now, and I'm 70, 80 hours of interviews and research in it, and I feel like I'm less than halfway. And I still, you know, there's a lot of stuff up here. It's not going to be one book. I'm going to write the book that everybody wants, right? That sort of overarching history, sort of the politics of motion and so forth, like definitely going to do that. But when I talk to people about the history of .NET, they see it through their lens. Of course. If they're a web dev, they talk about the web dev stuff. That's like writing the book on World War II. Yeah. You can't do it. And I'm not going to. I'm going to start with one. And if it's desired, like a history of XAML is not a bad idea. A history of Microsoft web dev, not a bad idea. It's a companion to the overarching story. But, you know, I've been gathering up screen shots of all the old sample apps from the earlier versions of .NET. And I could almost do a coffee table book on that. The pictorial history of Fitch and Mather and Adventure Works and North Wind. I will do, if you could do a coffee table book, I'd love to do it. We'll do it here if you want. Come on this show and we can run. Run them all? Yeah, run them all. I love it. Think about that. It'd be hilarious. Yes. There's still, there's folks out there that made videos that were like running every version of Windows. What if we could do it every version of the .NET sample apps? And then what we will have is, you know, folks can play along. You get a point if you remember that app. Right.  And if you haven't seen any of them, you know, then we'll come up with pithy ways of describing. I am not opposed. I mean, I'm enjoying gathering this stuff. I'm finding insights in them. There's multiple ways to tell a story. So I am not confined to any particular media, timeline, or architecture. I will try them out of the sport. Well, I know we're supposed to keep episodes to 30 minutes, but we're at 50 now. So I think this is a good place to stop in a moment. Hopefully you guys enjoyed that, kind of a whirlwind overview of a history. It's kind of just two old guys sitting around chatting. One we've been in and still enjoying. Yeah. And at the moment, show no signs of quitting. No. Thanks so much. Good to spend time with you, friend. Hope you enjoyed that. And we'll see you next time on Visual Studio Toolbox.


next we will try to color android kernels that is mostly we will color the driver part in kernel so within these five topics we are going to cover first is android system architecture that you will are familiar with this architecture then we will see a runtime work through so how android system boot and what are the services will start from the booting process to the till system will get up to work and then we will see for that binary driver that is inter process communication mechanism in android and then layer interaction so those four layer are there application, application, framework, libraries and kernel layer so how they are interactive when some system is running some application or try to access kernel driver and then last we will check it power manager that is also power management driver in android system so you are all familiar with the architecture so mainly we will focus on this Linux kernel part so Linux kernel now some different different drivers so apart from that Linux kernel we also need some other drivers because we are using this android system we are installing mobile phones or some other tablet system so we need camera driver, wifi driver this flash memory driver, audio driver and binder IPC driver and power management so these two binder IPC driver and power management is major modification in the Linux kernel driver so what is android kernel so it is not fully, android is not fully Linux system it is just realized in Linux kernel 2.6 so why we are mainly using the Linux kernel because it is already provided as process management then memory management, then security and the network state so this kernel is basically layer between hardware and software so this is the reason why we are using Linux kernel so it is already contained in memory management and process management so we don't need to create the same code for android also and this is permission based security model so we are familiar that we can provide permission to group user and others also so then Linux system so the same thing we are using in android also and the main use is support for same libraries so those library part will cover that question so in this we are sharing the library between different application so these are the main modifications are made to Linux kernel first is binder driver well smem that is android share memory driver that is sharing between two different applications how they are sharing memories between two different applications then alarm driver, power management memory killer kernel debugger and logger that is already explained more layer is that that is hardware abstraction layer so this is the what hardware abstraction layer is providing it is providing the libraries these basic libraries are C and C++ libraries so then it provides the interface of the libraries to the Linux kernel now why we need this hl layer so it is the big first one thing is that not all companies are familiar with standardized kernel driver so some need to some modification then only it can communicate with Linux kernel so at that time this hl layer will be useful and then add some hardware specific requirement are there at that time this hl layer will be useful now we will see the runtime work through so how the system will boot so android booting is a similar to linux booting when you will put it power on your android device so boot loader will load linux kernel linux kernel will start the first process which is init this init then will start the other demons like usb demon then android debugger debugger bridge demon and debugger demon and radio interface layer demon in this usb demon is just like usb and there is android debugged bridge demon so this is the mainly when you are collecting your device through the computer at that time this android debugged bridge demon will be used and this debugger demon is mainly involved when your application throw some exception or some error at that time this demon is used radio interface layer demon is just like your sim card or that radio interface will be used once this demon is started init will start zygode now what is the zygode so basically application has run on delvic vm so whenever you start application each application will be done delvic vm will be started so each application need delvic vm so if you start delvic vm each and every time so it will create some sort of overhead so what we are doing we are putting zygode process which will do clone of the delvic vm whenever it will start only once then it will put clone and then clone will be used by application so this is the delvic vm install it will initialize then it will link all core libraries so zygode is linked with all core libraries so whenever application will stop it will allow it will link application to this whole library and say the library is on application so those are sharing libraries so initially when application will start it will not create some different memory space for those libraries it will save it and whenever application try to run those libraries at that time only it will use copy and write and it will allocate some other different memory for those libraries now once zygode process is started so it will start run time process that is ended run time and then it will start the service manager basically the service manager is the complex manager for the binder handle service once the service manager is completely started run time will inform the zygode to start the remaining system then zygode will create start the delvic vm and it will start the system those system will later on start the surface failure that is our surface touch on the mobile device and then audio failure so these are main driver parts so those are now started and after this they are providing some sort of services to the other application which we are creating and we are using so for those so those application can use this surface failure and audio failure surface failure and audio failure to register their application to the service manager so they are registering their services to service manager and later on this binder will come in picture when you are using these services so once this is done then system will start the remaining manager there is window manager, activity manager, package manager those are collected with window manager is managing the windows which are open once they started they also need to register their services to the service manager so they will register their services to start some application so now you open the menu on your mobile device so how it will work so this is the way it will work so zygote will claim that Dalvik VM other than Dalvik VM the whole will run menu list it is there in each and every process so lipsy are linked in each and every process through zygote itself starting another application so same way zygote will claim the VM and between another application you will get delvik VM and one more thing is that to reduce the starting time zygote will whenever new application will be started the memory clone will be done by zygote so application memory structure and zygote memory structure are almost same so first of all the ITC list is interversal communication so what is the ITC so you are exchanging data with some other application like you have some application which is going to get some GPS location so the GPS location will give your data that location of your mobile device to your application this is the exchange between two different applications so this is the interversal communication so why we interversal communication need so we cannot directly your application cannot directly call to the GPS location dial up because each application running in all address space so they cannot access other application memory area so for that we need interversal communication then what is the data isolation so isolation is there through providing normal memory address space and use of the ITC will interact sorry it will direct interaction with the application so it will avoid some sort of hacking when you are trying to some application GPS location it will modify the location your mobile will show some right GPS location so this will be avoided normal normal line up so what are the IPC mechanism are there first of all is signal just as simple oldest mechanism it is one process will use some specific signal and those signal are different some 5 type of signal I have suppose I will get this type of signal type 1 then I have to do this type of work type 2 then I will do this type of work so they say just some sort of signal like it is similar to we can say some type 3 then left is a pipe that is an undirectional channel you need directional channel so that is only one way to communicate if there is a pipe channel between server client and server so either client can send data or server can send data both of them are not able to send data so if you want to communicate bidirectional then you need 2 pipes same process then next one is socket that is the bidirectional client will open the socket on server side both of them can use that socket to send and receive the data then next one is semaphore it is just a variable semaphore can be like a file descriptor you are sharing 2 application are sharing same file and they want to use same file descriptor can be a semaphore or may be some pointer where pointer is pointing to some area or location so at that time the pointer can be semaphore so that can be shared between 2 process now next one is the message queue so in that message queue is as simple as you have one message queue client is writing and server is reading after some time server is writing and client will read those things then next one is shared memory you have some shared physical memory are there which is allocated by kernel bug that server will allocate those memory and same thing like as a message that client will write data in that shared memory and server will read and some other specific location where server will write and from that location client will read data so and now what is the IPC mechanism in the android so android provides the binder that is the lightweight no-procedure core mechanism why we need to create this binder driver for IPC mechanism so what was the problem with old mechanism application server may run in separate process but communication must be must communicate and save data so like if you are using semaphore so you can just save variable you can save a bunch of the data so at that time this you need and IPC can and those old mechanism are providing us some sort of overhead so when you are communication is you are communicating with server at that time overhead will be high so to avoid that we need binder driver the solution is provide some driver which facilitated inter process communication so those facilities can be provided by same memory location same memory one more thing we can create is that on server side we can create a pool of thread pool which will reply to each and every request individually so suppose like if you are using socket that is for inter process communication mechanism so suppose a client will connect to the server so 100 client are there each and every client will connect to different different socket so it will need 100 socket so server will need to manage this 100 socket that is quite difficult than managing the 100 thread next is reference counting if your memory is so the reference counting how much client is referring to this memory memory page is quite easy to refer and synchronization is called between process so how the synchronization will not good in IPC mechanism so suppose you are connected with socket or pipe with server so whenever you are writing at that time server can also be writing so whenever you are writing some paragraph in middle of that server will reply so that is not synchronization so in this in this diverse facility what we are doing client will call the server we will client will wait and then server will reply after that client will again call the server function so caller and caller both are in same process so at that time we don't need to worry about those inter process communication mechanism because they can create their object because in same process and they can use their services so but what if the caller and caller both are on different process so how can we create how can we provide the inter process communication so for that we need interface so how we are creating so basically we are creating the proxy object we are creating caller side and we are creating stop object this proxy object is just a proxy like we are using a network proxy that is we are collecting to the internet so same way this client caller we use proxy object to collect the the query and this stop object is directly collected to with the server which is going to the server function which client will use so this proxy object will call the binary driver that is in kernel and the kernel will pass the relative to stop object and stop object will reply to the kernel and kernel will reply to proxy so this is the small interaction between two processes so here is process one and process two is the client and process two is the server so process two providing some service implementation or process one want to call the function of the process two so how they are using how IPC work here so process one will inform the service manager that I want to use this service this interface so service manager will return the object that is the proxy object to the client process one and using this call interface that proxy object it will call the proxy proxy stop stop object that is in the process two and the stop object will directly use the server implementation so this is the blue line will call it this directly so how it is client will go to this proxy object will interact with stop and then stop will interact with server implementation so this way how the client will get service from server so some sort of more detail in how binder will exactly will work so the binder will provide the binder object that is the interface to access to the remote process and the binder protocol that is some protocol to communicate with the driver so how the driver will work which driver will reply so that is the main protocol then I binder interface this is the thing which is returned by the service manager so I binder object will be returned to the client and client use this I binder object to communicate with the remote procedure then binder token each and every binder have unique identifier that is called binder token so this is the binder this whole facility are provided binder so binder is not providing interface as communication so what can you do with binder so first we indirectly so by using binder you can pass the share variable and you can pass the memory location and you can share the memory between two different processes then what is the direct implementation provided by binder first one is the notification so notification are attached with the binder that is a link to depth so this notification will occur whenever the binder process will get killed so at that time the manager will say manager will send the binder that is collected with those that binder that your binder is get killed you can re-collect it or you can wait it so this may be notification purpose is used by windows manager so like some windows is open which is providing some interface and those interface are collected with binder suppose your binder is get killed so still your window is there but that window manager will implement that window that you can turn off so the notification is by windows manager then calls so we can call two way synchronize synchronize is two way communication so once you client call the server and it will reply it will get suspended reply reply from the server so that is the two way communication and one way communication is possible just client will inform the server I have written some data you can read it whenever you want so that is done and client will do other work so that is one way and two way communication will also done the binder then identify so in this thing whenever client will collect to the server through binder it will send the data so in that data client will put it's ID vlick ID so that is the vlick ID server will get and it will identify client whether it is authenticated or not so therefore that personal binder it is useful then managing all the memories said thread reference count so reference count is just how many client are referring to the binder some boundary space so now how binder will interact with service manager so first of all first step is to when service provider it is our server will start it will register itself to the service manager so it will register every service at the service manager side and the service manager will inform that about registration into the binder driver now when arms are when client can use the service so client do not know exactly memory address there is address of the remote binder he know only interface client cannot directly communicate with the binder so he know just interface so it will first go to interface that is the service manager so client will ask for the great service and that service manager will inform the binder for the service and binder will reply the name and address of the interface so that will pass to the client and client then directly will use that those address and interface to communicate with server so now the binder implementation so binder is implemented mainly in a by 3 layer first is our API for application those we are writing in java that is 3++ and then kernel that is our binder so first of all it is API layer so in application layer mainly we are using AIDL AIDL is interface definition language so what is exactly this task task is to facilitate implementation of Android application so it make it easy so whenever we are writing some java file java file also after writing the java file AIDL parser will use and this parser will create the class file so this class file will use 2 space one is proxy side that is a proxy object it client and then use for stuff class that is a server side so here this AIDL that is a proxy object and the stuff class so now that java API those API will try to cover the middle layer so we try to reduce the hmas work on middle layer that is c++ so now how to communicate with server so transaction is data from one process to other is called transaction so what is the parcel this data send over the transaction is called parcel so data can be bunch of the object or maybe some other extra variable like integer or some other so all together will create a parcel so now we want to send this parcel to the server side so what we will do we will do marshalling that is the building the parcel so we will create a new object that is called parcel and we will send to the server so this is one example of the parcel so when we are defining the target then binder driver command which command we want to run on this binder then cookies that is used for communication between the client and server then server ID so client will identify himself himself to server then data data will contain a bunch of objects so parcel is just container of data and parcel can be contain floating data that is a marshalling data and it may be possible it contains on marshalling data so whenever you are doing marshalling through some using some mechanism binder will send this thing to the server side and server will on marshalling this data and it will use that data so to create the parcel that parcel class is there which will help to write your data in the parcel so some methods are there write stream which will write in the parcel that is provided by parcel class now the next one is wooden layer so it is implemented in c++ and it will provide the interaction between there is a that application layer and the to kernel layer and that marshalling and marshalling will be provided through wooden layer kernel data will provide some sort of the system called that is operation open and some IOCTN operation system called to IOCTN basically that control a stream device so you have some devices there I don't know exactly which type of how it is working but it will help try to control some devices so what is the difference between the binder driver and the Linux so in binder driver server will maintain the status per thread whether status is running or not that thread is suspended thread will wait for high so that status is maintained by server and in Linux socket we are maintaining the status of the socket socket are used or not if it is not used so how many duration when last last use so this is the binder driver come in picture so what is the application process will ask context manager context manager is basically service manager where the whole provider has registered their services so it will ask for service that is good service and it will reply so now it will once is reply interface now it is used as interface and it will call some function to the function with some argument so this will pass to the binder driver will do marshalling stop and it will pass to the pass to the thread at the server side that thread will do un-marsalling do some process and reply to the client so this is the cold wind return now what are the limitations of the binder IPC so binder use the binder use the command to communicate over the between two different processes so we are not interacting it directly we are indirectly we are interacting so it may be possible somewhere we need to access their name and boundary pages directly at that time this binder driver will not useful and second thing is that since we are doing that marshalling so that marshalling and un-marsalling is some sort of similar to the encoding and decoding which we are using in a network when we are sending a packet so client will encode the packet and it will send to the server and server will decode so same way we are doing the marshalling so if you want to send large amount of data at that time this marshalling and un-marsalling will create a overhead so that is the limitation of the binder now we will see the layer interaction so how basically this layer will interact with each other so there are only three way to interact interaction first is the application layer which will talk with the runtime services and runtime service will communicate with the libraries that live see another one is application will communicate with the runtime service and runtime service will communicate to live see and third one is application will communicate with runtime service and it will communicate with native domain and native domain will communicate with live see so domains are basically those processes which are running on the ground which will not directly interact with user so which interaction you are going to use so it is basically depend on the application and libraries so which are the easiest way which will give lowest overhead so this interaction we are going to use for those interaction so basically our application and application framework those two layer are written in java and libraries and this kernel part is written in c and c++ so how go java will communicate to the c++ so in the meantime this java will come in picture so java native interface which will define the name coding and conversion so that java vm can find and code the libraries and that is as I mentioned mainly it is the bridge between the application framework and the library so java class can use those c++ library and they can so first layer interaction so in these three application will call the runtime services so application is running in application one which is top of and the runtime service is running in application framework so at that time bounder IPC will happen so this is just directly shown the initially application will first get services from the service manager and service manager will do replies to the interface and then application will communicate to the runtime service so this will happen then runtime service will call to the native service which are running in the libraries so here we are moving from application framework to library so we did jli so here jli will be useful and then runtime services will use that rrfxn layer library so this is the initial initially that one layer is there between this library which is providing some c++ tab and some easy interaction with the kernel which are not separated direct interaction so at that time hl library will come and so native service will call hl library and hl library will call kernel-dialog so here is the example application application will get interface through binder IPC mechanism then application will call the co-manager that is service provider of the location then this location manager will ask for interact with gps provider so this is the runtime service part then this runtime service will communicate with the service so this is similarly native service and then hl library so here is our gps location provider so that is our native service and libgps that is our library provided by hl layer and it will call to the kernel what is the main so in this thing what is the application runtime first it will call the runtime service runtime service will interact with the native service then it will go to the native service part and hl library and then it will communicate with kernel so here is the difference between the previous method and this method is that binding binder IPC in this case binder IPC is happening here so native service will get the interface for the native service binding will get interface for native service and it will call native service and it will use hl library and it will call kernel so what is the example is media player so one application will call the media player so media player will ask that audio player there are libraries which are used for audio it will call audio player in the library this will use hl library and it will directly interact with kernel driver so this is the application called runtime service and it will go to native service binding and native service binding will call demone instead of native service it will call demone native service use hl library and it will go to kernel so this is the example for a telephone when you are using telephone means you are trying to call or receive some call or sending with a message at that time this telephone will open so application will call telephone manager telephone manager and this will call telephone manager will call rild that is radio interface lower demone that is started and it will start so it will interact with this is the demone and it will call hl library and hl library will interact with kernel last one is power manager first one is advanced power management that is the simplest easiest and it is the coldest bias based power management so concern configuration are there in bias if you set up and your monitor will get off that will done in line up and second thing is advanced configuration power interface in which you will can do some more configuration which is useful so basically scp is far better than apm and what android we use android is not using neither using apm nor using acp instead of that android have their own power extension cold power manager so how power manager will work so basically your device is limited battery mobile device is only limited is only desktop as infinite battery so which thing you can control in your mobile device so mainly first thing is come is your screen so if your model is ideal for a few 5 second your screen will be off so at that time you can save power and the keyboard light suppose your model is with keypad and at that time your keyboard you are not using key so keyboard light we can put it off so this way we can reduce the power in mobile device so this is power so we are using so weight lock is some sort of the signal which we are sending to the power manager and power manager will interact with the hardware so there are different other weight lock are there partial weight lock in which we are keeping CPU on obviously we will keep CPU on each and every weight lock so we will put that screen and keyboard light off then we will ask for dim screen at that time we will start the screen in dim mode and then drive to a screen and then we will completely start our screen and then full wake that is we are putting screen on and keyboard light also this is the state machine for power manager so how power manager will work suppose power manager in screen off state so if some user activity will happen then screen and bright will be done so screen will start using full power and when user activity continue then we will be in screen bright state suppose the screen will be ideal for a sometime at that time in after 5 seconds suppose the screen will get dim at that time we will get screen dim mode suppose at that time when some user activity will happen then it will go to the screen bright mode state when we are in screen dim mode and dim dim mode is done which you wait for 10 seconds still user is not interacting with your device so you will put that your screen that is screen off state so here is the application we will sell the weight lock that is partial so you will put the screen off then power manager will inform the driver and the driver will create a new weight lock and it will put it screen off LCD is off here after once application is done its work it will release the weight lock then power manager once it is done power manager will inform the driver and nothing to run we will put CPU off so we don't have any other application so we will put CPU off this reference is good this internal philosophy and android so this youtube one video is there for this one if you want they have described very well how the android internal will work so this is the good reference for the beginner from the android team itself there is android team itself any question that is just one pdf is given that serve on android versus linux when you search on google and you will get some pdf in just pdf they describe which things are modified in linux and this is one also good pdf inter process communication so it is very big around 35 pages are there so they have mentioned each and everything quite in very very detail thank you


Hello, and welcome to this presentation of the STM32 tamper and backup registers. It covers the main features of this peripheral, which is used to ensure security protection against physical and environmental external attacks. The TAMP peripheral features an ultra-low-power anti-tamper detection, which runs in all low-power modes. Additionally, the TAMP is functional even when the main supply is off and the VBAT domain supplied by a backup battery. The TAMP block embeds 128 bytes of backup registers used to preserve data when the main supply is off. These backup registers can be used to store secure data as they are erased when a tamper event is detected on the tamper pins. In addition, the backup SRAM is also erased when a tamper event occurs. Three external events can be detected with three different configuration modes depending on the security application requirements, and six internal events can be generated based on embedded monitors ensuring protection against environmental attacks. The TAMP registers can be configured to be protected against non-secure access. The key features of the TAMP are 128 bytes of backup registers split into 32 32-bit backup registers. These registers are preserved in all low-power modes and in VBAT mode and are erased when a tamper detection event occurs on any one of the three tamper pins or on the internal tamper monitors. Up to three external tamper events are supported. The modes of these tamper events can be configured either in passive mode or in active mode, allowing either three passive tamper pins and events or one active tamper plus one passive tamper event available in all low-power modes and VBAT. The passive mode can either be IO edge detection or level detection with configurable filtering and internal pull-up, which is the lowest power tamper detection mode. The anti-tamper circuitry includes ultra-low-powered digital filtering, avoiding false tamper detections on IOs. Each external tamper event can be individually configured to erase or not the backup registers and backup SRAM. Six internal events from various monitors also erase the backup registers and backup SRAM. The tamper events can generate an RTC timestamp event. The Quad-SPI interface is fully compatible with the one available on the STM32-L4 and STM32-F7 series, allowing a straightforward reuse of applications developed on these devices when this interface is managed by the ARM Cortex-M4 core. Here is the TAMP block diagram. The TAMP has two clock sources. The first one is the TAMP clock, RTC CLK, which is only used for the tamper detection in level mode with filtering and for active tamper detection. The second clock is the APB clock used for TAMP and backup registers, read and write accesses. Tamper's edge detection or internal tamper's detection do not need any clock. The TAMP clock can use either the high-speed external oscillator or HSE, divided by the RTC-DIV divider in the resetting clock control from 1 to 64. The other clock sources are the low-speed external oscillator or LSE, or the low-speed internal oscillator or LSI. Only LSE or LSI are functional in stop and standby modes. Only LSE is functional in VBAT mode. Several internal features can generate a tamper event. The temperature monitoring, the VBAT voltage monitoring, the LSE monitoring, the HSE monitoring, an RTC calendar overflow, and the monotonic counter overflow. By default, all tamper's detection will erase the backup registers and the backup SRAM. The TAMP registers are write protected to avoid any possible parasitic write accesses. First, the disabled backup domain protection bit must be set in the power controller control register in order to enable TAMP write accesses. The TAMP supports trust zone protection against non-secure write access. The protection can be set for the complete TAMP registers except backup registers by clearing the DEC PROT bit in the TAMP secure mode control register. The TAMP registers protected with DEC PROT can be read with secure and non-secure access. The backup registers have their own protection setting. The backup registers can be split into three protection zones. The size of each zone is configured by software. The protection zone one is protected against non-secure read access and against non-secure write access. This zone starts from backup registers zero and ends with the register defined by the BKPRWD PROT field in the TAMP SMCR register. The protection zone two is protected against non-secure write access but can be read with secure and non-secure access. This zone starts from the register defined by the BKPRWD PROT field and ends with the register defined by the BKPWD PROT field in the TAMP SMCR register. The protection zone three is not protected against non-secure access. This zone starts from the register defined by the BKPWD PROT field in the TAMP SMCR register and ends with the last backup register 31. After a backup domain power on reset, all TAMP registers can be read or written with secure and non-secure access except for the TAMP secure mode control register which can be written with secure access only. The TAMP protection configuration is not affected by a system reset. Accessing a secure protected register with non-secure access is done in silent mode. The read protected registers are read as zero. The write protected bits are not written without notification. As soon as at least one function is configured to be secured, the RTC and TAMP reset and clock control is also secured in the RCC. The TAMP features an ultra low power tamper detection security. The purpose is to protect the device content and functionality against external attacks. This is required for secure applications. In case of intrusion, sensitive data are automatically erased. Three tamper input pins and events are supported and are functional in all low power modes and in VBAT mode. Two output pins used in active tamper mode are functional in all low power modes and in VBAT mode. In the default configuration, the backup registers and the backup SRAM content are erased when a tamper event is detected. Each tamper event can be individually configured to not erase the backup registers and the backup SRAM. In this case, the software can perform some checks to discriminate if it is a true or a false tamper event and then decide to launch the backup registers and the backup SRAM erasure by setting the BK Erase bit in the TAMP CR2 register in case the tamper event is confirmed to be real. Passive tamper can be configured either in edge detection mode or in level detection with filtering mode. In edge detection mode, it is possible to configure the detection on the rising or falling edge. In level detection with filtering mode, the internal IO pull-up is used to detect the anti-tamper switch open state. The IO pull-up is applied only during the pre-charging pulse in order to avoid any consumption if the tamper pin is at a low level. The pre-charging pulse duration is configurable to support different capacitance values and can be one, two, four, or eight RTC clock cycles. The pin level is sampled at the end of the pre-charging pulse. The tamper detection circuit includes an ultra-low-powered digital filter to reduce the risk of false tamper events detection. It consists of detecting a given number of consecutive identical events before issuing an interrupt to wake up the device. This number is configurable and can be two, four, or eight events at a programmable sampling rate ranging from one to 128 Hz. This figure illustrates tamper detection using the internal pull-up. The internal pull-up can be applied for one, two, four, or eight cycles. If the switch is open, the level is pulled up by the resistor. If the switch is closed, the level remains low. The input voltage is sampled at the end of the pre-charge pulse. The tamper detection can be configured in active mode for a higher security level. The passive tamper detection just checks a static level. So if the attack manages to short the tamper input pin to the inactive state, the tamper event will not be detected. The active tamper is able to detect the physical open short attacks. With the active tamper, the MCU outputs a random pattern continuously on the tap-out pin. This output pin must be shorted externally to a tap-in pin. The comparison between the two pins is done continuously. So if there's a short on the tamper pin or if the external wire is broken by a physical intrusion, it will be detected thanks to the fact that after each tap-out value coming from a random number generator, the opposite value is also sent after. So it is not possible to have a long sequence of same zero or one values. The change frequency of the tap-out value is software programmable and impacts the intrusion detection maximum time. The power consumption can be reduced by decreasing the tap-out frequency and consequently increasing the detection time. A PCB mesh is used for active tamper detection. The tamper events can be individually configured to be passive only the input is needed or active and output must be associated to an input for comparison. In active tamper mode, the tamper output pin to be compared with each tamper input pin is selected by software and the same output can be used for several inputs. A digital filter can be enabled to reduce the risk of false tamper events detection. In this case, the tamper is detected only when two comparisons are false in four consecutive comparison samples. Several monitors are integrated in the device to detect perturbation and environmental attacks. These monitors are connected to the internal tamper detection blocks which can be individually enabled or disabled and which erase the backup registers and backup SRAM content in case of internal tamper event. A 32-bit monotonic counter is implemented in the temp referral. This register is read only and is incremented by one when a write access is done to this register. This register cannot roll over and is frozen when reaching the maximum value. The 2 power 32 last write into this counter can generate a tamper event. The monotonic counter overflow is connected to the internal tamper detection block 8. Environmental perturbation attacks can be detected thanks to V-BAT voltage monitoring and temperature monitoring both available in all low power modes and in V-BAT mode. For each monitor, the low level and the high level thresholds are programmable. V-BAT voltage monitor is connected to the internal tamper detection block 1 and the temperature monitor is connected to the internal tamper detection block 2. An RTC clock attack can be detected thanks to the LSE clock security system in the reset and clock control which detects when the LSE stops toggling. The CSS on LSE is available in all low power modes but not in V-BAT mode. CSS on LSE is connected to the internal tamper detection block 3. If the HSE is used as a system clock, a tamper can be generated in case the HSE stops toggling thanks to the HSE clock security system in the reset and clock control. CSS on HSE is connected to the internal tamper detection block 4. Software attacks to corrupt the RTC counters can be detected thanks to the RTC calendar overflow generated when the RTC calendar reaches its maximum value on the 31st of December 99 at 235959. The calendar is then frozen and cannot overflow. The RTC calendar overflow is connected to the internal tamper detection block 5. Each tamper detection event, external and internal, can generate and interrupt. The TAMP peripheral is active in all low power modes and in V-BAT mode. In stop and standby modes, the level detection with filtering and active tamper modes remain active only when the clock source is LSE or LSI. Note that only the LSE clock is functional in V-BAT mode. If the tamper source is available in low power mode, the TAMP interrupts cause the device to exit a low power mode. This is a list of peripherals related to the tamper and backup registers peripheral. Please refer to these peripheral trainings for more information if needed. Reset and clock control. Power control. Real-time clock.


This is a product overview for the Volkl Flair 78. It's a great all-rounder for advanced skiers looking for something with plenty of agility, but also wants something smooth and forgiving underfoot too. It uses Marker's 4-Motion XL binding that has four separate rail mounting points that allows the ski to flex naturally and gives it that nice smooth arc throughout the turn. It uses a dual wood core light construction that has a mix of PU and two lightweight wood stringers that means that it's nice and manoeuvrable, easy to kind of move around on your foot, but actually that power just gives it that little bit of boost to give power down to the edges, which is increased even further by putting a steel laminate on top of there too, just to provide it with a slightly damper, more smooth skiing experience. It has a mix of sidewall underfoot and tip and tail rocker, which means it gives you plenty of grip underfoot on firm snow conditions, but the tip and tail rocker just help to iron out any of those lumps and bumps and just give it a much more forgiving, easier to use ride. Tester's picked up on the fact that it had a fair amount of torsional stiffness, so it had that edge grip. It was responsive, both on and kind of off-piste, but it really excelled on the hard pack, which is why we've given it a runner-up award for all terrain car for women.