Empower Apps

Saleem Abdulrasool joins us to chat about bringing Swift to Windows. We get into server-side Swift, SwiftWin32, Swift's C++ interop, and how to get started yourself.

Guest
Related Links
Related Episodes
Chapters
  • (00:00) - Why Swift on Windows
  • (08:40) - Command Line Tools, PowerShell & WSL
  • (16:35) - Server-Side Swift & Building Desktop Apps
  • (24:46) - The History of Windows UI Frameworks
  • (33:15) - Getting Started with Swift on Windows
  • (41:32) - Interop, SwiftUI & Future Plans

Watch
Click here to watch a video of this episode.

Transcript

Support the Show
★ Support this podcast on Patreon ★  

Thanks to our supporters: Thanks to our monthly supporters
  • Steven Lipton
 
Welcome new supporters:

Social Media
Credits
Music from https://filmmusic.io "Blippy Trance" by Kevin MacLeod (https://incompetech.com) License: CC BY (http://creativecommons.org/licenses/by/4.0/)

Creators and Guests

Host
Leo Dion
Swift developer for Apple devices and more; Founder of BrightDigit; husband and father of 6 adorable kids
SA
Guest
Saleem Abdulrasool
PL/Compiler Engineer, cross-platform Swift, and Swift Core Team Member. @browsercompany, ex- Google, Facebook, Microsoft.

What is Empower Apps?

An exploration of Apple business news and technology. We talk about how businesses can use new technology to empower their business and employees, from Leo Dion, founder of BrightDigit.

[00:00:00]

Why Swift on Windows
---

Leo Dion (host): Welcome to another episode of Empower Apps. I'm your host, Leo Dion. Today I'm joined by Saleem Abdulrasul. Saleem, thank you so much for coming on.

Saleem Abdulrasool (guest): Thank you for having me. It's a pleasure

Leo Dion (host): I think this is gonna be our first Windows-focused episode, so my, I'm excited. I'll let you introduce yourself and how you got started into doing Swift for Windows

Saleem Abdulrasool (guest): Let me take a pass at introducing myself then. So I'm Saleem Abdulrasool. Most people know me online as compnerd. I'm a systems engineer at The Browser Company, but the thing I'm probably best known for is that I brought Swift to Windows. I've worked on developer tooling across both the LLVM and Swift projects, and on top of that, I built a set of my own things.

Saleem Abdulrasool (guest): The app framework SwiftWin32 the Windows interop layers, and so on. Windows is really just the last stop though. I was one of the original folks who got Swift running on Android, and I did a few odd ones along the way, like PlayStation. I even laid some of the [00:01:00] groundwork for embedded Swift early on before Apple took it up and ran much further with it.

Saleem Abdulrasool (guest): So my world is Swift with Swift in all the places people don't expect it.

Leo Dion (host): Yeah, which I'm a big fan of, so this is really exciting. I guess we'll maybe let's start by why Swift on Windows? And you can either focus on personally or within The Browser Company. What was your interest there?

Saleem Abdulrasool (guest): I'd say it's conviction about the language plus a bit of stubbornness. I believed Swift-- in Swift early on, right as a language in its own right. And if you actually believe a language is good, you want it to run where the people are. The vast majority of desktops out there run Windows, so to me it was obvious.

Saleem Abdulrasool (guest): If Swift's going to be a serious general purpose language, it needs to reach the Windows users. The other half was that everyone said it wasn't really practical, and I had a pretty good idea it was, so I wanted to prove it [00:02:00] out

Leo Dion (host): That's amazing. What about Swift were you like, "Yeah, this needs to be..." what about the language itself that you love it and why you were like, "Yeah, we need to use Swift in Windows and not just go to C++ or C# or something"?

Saleem Abdulrasool (guest): Yeah. The, with Swift, right, like what I saw was a, a language that kind of shed its heritage in some senses, right? Like it, it didn't have the baggage that other languages had. So C++ kind of derived itself from C, and with C- Swift it, it took some inspiration from a variety of different languages, but it didn't really bring them forward, right?

Saleem Abdulrasool (guest): It's not like I'm just going to evolve the syntax. It was just like take a clean break and look at what the languages are and what they're trying to do. And so it came from that foundation, like we now understand what we need from languages. Let's actually go back and think about this and do something correctly.

Saleem Abdulrasool (guest): So we have a memory safe language. [00:03:00] You have clean syntax, and it really went, I don't need to do everything. I can coexist in this world. And so you have this excellent interop story that allows it to blend all the things that you already have, right? It's not oh, let me go out and rewrite everything at once.

Saleem Abdulrasool (guest): It's a, I can progressively move to a better place.

Leo Dion (host): Right. So as you were working on Swift for Windows, was there any particular language feature that made that experience easier for you at all?

Saleem Abdulrasool (guest): The experience of bringing it over or,

Leo Dion (host): Yeah. Bringing it over. Was there something about like async/await or certain language features that you were like, "Okay, now this is gonna be way more viable"?

Saleem Abdulrasool (guest): Not-- I wouldn't say that's really the case. I push back on the idea that some of the language features made it easier. If anything, the language evolving is one of the things that made it more difficult. A lot of the features [00:04:00] land on Apple's platforms first, right? And Windows comes into the picture.

