Future of Windows in pro audio

[VitaminD]

The ASIO driver project I lead is open source, permissively licensed. Before this, no one created open source ASIO + UAC2 drivers, but I wanted everyone to have access to the code.
https://aka.ms/asio

The Windows MIDI Services project I lead, which has been incorporated into Windows 11 as of a week ago, is open source, permissively licensed, developed in the open with customer and partner input. That's an entire SDK, Windows Service, kernel driver, and more. We continue to work on it in the open, and then pulling the resulting code into Windows.
https://aka.ms/midirepo

WSL is open source, PowerToys is open source, WPF, WinUI, WinAppSDK, etc.

There's actually quite a bit of proper OSS at Microsoft. Other teams, especially in the developer division and .NET, do a lot more of it than we do.

Modern Microsoft is not scared of Open Source, but there are places where we use it, and places where we do not. You may be still thinking of the Steve Ballmer days, which was a while ago, now.

Pete
Microsoft

Do you ever have communication with DAW developers such as Steinberg on threading/scheduling and maximizing performance within the deep confines of Windows?

[lunardigs]

Microsoft BANNED WireGuard, VeraCrypt & Windscribe Without Warning

[Psychlist1972]

Despite the clickbait take on this, they aren't banned, they need to verify their accounts, and as publishers, keep up with changes. It's a pain, but nothing nefarious. I know that doesn't make for a good story, though. I've been dealing with this with hardware driver partners (like USB Audio devices). And yes, this process could be MUCH better and the communication way more clear.

This is what Pavan, President of Windows said:

Thanks, Tim. We’ve seen these reports and are actively working to resolve this as quickly as possible. We’ve reached out to VeraCrypt and have spoken to Jason at WireGuard, they should be back up and running soon.

Some background on this, this is all part of our ongoing efforts to help protect customers and the Windows ecosystem. We published a blog last October that shared we would require account verification for all partners in the Windows Hardware Program who had not completed account verification since April 2024. Other platform vendors are doing the same.

We worked hard to make sure partners understood this was coming, from emails, banners, reminders. And we know that sometimes things still get missed. We're taking this as an opportunity to review how we communicate changes like this and make sure we're doing it better. If anyone needs help with reinstatement, they can request support here,

Pete
Microsoft

[lunardigs]

Clickbait? Really?

isallthisclickbaittoo.png

[audiojunkie]

That would never happen with Linux.

[Psychlist1972]

That would never happen with Linux.

"Linux" isn't a thing in this way. You need to look into the requirements for driver submission for specific distributions. For example, RHEL has pretty stringent requirements and process to get drivers into the distro.

The signing and validation requirements here for Microsoft operating systems are to help protect customers from malicious kernel driver code. Another option would be to do like Apple did, and start requiring developers to create user-mode drivers for, for example, all the low-latency audio devices we all rely on, and require special boot modes or settings to allow kernel drivers.

Pete
Microsoft

[Psychlist1972]

Clickbait? Really?

isallthisclickbaittoo.png

Yes, and all that is click bait as well. Nothing "mysterious" about it, and they aren't banned. Those three aren't the only ones who have run into this, although they make for good headlines. Around 15-20% of the driver partners I work with in the musician space have also run into problems because they didn't update their accounts last year, and I've had to deal with escalations for them over the past months.

Like I said, comms could have been clearer on this so the partners didn't get stuck in this situation. I don't know how the changes were originally announced, but it's obvious that not all the partners got the memo.

But also "Companies who haven't updated info since 2024 miss notification about required attestation and can no longer access accounts" isn't a catchy headline that will drive ad views.

Pete
Microsoft

[lunardigs]

Clickbait? Really?

isallthisclickbaittoo.png

Yes, and all that is click bait as well. Nothing "mysterious" about it, and they aren't banned. Those three aren't the only ones who have run into this, although they make for good headlines. Around 15-20% of the driver partners I work with in the musician space have also run into problems because they didn't update their accounts last year, and I've had to deal with escalations for them over the past months.

Like I said, comms could have been clearer on this so the partners didn't get stuck in this situation. I don't know how the changes were originally announced, but it's obvious that not all the partners got the memo.

But also "Companies who haven't updated info since 2024 miss notification about required attestation and can no longer access accounts" isn't a catchy headline that will drive ad views.

Pete
Microsoft

Oh, ok cool.
No big deal then.

