The Windows Driver Frameworks are on GitHub

There are actually some strong OS voices in Microsoft. I was at Solutions Linux in France (around 2006 iirc) and there was a Microsoft booth. Since our booth had some downtime I talked to the guy manning their booth who was kind of stranded between Linux distros and FLOSS companies.<p>He was pretty cool and genuinely trying to advance OS within Microsoft but said it&#x27;s a pretty frustrating experience overall (his descriptions of the internal processes at Microsoft were pretty interesting). Seems like they have come a long way since, I hope he&#x27;s still working there. I should have his card somewhere at home :)<p>So as far as I know there have been developers who were pushing to open source a lot of infrastructure&#x2F;language stuff for quite some time.<p>Edit: I think it&#x27;s no coincidence we see this happening now that Ballmer is gone. He was kind of the villain in the &quot;let&#x27;s open source stuff&quot; stories I heard.

I must say, I&#x27;m very impressed with all of the open source moves that MS has done lately. I wonder if that will drive more adoption of C# and cause Oracle to open up Java. I&#x27;m not a fan of C# because it&#x27;s basically only used on windows systems, despite xamarin and et al.

What effect will this have on the ability to boost driver support in Linux, if any? FreeBSD has ndisgen [1], but would this help improve that or a broader set of driver use in Linux?<p>Secondly, what about WINE?<p>[1]: <a href="https://www.freebsd.org/cgi/man.cgi?query=ndisgen" rel="nofollow">https:&#x2F;&#x2F;www.freebsd.org&#x2F;cgi&#x2F;man.cgi?query=ndisgen</a>

This is slightly off topic. However maybe someone on this thread can point me in the right direction. Can anyone recommend some good resources to get started writing low-level drivers for windows (books or open source examples)? I work mostly with embedded software on custom project. From time to time I need to interface with Windows machines and the information of this topic has always been limited.

One barrier to developing drivers for Windows is the driver signing policy <a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff548231(v=vs.85).aspx" rel="nofollow">https:&#x2F;&#x2F;msdn.microsoft.com&#x2F;en-us&#x2F;library&#x2F;windows&#x2F;hardware&#x2F;ff...</a> which requires you to pay for a software publisher certificate.

The open-sourcing is a sign that MSFT is in a tricky spot (BYOD, mobile, tablet, games) and desperately needs to improve relations with the outside world. Expect we&#x27;ll also see MSFT using more open source in products to compete effectively though I wonder what&#x27;d happen with internal best practices that the outside world doesn&#x27;t have, e.g. SAL. Will they contribute back? Let&#x27;s see.<p>Inside MSFT there used to be minimal credit for releasing source which was a strong inhibitor in the employee review process. And a gratuitously awkward internal process for open sourcing code with no path for accepting changes&#x2F;contributions. Attitudes are definitely improving.<p>The major benefit of this particular move will be when you&#x27;re working on Windows drivers - now you can see and completely grok what a piece of code does until it transitions into the kernel proper.

&quot;we understand there’s no substitute for having OS source available&quot; Ho ho ho.

Will it help making drivers for filesystems which MS doesn&#x27;t care to support?

I don&#x27;t see a patent grant...

Whiny ass comments so far. Bravo Microsoft!

&quot;First they ignore you, then they laugh at you, then they fight you, then you win.&quot; -Gandhi

I hope Microsoft knows this, but Open Source doesn&#x27;t imply putting your source on GitHub (and vise-versa). If Microsoft dev teams served source tarballs along with their releases, we&#x27;d be just as happy. But perhaps they will actually use the GitHub issue trackers and other neat features, as they are pretty useful.