Saleem Abdulrasool (guest): Concurrency actually is a good example. By the time we were bringing it to Windows, the model already had baked and shipped, right? So it's a fun problem because it's not just a library feature. The model shares stacks in a stack space, and to control stack growth, it relies on guaranteed tail calls.

Saleem Abdulrasool (guest): And that's a calling convention guarantee, right? And calling conventions are one of the areas where Windows differs. So

Leo Dion (host): Right

Saleem Abdulrasool (guest): yeah. And then another thing was async function pointer representation, right? It didn't really work on Windows, and that started a bug in someone's program, and the work was reducing it down to a minimal test case, root causing why the representation broke, and then eventually designing a workaround using pointer tagging.

Saleem Abdulrasool (guest): So it's some low-level piece of the puzzle, right? It's not just a simple recompile and it works.

Leo Dion (host): Can you like deep dive more [00:05:00] into some of those challenges as far as like how Windows does things differently from Linux or any of the Apple platforms?

Saleem Abdulrasool (guest): I guess there, there's plenty of differences. Are there areas that you're potentially drawn to or

Leo Dion (host): No. Just what do you think is the most obvious thing or challenge that you had to face, I don't think that there's one obvious thing, right? ~ ~one of the things is that it's been all over. And I don't know if you actually read my or watched my talk from the LLVM Developer Conference in 2019. It was called Porting by a Thousand Patches, and that's because it really has been just one thing after another, right?

Saleem Abdulrasool (guest): That, that's one of the things that you learn is th- this port was never impossible. It just was accepting the fact that every time you fix one thing, three [00:06:00] more things pop up, and just showing up to keep knocking them down

Leo Dion (host): Is there just like a different philosophy behind how Windows works as opposed to the other ones if you squint, I think that you realize that all of these operating systems look similar. And that, that's one of the interesting things. I'd actually argue that Windows at this point feels more similar to me than-- to macOS than it does to Linux.

Leo Dion (host): Okay. In what way?

Saleem Abdulrasool (guest): Microsoft really takes API stability to heart.

Saleem Abdulrasool (guest): Microsoft has maintained API stability for close to 30-some years now, right? Like applications written in 1995 will run just fine today

Leo Dion (host): Mm-hmm. That makes total sense. ~ ~it almost seems like they're going in the other direction where like, "Come on guys, get off of Windows 10, move to Windows 11." If anything, they... It's a, it's become a burden to them if that makes [00:07:00] sense

Saleem Abdulrasool (guest): Yeah it's definitely a challenge to keep programs running for that length of time. I think that Microsoft has some great engineers, and they've managed to do an exceptional job, and Apple has done an amazing job at this as well, right? ~ ~this is the reality. These companies are large and have some excellent engineers that are able to perform some heroics for keeping software running well.

Saleem Abdulrasool (guest): But that's part of that commitment to API stability. But at the same time, there's also ideas of security, right? Both these platforms go to extents to make sure that their users are safe. Both of them sort of have mature ecosystems. Both of them have multiple distribution mechanisms, and so there's a lot of similarities between these.

Saleem Abdulrasool (guest): Linux is growing too, right? It's not oh, it's completely different. It's just that it's taken a different route to get to the same place. And while [00:08:00] API stability has never been one of its core areas of focus for the user space, I think that they've been making progress towards shoring up the rest of the ecosystem, right?

Saleem Abdulrasool (guest): And the package managers on Linux are always something that people sort of compare themselves to, right? That's where a lot of these ideas came from. So the port system in BSD, package managers on Linux they're phenomenal. And so you have a lot of those ideas bleeding over now to these other platforms too.

Leo Dion (host): Yeah. Yeah, that's one thing I've noticed when I was working with Windows. So let's talk maybe about like a

Command Line Tools, PowerShell & WSL
---

Leo Dion (host): showcase of some great use cases for where this has happened. ~ ~I put in my list command line tools, for instance, work across the board. Is there any command line tools in s- written in Swift that you can think of off the top of

Saleem Abdulrasool (guest): there's definitely an interesting one that everyone likes to use, the Swift [00:09:00] compiler

Leo Dion (host): Yeah. So yeah, talk about that

Saleem Abdulrasool (guest): Yeah. The command line surface is probably the most mature one. And the best proof is the toolchain itself, right? Like the Swift toolchain uses Swift now. And when the thing that builds the language is written in the language on the platform, that tells you that the story is real, right? Building and running native command line tools on Swift on Windows works today.

Saleem Abdulrasool (guest): The language and API support is there, is complete. But there is one nuance though, and it's a fun Windows is not Unix thing. The command line environment is quite different. Windows historically doesn't have the same PTY/TTY concept Unix does, and it traditionally didn't render the console using ANSI escape sequences the way Unix terminals do.

Saleem Abdulrasool (guest): It used proper Windows APIs for that.

Leo Dion (host): Okay

Saleem Abdulrasool (guest): And that changed with Windows Terminal. Microsoft added the tooling and the API support to host enough of the TTY [00:10:00] concept and moved over to ANSI escape-based rendering. So the language support is great, but it's not quite apples to apples, no pun intended because the console model underneath is just a different world.

Leo Dion (host): ~ ~So in a previous life I was a Microsoft developer, because if you wanna be a salaried employee in the Midwest, you pretty much have to be. But when I was young I got into .NET, C#, and then just before I started kind of slowly moving into the Apple space PowerShell had become a thing.