[audiojunkie]

That would never happen with Linux.

"Linux" isn't a thing in this way. You need to look into the requirements for driver submission for specific distributions. For example, RHEL has pretty stringent requirements and process to get drivers into the distro.

The signing and validation requirements here for Microsoft operating systems are to help protect customers from malicious kernel driver code. Another option would be to do like Apple did, and start requiring developers to create user-mode drivers for, for example, all the low-latency audio devices we all rely on, and require special boot modes or settings to allow kernel drivers.

Pete
Microsoft

Well of course RHEL has stringent requirements! They only accept very clearly vetted open source.

But it’s not the same as Windows. Even if some commercial distros were to do what Microsoft does, there are plenty of the 600+ distros that would do things differently. Linux still has WAY more freedom over stuff like this.

Signing and validation requirements just aren’t necessary for Linux, like it is for Windows, because the code is open source and can be scrutinized by everyone. Signing and validation are only needed by for profit OSes that keep their source closed and unavailable for scrutiny.

User mode drivers for many things are actually quite smart. Everything but the absolute essentials would probably be better off run in the user space rather than at the kernel level for security’s sake.

[NWSM]

The Point is, i know how i can make music with Linex.

Wint...Wynd...ach...Windos....anyways...is dead for me.

I like more to struggle with Lenox as with Windos.

cheers muchachos*

[lunardigs]

https://devops-geek.net/devops-lab/wire ... n-freedom/

WireGuard Windows Release: Microsoft Signing Resolution Finally Unlocks Cross-Platform VPN Freedom

After months of navigating the corporate labyrinth of Microsoft’s code signing requirements, WireGuard has released a new Windows version that resolves the long-standing signing resolution issue. This isn’t just another patch—it’s a significant milestone that finally brings WireGuard’s elegant simplicity to Windows users at the kernel level, without the workarounds and sketchy driver loading hacks that plagued earlier implementations.

For those living in the Linux echo chamber, this might seem like a “Windows problem,” but it’s actually a massive win for the entire VPN ecosystem and has serious implications for cross-platform infrastructure, DevOps workflows, and distributed team security ...

[audiojunkie]

https://devops-geek.net/devops-lab/wire ... n-freedom/

WireGuard Windows Release: Microsoft Signing Resolution Finally Unlocks Cross-Platform VPN Freedom

After months of navigating the corporate labyrinth of Microsoft’s code signing requirements, WireGuard has released a new Windows version that resolves the long-standing signing resolution issue. This isn’t just another patch—it’s a significant milestone that finally brings WireGuard’s elegant simplicity to Windows users at the kernel level, without the workarounds and sketchy driver loading hacks that plagued earlier implementations.

For those living in the Linux echo chamber, this might seem like a “Windows problem,” but it’s actually a massive win for the entire VPN ecosystem and has serious implications for cross-platform infrastructure, DevOps workflows, and distributed team security ...

I see the improved Windows installation a positive for furthering the adoption of the WireGuard protocol as a standard over OpenVPN. Wireguard is superior in just about every way and should be the de facto standard.

[ampetrosillo]

There are indeed many valid reasons to move away from Windows and Microsoft today. But there are even more reasons to stay with Windows. Installing Ubuntu, Mint, or Arch often leads to a moment of truth, when solving one set of problems usually brings a different set of trade offs and impossibilities.

Many workflows depend on native Windows applications, and a large amount of commonly used software is either missing or only works via Wine or Proton. Linux is not well suited for many everyday tasks that work out of the box on Windows. Usability is another hurdle. For many tasks that could be handled through a graphical interface, you are still forced to use the bash, and this pattern repeats in various ways.

These limitations are largely self-inflicted by the Linux ecosystem itself, rather than being the fault of users or third parties. They stem from fragmentation among distributions, the lack of commercial support, and fundamental design choices in how Linux is structured. Managing everything through a single central system, the package manager, works in theory but creates practical dependency challenges that contribute to these issues. This is a systemic problem that has persisted for more than twenty-five years and shows little sign of ever being resolved. As a developer, Linux often gives me much more work than Windows, which contributes to the situation where there is less software available.

For most users, the lack of native software remains a practical barrier rather than a philosophical one. It is not a question of will. Principles are nice, but they do not get the job done. That is also why Windows still holds a vast majority of the desktop market, while Linux distributions together represent only a small single digit percentage. No Linux distribution functions as a true general purpose platform like Windows, and macOS, the only real competitor, has its own limitations.

