51–60 of 87 posts
MIT licensed cross-platform C. Ten years ago I wouldn't have believed it. Today it's not even surprising. I really like this version of Microsoft.
I'm with you on the licensing side. But C? come on Microsoft.
What use is to have Fort Knox security level if the foundations are built on top of quick sand.
MIT licensed cross-platform C. Ten years ago I wouldn't have believed it. Today it's not even surprising. I really like this version of Microsoft.
Please fire away any questions you may have! I lead the team that built this library. This blog has details on current development status and adoption within Microsoft: https://techcommunity.microsoft.com/t5/networking-blog/msqui...
Does QUIC or your implementation of it support application control of keying or is it always based on x.509 certs and CAs? edit: the spec ( https://tools.ietf.org/html/draft-ietf-quic-tls-27 ) seems agnostic on this. Also simple APIs especially in security are important, so supporting certs only is no flaw in my book, just curious about the edges of how the OS QUIC could be used in the future.
MIT licensed cross-platform C. Ten years ago I wouldn't have believed it. Today it's not even surprising. I really like this version of Microsoft.
I'm with you, and I'm happy that it seems like they are trying to become a good steward in the software industry. I am impressed by the quality of Windows 10, up to about a year ago I used Linux daily because it was a better experience than Windows 98 through 8.1, until recently. Lately, I find it's way easier to run Windows 10 with WSL rather than screw around with Linux trying to get things to work correctly that I…
Weird, I must have some different edition of Windows. Totally inconsistent settings/control panel interfaces, updates taking ages, updates failing when you look at it wrong (and then stuck in update-revert loop every boot), driver setup taking minutes, and I constantly discover some new disk-hogging background process.
Earlier quoted context omitted.
Does QUIC or your implementation of it support application control of keying or is it always based on x.509 certs and CAs? edit: the spec ( https://tools.ietf.org/html/draft-ietf-quic-tls-27 ) seems agnostic on this. Also simple APIs especially in security are important, so supporting certs only is no flaw in my book, just curious about the edges of how the OS QUIC could be used in the future.
QUIC outsources this part of the solution to TLS (specifically TLS 1.3) so you just need a way to meet your needs in TLS 1.3 and it'll work in QUIC
Earlier quoted context omitted.
Was't QUIC was standarized as HTTP/3 what makes it call QUIC not HTTP/3.
No. HTTP/3 is HTTP using QUIC as the lower-layer transport. QUIC itself allows for different protocols to be build on top of it, and was standardized on its own.
• QUIC’s original implementation bound the transport protocol & app protocol to HTTP/2 - this was led by Google and is commonly referred to as “gQUIC”. This is what Chromium implemented and could be used via the Cronet library in other contexts. • A desire to use QUIC as a stand-alone transport layer (above UDP) grew, and is now standards-tracked as “IETF QUIC”. • HTTP/3 is a evolution (rather than a revolution) of HTTP/2 that requires IETF QUIC as a transport.
Earlier quoted context omitted.
Isn’t the Windows kernel C++?
The Windows kernel is mostly C, but also parts in assembly and C++. [1] It also helps to keep in mind that back in the late 80s, when development work on the NT kernel began, C++ was still the new kid on the block. NT kernel work began even before ANSI C was done. -- [1] https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...
Microsoft C/C++ 7.0 was released in 1992 alongside MFC 1.0, which was a bit late to the race.
Microsoft was the latest C compiler vendor on the MS-DOS space to integrate a C++ compiler into their tooling.