Leo Dion (host): How does that... 'Cause ~ ~I researched before this writing my own Windows app and ~ ~one of the things was like how like I was confused by okay, so there's like command line, there's PowerShell, and then a lot... There's a few things out there where I don't know what it's called, but you can kind of do like Linux-y terminal stuff on Windows.

Leo Dion (host): Like explain the differences in that whole ecosystem, 'cause it was really confusing to me.

Saleem Abdulrasool (guest): Sure. So just to make [00:11:00] sure I'm following, are you talking about Windows Subsystem for Linux?

Leo Dion (host): I think that's exactly what I'm talking about, yeah. Yeah, 'cause there's like the old school basically DOS brought in, there's PowerShell, and then there's the thing you just said

Saleem Abdulrasool (guest): Yeah. No, you're right that Microsoft's environment is sometimes scary for a new user because it's just so vast. I think that the first thing to think about is the-- again, right? If you squint just right, all of these platforms look the same. ~ ~on Windows, right, you have this shell, you have this window that you're interacting with, and in a lot of ways, this is what you see on macOS and Linux as well, where you have this window that you're working on, you have a shell within it, and you're able to launch commands and whatnot.

Saleem Abdulrasool (guest): Now ~ ~Windows actually, the way that I think about it, has ~ ~It did not have a shell. All right? What it had was a batch interpreter. ~ ~and this is meaningful when you actually try to [00:12:00] understand that ecosystem and why things are the way they are. The batch interpreter is meant to be not an interactive tool that you're using to work with the computer with.

Saleem Abdulrasool (guest): It's meant to be just a host to run a predetermined script, right? So that's what the DOS command prompt was. It was a batch interpreter, really. PowerShell was Microsoft's first foray into this, an idea of a interactive shell almost. And they came at it from a completely different place than where the Unix environment came from.

Saleem Abdulrasool (guest): PowerShell was meant to be this, th- this different environment where you actually you were performing operations against objects. So it's this very Smalltalk-ish environment, right? You have all of the all of these things that you're working against, and you're piping them into one another, and you're building up this pipeline of commands that you're g- executing,

Leo Dion (host): It almost like,[00:13:00]

Saleem Abdulrasool (guest): of objects

Leo Dion (host): what I remember was like, it was almost like they were trying to bring .NET into the shell. A lot of the same APIs were more li- like whatever you can do in code you can do with PowerShell

Saleem Abdulrasool (guest): Right. So that c that's a separate aspect of PowerShell. So PowerShell has this idea of you have objects and you have properties on these objects that you're interacting with, and you're able to pipe them to each other and you're able to build a pipeline. And fun little aside, the original name the code name for PowerShell used to be Monad, right?

Saleem Abdulrasool (guest): Like the idea is that it's a monadic operation stream that you're building up. The, the aspect that you're referring to is actually a feature that they've built out because PowerShell itself is built on top of the .NET environment, and .NET environment has this really cool concept of running over a VM, right?

Saleem Abdulrasool (guest): Like the v- the virtual machine that it executes on is the CLR. [00:14:00] And so what it's able to do is it's able to use a funct- a piece of functionality there, which is P/Invoke. It allows it to do a platform in- invocation and bridge right into the .NET ecosystem and bring all of that into the shell itself

Leo Dion (host): Got it. Okay

Saleem Abdulrasool (guest): So that's sort of the PowerShell environment itself. And then y- since you're asking about the Windows subsystem for Linux this is actually going into another aspect of Windows where Windows again is this... I- it's this interesting environment, right? Like the NT k- the kernel itself, the NT kernel is very powerful and it's very flexible just because of the way it was designed and the ideas behind it.

Saleem Abdulrasool (guest): One of the ideas that the NT kernel had was the idea of execution environments. So i- if you go back to the original time that this was all being developed, Microsoft was working with IBM, right? They they had this partnership and there was [00:15:00] this other OS, OS/2, and the idea was to actually be able to natively host executables from different OSs under the same environment.

Saleem Abdulrasool (guest): So you could take an OS/2 executable and you could execute it on Windows. It would run under the NT under a separate sus- subsystem, so it could actually provide you the necessary infrastructure for the OS/2 environment. And so Microsoft actually did this really clever thing of they built yet another subsystem, which was the Windows subsystem for Linux, and this allowed them to build or to execute Linux executables against the NT kernel.

Saleem Abdulrasool (guest): What they found is that people didn't necessarily want that model per se. They wanted a much more richer Lin- pure complete Linux environment, and so they switched over from that to the Windows subsystem for Linux 2, which actually is [00:16:00] more of this full Linux environment that's running alongside of Windows.

Saleem Abdulrasool (guest): And so that's where you were referring to of being able to just run that Linux environment, where it is actually the Linux kernel that's running on Windows as well.

Leo Dion (host): That is the same thing, essentially. Linux, Windows for Linux. Interesting. I didn't know that that goes back to OS/2 wow. Okay, 'cause OS/2 is that was IBM's like little experiment back in the '90s that did not work out.

Leo Dion (host): Okay. Super interesting. I did not know that. I...

Server-Side Swift & Building Desktop Apps
---

Leo Dion (host): So one thing I was intrigued by, I had this conversation with Giannis at SwiftCraft, and we were talking about how big of a deal it is to get server-side Swift on Windows. And I was like, " why would you care to get a server-side Swift in Windows?"