Linux works best as a complementary platform for tasks where it truly excels, such as servers, embedded systems, or certain development environments. Even in areas like gaming via Proton, it still covers far fewer users than Windows and has limitations for many mainstream applications.

TL;DR: If I can’t do my job, switching to Linux is simply not an option

Written from Ubuntu as my dual boot system

EDIT, maybe one last word about Onedrive and Bitlocker encryption. I think it is common sense simply not to use it, there are better alternatives. Same for the integrated AI solution. It was one of the first things that i turned off. I don't need a spy AI that makes snapshots from my desktop. These things are not part of the OS, even when Windows makes it look like, by shipping it together with the OS. It's part of the service with which Microsoft makes their money nowadays.

Apologies for basically necroing this quote, since I've only started reading this thread now, but the idea that developing for Linux is harder than on Windows is... imprecise.

It is if you expect to carry the "developing for Windows" philosophy over to Linux.

Linux is a system where everything is intended to be open source by default, and where certain design practices (eg. shared libraries, and secondly Unixisms) are expected to be adopted. It's like coming to Italy to buy a house and complain that you need to go through a notary. It's part of the system. (And this step is devised to do stuff that other countries simply do differently, for example through purchasing contract insurance instead of relying on an official to check whether everything is in order). Linux is community-led and community-oriented. To develop for Linux means to interact with such a community. Especially if you work at the kernel level (but it also applies to user space somewhat).

[Tiles]

There are indeed many valid reasons to move away from Windows and Microsoft today. But there are even more reasons to stay with Windows. Installing Ubuntu, Mint, or Arch often leads to a moment of truth, when solving one set of problems usually brings a different set of trade offs and impossibilities.

Many workflows depend on native Windows applications, and a large amount of commonly used software is either missing or only works via Wine or Proton. Linux is not well suited for many everyday tasks that work out of the box on Windows. Usability is another hurdle. For many tasks that could be handled through a graphical interface, you are still forced to use the bash, and this pattern repeats in various ways.

These limitations are largely self-inflicted by the Linux ecosystem itself, rather than being the fault of users or third parties. They stem from fragmentation among distributions, the lack of commercial support, and fundamental design choices in how Linux is structured. Managing everything through a single central system, the package manager, works in theory but creates practical dependency challenges that contribute to these issues. This is a systemic problem that has persisted for more than twenty-five years and shows little sign of ever being resolved. As a developer, Linux often gives me much more work than Windows, which contributes to the situation where there is less software available.

For most users, the lack of native software remains a practical barrier rather than a philosophical one. It is not a question of will. Principles are nice, but they do not get the job done. That is also why Windows still holds a vast majority of the desktop market, while Linux distributions together represent only a small single digit percentage. No Linux distribution functions as a true general purpose platform like Windows, and macOS, the only real competitor, has its own limitations.

Linux works best as a complementary platform for tasks where it truly excels, such as servers, embedded systems, or certain development environments. Even in areas like gaming via Proton, it still covers far fewer users than Windows and has limitations for many mainstream applications.

TL;DR: If I can’t do my job, switching to Linux is simply not an option

Written from Ubuntu as my dual boot system

EDIT, maybe one last word about Onedrive and Bitlocker encryption. I think it is common sense simply not to use it, there are better alternatives. Same for the integrated AI solution. It was one of the first things that i turned off. I don't need a spy AI that makes snapshots from my desktop. These things are not part of the OS, even when Windows makes it look like, by shipping it together with the OS. It's part of the service with which Microsoft makes their money nowadays.

Apologies for basically necroing this quote, since I've only started reading this thread now, but the idea that developing for Linux is harder than on Windows is... imprecise.

It is if you expect to carry the "developing for Windows" philosophy over to Linux.

Linux is a system where everything is intended to be open source by default, and where certain design practices (eg. shared libraries, and secondly Unixisms) are expected to be adopted. It's like coming to Italy to buy a house and complain that you need to go through a notary. It's part of the system. (And this step is devised to do stuff that other countries simply do differently, for example through purchasing contract insurance instead of relying on an official to check whether everything is in order). Linux is community-led and community-oriented. To develop for Linux means to interact with such a community. Especially if you work at the kernel level (but it also applies to user space somewhat).