Leo Dion (host): Most servers that I know of are running Linux. And then we got into this whole thing about how there's and I knew, I kinda know [00:17:00] this now, but in reflection, I didn't realize at the time, was like, oh yeah, there's a lot of companies that's have to run Windows and have to run Windows servers.

Leo Dion (host): And so getting Swift, server-side Swift working on Windows is really important because it gives us an opportunity to basically write a server for a, a ton of people who run Windows as servers. Now I, like I said, in a previous life, I had done some .NET and worked with IIS and all that stuff. Kind of explain, first of all how getting a server work on Windows, the challenge of that, and then why is it so important?

Saleem Abdulrasool (guest): Yeah. To really tell you this one, you have to go back to around the turn of the millennium to the C10K problem. The challenge of handling 10,000 simultaneous connections on one server.

Leo Dion (host): Yeah

Saleem Abdulrasool (guest): Windows actually was a serious server environment very early and a lot of enterprise flocked to it, and in part of it was because of its async I/O [00:18:00] model,

Leo Dion (host): Okay

Saleem Abdulrasool (guest): I/O completion ports or IOCP.

Saleem Abdulrasool (guest): And IOCP is genuinely interesting. It's a completion-based model where the OS hands you back data once the I/O is done. That's quite different from the traditional Unix readiness model where the OS just tells you a socket is ready and you go read it. For a long time, that made Windows kind of its own world.

Saleem Abdulrasool (guest): Interestingly Linux actually has moved towards the same completion model recently with io_uring, so the two are closer now than they've ever been. But the point is that Windows has always been a capable server-ready platform, and there's real interest in writing servers there. The catch really is the tooling story in Swift.

Saleem Abdulrasool (guest): The center of gravity for server-side Swift is NIO the networking framework. And I actually got NIO working on Windows back in April 2020. But we never really managed to get that work integrated upstream into NIO itself. And there was a second push, and now there's a third push happening.

Saleem Abdulrasool (guest): And I'm [00:19:00] genuinely hopeful that this latest one lands 'cause the goal is simple, right? You-- And worth it. You should be able to write server software on Windows easily in a, a reliable, safe, modern language and take full advantage of the advanced networking Windows actually has.

Leo Dion (host): Well, so we have it fully working now, but it's just waiting on a merge, is that the understanding?

Saleem Abdulrasool (guest): So a lot of the original work had bit rotted. There are multiple people now Johannes included Jake also put up some recent patches. ~ ~there's a lot of people actually pushing on it now, and hopefully this work will finally see day of light.

Leo Dion (host): And just for those who don't know, can you explain why SwiftNIO is so important and what it provides on the server?

Saleem Abdulrasool (guest): yeah so NIO basically is a engine, right? ~ ~It is basically the reactor itself which will feed the data from the sockets into your application itself. So it gives you the [00:20:00] means of quickly getting data from the socket processing it.

Saleem Abdulrasool (guest): Excuse me.

Saleem Abdulrasool (guest): So getting that data, processing it, and handing it off to the application so that the application can form the application logic. And so when you have that, that infrastructure, you can quickly stand up these applications and have them scale to what you normally expect these days from the machines which have grown significantly from the turn of the millennium time, right?

Leo Dion (host): Yeah, that makes total sense. And then I guess the last piece to talk about is the desktop app infrastructure, which you've worked a lot on at The Browser Company. From my understanding, there's two ways of doing this. And then I chose the way to just use the Windows SDK in Swift way.

Leo Dion (host): Explain kind of that journey and where things stand for building Windows apps.

Saleem Abdulrasool (guest): Yeah y-you're right. Desktop is where the majority of Windows users are, so we really do need to [00:21:00] focus there. And the state today is that there's no single UI framework. It's bring your own UI. Why don't I walk you through my own path because it kind of maps the whole space? I started with Swift Win32, which gives you a native app framework built around the classic Win32 APIs.

Saleem Abdulrasool (guest): But I wanted some more of the modern UI components, so I started looking at WinRT and WinUI, and that pulled me into building Swift COM to talk to COM, and then Swift WinMD to read the metadata that describes the full Windows API surface. I also poked at DirectX along the way. And at The Browser Company, we're actually using a fork of the WinMD work to generate bindings to WinUI, and we build with that.

Saleem Abdulrasool (guest): And here's the part that I'm excited about. Swift on Windows has matured to the point where we can now tackle something we'd always said that we could do someday proper COM interop and with the compiler helping. The idea is to bring Swift's ARC the automatic reference [00:22:00] counting to COM because COM is reference counted at its core.

Leo Dion (host): Okay

Saleem Abdulrasool (guest): Microsoft actually tried something in this spirit years ago with C++/CX where the language extension managed to d- the ref counting for you, though they later decided that a library-based ap- based approach was a better fit for C++. Swift is interesting here because it already has ARC built in, so it's a much more natural fit.

Saleem Abdulrasool (guest): And the model we're working towards is a natural native Swift that just happens to bridge over to COM. And in a lot of ways, that's the same thing that Apple did with Swift, Objective-C, and Core Foundation, toll-free bridging, first-class conveniences, the language doing the bookkeeping for you. And I've restarted the WinMD work to support this.

Saleem Abdulrasool (guest): All of this is in the open, so honestly, that, that whole thing is its own con- conversation about the approach and technology, so let's not go too deep into that.

Leo Dion (host): And we'll provide links to these repos in the show notes below so you [00:23:00] can check that out. How would you recommend somebody get started? Because I went with the Win SDK route and had Claude basically doing what I wanted to do. What would you recommend?

Saleem Abdulrasool (guest): Yeah. So the, the Windows SDK is definitely the easiest way to get started. The, the reality is that the WinUI environment, as enticing as it is not so developer-friendly yet. something that we are working on. The, and the idea is that the COM interop once that is ready, will need naturally open up full access to WinRT, which is what WinUI is based on.

Saleem Abdulrasool (guest): So you have COM allowing us to bridge to WinRT, which opens up WinUI, and then we get the full fidelity WinUI APIs without necessarily having to build up all the projections ourselves manually. So there, i-i-if [00:24:00] you are an intrepid developer, you can of course use the fork from The Browser Company that has all this functionality there.

Saleem Abdulrasool (guest): We did an i-initial investigation where we used the old WinMD approach and generated the bindings manually. And there are some places where there are little hidden trapdoors where you might find yourself stepping through and it's like, "I did not expect that." And that, that's just the state of the, the original projections, right?

Saleem Abdulrasool (guest): There was a lot of hand-rolled dual models to do the bridging between Swift and C- and COM. And the idea is with Swift with the COM interop in Swift, we should be able to bridge to that much more

The History of Windows UI Frameworks
---

Leo Dion (host): I want to take a minute and explain some of these concepts. So I remember building like Windows apps using C# 15,

Saleem Abdulrasool (guest): Mm-hmm.

Leo Dion (host): 16 years ago. And then obviously there was [00:25:00] COM, M- MFC was one of 'em. And now you're talking about WinRT, you're talking about WinUI. What are these and how do these all work together within the Windows desktop environment?

Saleem Abdulrasool (guest): Yeah, absolutely. I think this is one of those other places where you end up with this stroll through memory lane.

Leo Dion (host): Yeah, go for it. I'll even put in some I'll put in what do you call it? Flashback music here on the podcast

Saleem Abdulrasool (guest): That sounds amazing. So the Win32 API is really old. This came out of Project Chicago

Leo Dion (host): O- one of the key indicators is that it's old is that it's called Win32. That's, that to me was like a big tell like, yeah, this is pretty old if it's 32-bit based. But anyway, go ahead

Saleem Abdulrasool (guest): Yeah. So th-this all I believe came out of Project Chicago, although some of it might predate it. So Project Chicago would be known to most [00:26:00] people as Windows 95. That's where a lot of these original APIs really first showed up in, in the way that we tend to use them today with GDI and the, the whole proper Windows handles and everything for the UI toolkit

Leo Dion (host): Yep. And that's the way I went, which was ugly but it worked. So yeah

Saleem Abdulrasool (guest): And Microsoft actually did evolve that through Windows 98 and Windows ME as well. The-- There was a separate parallel piece of work that was going on. So if you think back now around the same time with Windows 95, right? Microsoft had just released Windows 95. It was huge, and people wanted to build applications.

Saleem Abdulrasool (guest): And one of the things that really was interesting at that time was there were these applications that were dedicated and did really well for certain things. [00:27:00] And one of these examples is Excel, which is to this day considered best in class for spreadsheeting, right? So the idea there was, well, we have all of this library of code where we've really invested in building these high-fidelity applications.

Saleem Abdulrasool (guest): It'd be wonderful if we could reuse them. And that led to the idea of object linking and embedding, and the idea was that you could embed Excel into your application and have that level of spreadsheet work ~ ~within your application without having to rebuild it. And to do that ~ th-that~ train of thought basically kind of grew out into COM, which was the Common Object Model where you had a representation that you could work with in-process, out-of-process, however you really wanted to work with it, right? And so it just allows you to sort of go, "I have this interface definition. I do not know how it's [00:28:00] implemented or anything, but I know this is the interface that it provides, and I have its identity." These identities are GUIDs. And so you basically go, "Hey, system, here's the identity and this is the interface that I want.

Saleem Abdulrasool (guest): Give me that." And it just hands you back an opaque interface, and you just work through that, and suddenly you have the implementation f- without having to really rebuild it yourself. And so this is a very powerful concept, right? That it allows for this decomposition and for people to focus on the areas that they're really good at. Microsoft basically took that and built out their entire ecosystem with this idea, and so you have COM pervasive throughout the OS now Fast forward to Windows 8, and around that time, one thing that was becoming really popular was more of the compute on the go, right? So people had tablets, people had phones, people had these thin and light laptops, and the idea [00:29:00] was: How do we actually evolve the ecosystem to sort of work with that where we're thinking about the modern environment, right?

Saleem Abdulrasool (guest): So you have applications. We don't really care about where the file is stored or how it's stored. What we want is, this is my data, this is the application I'm working with, I just wanna do my job, right? And so-- A- and this is the model that you see with today's phones, right? You don't have the file system necessarily exposed to you.

Saleem Abdulrasool (guest): You have these applications, you have your data, and it just magically, fluidly moves between them.

Leo Dion (host): Are we getting into XAML yet?

Saleem Abdulrasool (guest): Oh, sorry, I skipped entirely over XAML, and I think that it sounds, it, it-- The, the chronology being a little out of order here actually helps understand everything, how they fit together. The idea was that you have these applications that are isolated, and you don't want them to leak data to each other, right?