You have some really romantic ideas here

The short answer: nope, that’s not how it works in reality, sorry.

The long answer:

The issue here isn’t “philosophy” or someone trying to apply a Windows mindset to Linux. This isn’t about preferences, biases, or aversions. It’s much more concrete than that.

There are real, practical friction points when developing for Linux that simply don’t exist (or exist to a much lesser extent) on Windows:

**Fragmentation**
On Windows you target one clearly defined platform. On Linux you deal with multiple distros, different library versions, packaging systems, and sometimes incompatible environments. That directly leads to “works on my machine” problems.

**Dependencies**
Shared libraries sound great in theory, but in practice you hit version conflicts, missing packages, and inconsistent naming across distros. Static linking is often discouraged, so you’re constantly balancing compatibility and convention.

I’ve had software released on Ubuntu where a Python dependency was effectively broken by a point release just two weeks later, and the application stopped working. Now try explaining that to users of a freshly released product. And this isn’t a one-off, it happens repeatedly.

**Distribution**
On Windows you ship an .exe or installer and you’re done. On Linux you’re choosing between deb, rpm, AppImage, Flatpak, Snap, or source builds. That’s not philosophy, it’s overhead.

**GUI stack**
X11 vs Wayland, GTK vs Qt, different desktop environments and inconsistencies. That adds real complexity to UI development.

**Lack of a stable baseline**
Windows APIs are relatively stable over long periods. On Linux, what you can rely on depends heavily on the distro and stack.

Linux absolutely gives you more freedom, but that freedom comes with real costs in compatibility, packaging, and maintenance. And none of these “freedom” solutions come even close to the usability of Windows.

For me, as a long-time developer, this is everyday reality. On Windows I build an executable and I’m basically done for years. On Linux I’m maintaining multiple formats, chasing distro-specific issues, and dealing with support cases that aren’t even about my software, but about system setup and dependencies.

And when you add it all up, it also explains why there is still significantly less desktop software on Linux. Which is why many people simply can’t migrate, even if they want to, because they rely on specific tools for their work. And often there are no equivalent replacements.

In my experience, there is no Linux distribution that truly competes with Windows in this regard. It can be “good enough” for some use cases, no question. But if I can’t reliably get my work done, then switching simply isn’t an option.

[ampetrosillo]

There are indeed many valid reasons to move away from Windows and Microsoft today. But there are even more reasons to stay with Windows. Installing Ubuntu, Mint, or Arch often leads to a moment of truth, when solving one set of problems usually brings a different set of trade offs and impossibilities.

Many workflows depend on native Windows applications, and a large amount of commonly used software is either missing or only works via Wine or Proton. Linux is not well suited for many everyday tasks that work out of the box on Windows. Usability is another hurdle. For many tasks that could be handled through a graphical interface, you are still forced to use the bash, and this pattern repeats in various ways.

These limitations are largely self-inflicted by the Linux ecosystem itself, rather than being the fault of users or third parties. They stem from fragmentation among distributions, the lack of commercial support, and fundamental design choices in how Linux is structured. Managing everything through a single central system, the package manager, works in theory but creates practical dependency challenges that contribute to these issues. This is a systemic problem that has persisted for more than twenty-five years and shows little sign of ever being resolved. As a developer, Linux often gives me much more work than Windows, which contributes to the situation where there is less software available.

For most users, the lack of native software remains a practical barrier rather than a philosophical one. It is not a question of will. Principles are nice, but they do not get the job done. That is also why Windows still holds a vast majority of the desktop market, while Linux distributions together represent only a small single digit percentage. No Linux distribution functions as a true general purpose platform like Windows, and macOS, the only real competitor, has its own limitations.

Linux works best as a complementary platform for tasks where it truly excels, such as servers, embedded systems, or certain development environments. Even in areas like gaming via Proton, it still covers far fewer users than Windows and has limitations for many mainstream applications.

TL;DR: If I can’t do my job, switching to Linux is simply not an option

Written from Ubuntu as my dual boot system

EDIT, maybe one last word about Onedrive and Bitlocker encryption. I think it is common sense simply not to use it, there are better alternatives. Same for the integrated AI solution. It was one of the first things that i turned off. I don't need a spy AI that makes snapshots from my desktop. These things are not part of the OS, even when Windows makes it look like, by shipping it together with the OS. It's part of the service with which Microsoft makes their money nowadays.