Saleem Abdulrasool (guest): You want to be in [00:30:00] control of your data. So that led to this idea of the Windows Runtime application for applications, right? So Windows Runtime or WinRT was that substr- substrate that Microsoft built up for these ty- new modern applications. And so you have this new environment where you can build these, these modern applications that, that sort of abstract away the idea of file system, the environment, and all of these things that people that are working with the command line are familiar with.

Saleem Abdulrasool (guest): All of that just goes away. You have applications and you have your data, and that's all you need to think about. When they did this, because you were building up these more modern applications, they wanted to change the look and feel of these applications. And so they basically repurposed what they'd built with Windows, w- around the Windows ME ti- right after Windows ME or around Windows ME with XAML, right?

Saleem Abdulrasool (guest): XAML basically [00:31:00] was this idea of building out a declarative UI. Shocking, I know. No one w- has ever thought of that idea. Mm-hmm. Yeah. Yeah

Saleem Abdulrasool (guest): hey, it's computer science. We see the same problems just again and again, right?

Leo Dion (host): It's like storyboards and interface builder. That's what you're alluding to, right? Yeah

Saleem Abdulrasool (guest): Yes. And SwiftUI. No, I being facetious, but yes.

Saleem Abdulrasool (guest): All of these yeah, the, the thing is though it is all the same concepts, right? Again, if you scroll,

Leo Dion (host): Well I think HTML was a big inspiration,

Saleem Abdulrasool (guest): HTML was also a big inspiration, you're right.

Leo Dion (host): Yeah

Saleem Abdulrasool (guest): so XAML basically allowed you to mark up the UI that you wanted, right? So they were able to be a bit more flexible about how that UI evolved, and so they were able to reuse that to build out the UI

Saleem Abdulrasool (guest): That unfortunately never really took off in the way that they were hoping. And so basically what they found is that [00:32:00] the people who were using the applications really clamored for native applications on the desktop. And so they basically took the WinRT layer and evolved that, right? And from that you ended up with WinUI, which is the new UI layer for building Windows applications.

Saleem Abdulrasool (guest): And ~ ~this basically is built on top of WinRT, which is built on top of COM, and so you have now the new UI layer, and this was shipped as part of the OS, which meant that, well, if you want to update, that's kind of difficult, right? OSs don't ship every day. So Microsoft actually took that and said, "Actually, we can put in the effort and break this out of the OS," right?

Saleem Abdulrasool (guest): And so that's where we come up with WinUI 3, where it's been separated from the OS itself and allows you to ship a version with your application, and it's being adopted by both Microsoft and elsewhere in building new UI [00:33:00] applications.

Leo Dion (host): So yeah, that was awesome. I appreciate that very much because that explains a lot that I've missed in the last 15 years. What I don't know where to start. I have two questions. One is,

Getting Started with Swift on Windows
---

Leo Dion (host): how do you recommend your typical iPhone developer with a Mac, how should they get started building, like trying out Swift for Windows and building a desktop app?

Leo Dion (host): What's the best route there?

Saleem Abdulrasool (guest): Yeah. So th-there's two aspects to it. Let me start with the first one, which is how do you really get started? 'Cause I feel like that's what you're trying to ask.

Leo Dion (host): Mm-hmm.

Saleem Abdulrasool (guest): So Windows is a much older and more complicated landscape than most people expect, and one of the things that I actually like about it is that it lets you work the way you want.

Saleem Abdulrasool (guest): So the answer kind of depends a bit on who you are. For most people, you just wanna download the installer and run it, and that's had a huge overhaul recently to make the experience really smooth. That gives

Leo Dion (host): do you even get, how do you even get [00:34:00] Windows though? You've skipped a part.

Saleem Abdulrasool (guest): Yeah. I assume that y- you have Windows on Ma-- If you're running just on macOS hardware, I think that Parallels right now is the only way because of the

Leo Dion (host): Yeah, that's what I ended up doing

Saleem Abdulrasool (guest): Excuse me. And then if you have Intel hardware you should be able to just get Windows from Microsoft. It r- it runs on a wide variety of hardware, right? Th- and that's one of the important things that

Leo Dion (host): I found the opposite is true, that my, all my Windows machines, so I don't have a lot, are too old to run Windows 11. So I ended up going with Parallels for a lot of reasons, one of which is just the ease, the ability to be able to develop on the same machine that I'm using day to day

Saleem Abdulrasool (guest): I would say that it feels that way but when you actually truly look at the requirements, it's interesting. Most of these machines that are [00:35:00] required to like those minimum requirements for Windows, usually they're asking for a machine from around 2012, 2013 at the earliest.

Leo Dion (host): Okay

Saleem Abdulrasool (guest): So that's about 13 years ago now.

Leo Dion (host): Yeah, that's true. But also it could be faster 'cause Apple Silicon's so solid, it could honestly be faster to develop in a VM than it would be to develop on a desktop that's 13 years old or two. So yeah, something to consider

Saleem Abdulrasool (guest): Yes. For what it's worth I actually did spend some time with a machine specifically for testing that actual developer workflow where I don't actually develop Swift, but I develop with Swift. And what I did was I purchased a Project Tiny Mini Micro, I believe is what they're called machine.

Saleem Abdulrasool (guest): Like a $100 machine off of eBay from like 2012, and [00:36:00] I was just doing f- all of the development right on that, right? And

Leo Dion (host): That's really good to know

Saleem Abdulrasool (guest): it worked pretty great. Like my biggest complaint was I need to switch machines so that I can do d- my actual compiler development to my actual application development, and the application development was just so much easier.

Leo Dion (host): Yeah. I have, I usually whenever I need a Windows machine or a cheap computer, I've gotten like those, I think they're HP EliteDesk machines. Yeah, those are super cheap too.

Saleem Abdulrasool (guest): Yeah, that, that's exactly what

Leo Dion (host): hopefully they're still super cheap. Well, we'll see in a, in our current environment. But the, the other, like I don't know if you're gonna mention this, but yeah I set up PowerShell.

Leo Dion (host): I installed the latest version of PowerShell, and I set up a SSH server so I can SSH into it. It just like there are a lot of pieces. Oh, you... So part of the process, and let me know if I'm stepping on your toes on this, but was like you have to [00:37:00] install the Visual Studio Community edition, and I believe it was e- either 2012, is it 2022 or 2026?

Leo Dion (host): What would you recommend?

Saleem Abdulrasool (guest): So 2022 is definitely supported. We've been actively working on the 2026 support. I've been using a combination of the two, and I know that

Leo Dion (host): ended up doing.

Saleem Abdulrasool (guest): Sorry?

Leo Dion (host): That's what I ended up doing, was installing both

Saleem Abdulrasool (guest): Yeah. And then for ARM64 support, I do recommend Visual Studio 2026.

Leo Dion (host): Okay.

Saleem Abdulrasool (guest): But yeah I think that's a good segue back to what I was saying where you just download the installer and run it. And that gives you everything that you need with the one caveat that you already covered.

Saleem Abdulrasool (guest): We can't actually redistribute Microsoft's SDK, and so you need to install Visual Studio. And any version is fine. Community is free, but Professional, Enterprise, it doesn't really matter. [00:38:00] And you're installing it specifically for the Windows SDK and the C library.

Leo Dion (host): Right.

Saleem Abdulrasool (guest): If you want the build tools there are enough.

Saleem Abdulrasool (guest): All we really need are just the headers and the import libraries.

Leo Dion (host): Right. Yeah

Saleem Abdulrasool (guest): And there's a fun aside here. The whole idea of an import library, the compact stub describing what a library exports, Windows has had that since the early '90s the NT era, and Apple introduced the equivalent the TBD files in 2015.

Saleem Abdulrasool (guest): So Microsoft was way ahead on that one by a couple of decades.

Leo Dion (host): We covered how to get started. I and maybe you have experience with this. So in, in our current Apple world, there's a lot of talk about how Mac apps don't look like Mac apps, et cetera, et cetera. People just develop Electron or people... Like what is the environment in Windows for developing Windows apps?

Leo Dion (host): Are people like just yeah, slap together... I'm [00:39:00] sure there's a lot of slap together Electron apps but is there guidance as far as like this is how you should make a Windows app, this is how it should look, et cetera?

Saleem Abdulrasool (guest): Yeah. Yes there there is guidance on what is recommended. Microsoft does recommend WinUI 3. And we are actively working on we being The Browser Company are actively working on improving that. And we are collaborating with Apple on some of this as well. Hopefully that-- this, this is just going to improve over the next year or so.

Saleem Abdulrasool (guest): But there is already some amount of support there in terms of examples of how to do that. There are in fact community members who've posted YouTube videos on how to build with the WinUI bindings that we've generated at The Browser Company. We'll put links to that And to your other question of how your application should use-- t- and you should look.

Saleem Abdulrasool (guest): Microsoft has [00:40:00] equivalences to Apple's HIG as well. So Microsoft has Human Interface Guidelines, and you are generally recommended to follow those for a couple of reasons, right? You want to fit into that environment naturally, but it also makes your application feel at home that way, right?

Saleem Abdulrasool (guest): So

Leo Dion (host): Mm-hmm. What and then my, so the way I did it was Windows SDK directly, and then my understanding for like the WinUI method, which I assume is the alternative you're talking about, is you have to do some compilery stuff to get that working. How much of a challenge is that? Or is that what you're talking about when you say we should check out those YouTube videos?

Saleem Abdulrasool (guest): Yeah. So that is not actually compilery work. The the problem there is that the bindings themselves require some amount of setup, and that [00:41:00] has not been made as fluid as just importing a package dependency yet.

Leo Dion (host): Okay

Saleem Abdulrasool (guest): And ~ ~the hope is that once we have COM interop, it will become, excuse me a much simpler process where you can just add in a package dependency and get the WinUI bindings.

Saleem Abdulrasool (guest): For the time being, you need to set up an additional package and build that, and then pass that along to your application build so that you're able to integrate that. That's, the complexity.

Leo Dion (host): Got it. Okay. Very cool.

Interop, SwiftUI & Future Plans
---

Leo Dion (host): I have another question about window interop. Is there an ability to... So there's a interop with C++, right? So you could do Windows SDK stuff in C++ and then bring that in as a Swift package or product or something, right? Is that, am I saying that correct?

Saleem Abdulrasool (guest): Yeah. You can definitely have a library that's written in C and C++ and then be able [00:42:00] to i-integrate that into your application. And in fact, that is what all of this relies upon, right? ~Th-this~ is one of the fundamental aspects of Swift itself. So that when you Win32 API-based UI application that you're describing actually relied on that C interop.