Apologies for basically necroing this quote, since I've only started reading this thread now, but the idea that developing for Linux is harder than on Windows is... imprecise.

It is if you expect to carry the "developing for Windows" philosophy over to Linux.

Linux is a system where everything is intended to be open source by default, and where certain design practices (eg. shared libraries, and secondly Unixisms) are expected to be adopted. It's like coming to Italy to buy a house and complain that you need to go through a notary. It's part of the system. (And this step is devised to do stuff that other countries simply do differently, for example through purchasing contract insurance instead of relying on an official to check whether everything is in order). Linux is community-led and community-oriented. To develop for Linux means to interact with such a community. Especially if you work at the kernel level (but it also applies to user space somewhat).

You have some really romantic ideas here

The short answer: nope, that’s not how it works in reality, sorry.

The long answer:

The issue here isn’t “philosophy” or someone trying to apply a Windows mindset to Linux. This isn’t about preferences, biases, or aversions. It’s much more concrete than that.

There are real, practical friction points when developing for Linux that simply don’t exist (or exist to a much lesser extent) on Windows:

**Fragmentation**
On Windows you target one clearly defined platform. On Linux you deal with multiple distros, different library versions, packaging systems, and sometimes incompatible environments. That directly leads to “works on my machine” problems.

If the software is open source, then it's the maintainers' problem. If it isn't, least common denominator. Or you pick one, two or three distros you support. Or you use containers and static linking, or you do what Reaper does for instance (static linking and no containers). Or you actually provide the maintainers with your source code, after signing an NDA (as if code is that valuable anyway) and you involve them in the process.

**Dependencies**
Shared libraries sound great in theory, but in practice you hit version conflicts, missing packages, and inconsistent naming across distros. Static linking is often discouraged, so you’re constantly balancing compatibility and convention.

I’ve had software released on Ubuntu where a Python dependency was effectively broken by a point release just two weeks later, and the application stopped working. Now try explaining that to users of a freshly released product. And this isn’t a one-off, it happens repeatedly.

That could happen on Windows too. I have a piece of software that no longer works because of the MIDI server change. It used to be finicky, now it just hangs outright. I have *no* way to solve the issue. MS won't do anything of course, I have no easy way to revert to the older MIDI server, and the software itself is basically abandoned. That said, smaller, more subtle bugs happen on Windows too. You don't get the inconsistent naming and missing packages (again, you can pick one or two distros you directly support, or you use some older, mature version of the libraries you need).

**Distribution**
On Windows you ship an .exe or installer and you’re done. On Linux you’re choosing between deb, rpm, AppImage, Flatpak, Snap, or source builds. That’s not philosophy, it’s overhead.

Again, if it's open source, it's the maintainers' problem. If it isn't, do what the others do. Reaper just throws everything into /opt, IIRC.

**GUI stack**
X11 vs Wayland, GTK vs Qt, different desktop environments and inconsistencies. That adds real complexity to UI development.

I'll give you Wayland, because now Wayland can't be ignored anymore. But that would apply to any large infrastructure change on any OS. As for UI libraries, nah, you pick one and use one.

**Lack of a stable baseline**
Windows APIs are relatively stable over long periods. On Linux, what you can rely on depends heavily on the distro and stack.

Linux absolutely gives you more freedom, but that freedom comes with real costs in compatibility, packaging, and maintenance. And none of these “freedom” solutions come even close to the usability of Windows.

For me, as a long-time developer, this is everyday reality. On Windows I build an executable and I’m basically done for years. On Linux I’m maintaining multiple formats, chasing distro-specific issues, and dealing with support cases that aren’t even about my software, but about system setup and dependencies.

And when you add it all up, it also explains why there is still significantly less desktop software on Linux. Which is why many people simply can’t migrate, even if they want to, because they rely on specific tools for their work. And often there are no equivalent replacements.

In my experience, there is no Linux distribution that truly competes with Windows in this regard. It can be “good enough” for some use cases, no question. But if I can’t reliably get my work done, then switching simply isn’t an option.

Again, it's something that matters more for proprietary software than for open source. And anyway, there are things you can do for proprietary software to ensure that it works. I can understand the sprawling nature of Linux causing some headaches, as Ardour for instance was badly packaged and maintained by certain distros for years (but they managed to solve it), but some of this is either overblown or can be solved with a different approach.