Saleem Abdulrasool (guest): So all of that should be functioning just well.

Leo Dion (host): Do most people do C++ or do most people do C# in the micro? I would assume C# still, right? Or am I wrong?

Saleem Abdulrasool (guest): I think that you find that it goes back to Windows is pretty broad, right? You'll find people who are writing in C# and you'll find people who are writing in C++. So I don't know the actual counts, so I can't really speculate, but there's definitely both sides of development.

Leo Dion (host): Is there a C#? Well, I see some stuff about XAML still, which is hilarious. But is there any interop with XAML or C# in any way if you wanted to go that route than having to write C++?

Saleem Abdulrasool (guest): [00:43:00] so that on its own is pretty complicated because there's so many different approaches. Microsoft actually has this really interesting technology they've built where you can host XAML content within WinUI. So you have what they call XAML Islands. And so you're able to have XAML within your WinUI application that does not require C#.

Saleem Abdulrasool (guest): That does you can do it with C++. And in fact, we've al- at The Browser Company have experimented with that with Swift as well. And I don't think we have anything where it's something where we can just go and point you to a repository, go, "Here's how you do it." But it is something that, you know I think that will become much easier to work with as the COM interop improves, because that opens up a much more convenient way to work with the WinRT APIs and therefore WinUI.

Saleem Abdulrasool (guest): [00:44:00] And as you have the f- full fidelity WinUI come over, you should be able to use the XAML Islands as well much more easily.

Leo Dion (host): Has there been any work done to bring I don't wanna call it SwiftUI, but you know what I mean, to be able to build UIs using SwiftUI-ish into Windows?

Saleem Abdulrasool (guest): So there-- the work of building out a framework for declarative UI is quite large, right? I would imagine, yes. Yes.

Saleem Abdulrasool (guest): I don't know of any one complete solution. I think that especially if you're looking for a fully native experience, I don't know of anyone that has that fully built out yet. In some ways XAML itself is declarative.

Saleem Abdulrasool (guest): So I think the question is really: what is it that you're looking for, right? Are you looking for a, [00:45:00] "I just drop in my SwiftUI code and it works"? I don't know if there's a equivalent for that. If you're looking for, "How do I build applic- UI applications?" I think the answer is we have multiple ways of building out a UI on Windows right now.

Saleem Abdulrasool (guest): Some of them are more declarative than others, and I think that over time we should actually find all of these are going to start converging as COM really becomes full fidelity on full fidelity within Swift.

Leo Dion (host): Yep, I agree. Before we end, what are the future plans for Windows Swift on Windows, besides getting that PR merged for server side?

Saleem Abdulrasool (guest): I think the near-term future is really about turning current limitations into strengths. I mentioned it a few times. The one that I'm most directly driving is the COM Interop work bringing Swift's ARC model to COM, and that's the big unlock because so much of Windows is built around COM, and not [00:46:00] just the UI, but the whole platform.

Leo Dion (host): Yeah

Saleem Abdulrasool (guest): Getting that right means that Swift can integrate with Windows in a much more natural way. Debugging is the other big arc. Getting code view and PDBs fully in place so that the whole Windows tooling ecosystem just works with Swift. And that's something I'm steering through colleagues at The Browser Company and others at Apple rather than doing it myself, which is a good sign for the for where the project is, right?

Leo Dion (host): Mm-hmm.

Saleem Abdulrasool (guest): and more broadly, it's closing the last few parity gaps so that it works on Windows is just assumed the way it is on any other platform.

Leo Dion (host): Yep. Very cool. Thank you so much for coming on today, Saleem. I really appreciate it. It's good to finally meet you. I've heard so many good things about you and your genius. Where can people find you online?

Saleem Abdulrasool (guest): Yeah. First again, thank you for really having me. It was wonderful to chat with you about all of these old Windows details that people often forget about. [00:47:00] As to finding me the easiest is to just look for compnerd. That's me pretty much everywhere. I'm compnerd on GitHub, Mastodon, X and if Swift on Windows is what caught you here, the best place to actually plug in is the Swift forums.

Saleem Abdulrasool (guest): There's the Windows category and the Windows work group is right there. Come say hi, tell us what you're building or where you're stuck

Leo Dion (host): Awesome. Thank you so much. If people aren't subscribed to the newsletter, we just recently talked about some stuff with AI and how I've been using AI in agentic development. We'll have another newsletter out soon to talk about the release of AtLeast, so definitely take some time enjoying that TestFlight.

Leo Dion (host): I'll have the link in the show notes. And then thank you for Patreons like Steve Lipton for helping out. We post these episodes right away on Patreon, so you can check out if you wanna get early access, that's a great way to do it, or sneak preview to future blogs and [00:48:00] newsletters. Let me know. My company is BrightDigit. Check out brightdigit.com if you're looking for help with anything, and we also have some availability for half an hour consultation sessions, so I'll put a link to that in the show notes as well. I'm on Twitter @leogdion, Mastodon @ leogdion@c.im or you can reach me on LinkedIn at Leo G.

Leo Dion (host): Dion, or excuse me, Leo Dion, which is my name 'cause f- that is my handle, but you know what I mean. Anyways I'll shut up. Thank you for joining, and I'll look forward to talking to you later. Bye everybody.