Microsoft is certainly within the rights afforded to them by the curl license to do this, but:<p>> The provided functionality is certainly a very stripped down and limited version of the libcurl API. A fun detail is that the quite bluntly just link to the libcurl API documentation to describe how xCurl works.<p>is IMO a major dick move. It seems inevitable that doing this will cause users with questions about xCurl to seek out curl maintainers/forums for support with xCurl (as with the email that prompted this article), even though they have no insight at all into how xCurl works. And some of those people might not be very happy with the response "we have no idea - try contacting Microsoft".<p>Now, that might not have been Microsoft's deliberate intent, but I don't see how it's anything but completely forseeable, and should have been avoided.<p>(Yes, Microsoft need to credit curl with the copyright info and license, but the place for that is the "Credits" and/or "License" parts of the documentation, not the "Usage"/"API reference" parts.)
The mentioned security requirements likely have to do with certification requirements for games released for the Xbox. You couldn't just make network connections willy-nilly, there was some amount of having to declare ahead of time what ports you would be using and for what. The normal socket API is also severely limited, and largely cannot even be used without obtaining a special exception from Microsoft for your games.<p>I was actually at one point (years ago) tasked with determining if we could use curl in a project I was working on. There was indeed much surgery needed to ensure that the code even compiled, much less worked correctly. We ended up just using WinHTTP directly instead.<p>As for getting access to the source code for xCurl, that will likely not be possible without actually signing up as a dev with Microsoft and going through the whole process. And even then, you'd be under a NDA.<p>(My information is several years old though, so it might be somewhat outdated)
The voice of the battle-weary maintainer comes through clearly in this one. I can't imagine the burden of being responsible for something as widely used as curl. Ok, I can kind of imagine it, or I wouldn't be writing this comment. That feeling of "oh no, someone has just created a support nightmare for me" is familiar, even if I've only experienced it at a minuscule scale in comparison.
As a cynical Enterprise person, my take is that some team within M$ wanted to force some other team to no longer use Curl/Libcurl for "reasons", so they had to gut it and replace pieces with some other team's cruft. There is no interest in upstreaming, supporting, extending, documenting, releasing, etc this monstrosity as it was probably an ugly kludge to meet an internal bureaucratic requirement.<p>This is why the MIT license is great. If it was GPL'd or something, they would have to rip out curl <i>entirely</i> and develop a completely in-house library, which takes more time, costs more, adds bugs, etc. On top of adapting any programs that normally use libcurl to use their custom thing, or creating a shim library (either way more work). MIT-licensed code allows corporations to still build on top of open source, and monkey-patch their own shittiness in the process. Many of us OSS devs choose MIT for this reason: we just want more people to be able to use it.
Obvious question, why didn't they just implement the security features necessary? They could have contacted Daniel to get his cooperation.<p>Edit: Answer is in the comments. So they should have just implemented a wrapper ontop of libcurl. But I guess the real effort here is to promote WinHttp as a replacement for libcurl. And since the developer community at large is so used to libcurl they made a wrapper for WinHttp instead. Oh lord.
So in summary, this seems like it could be a security issue waiting to happen for games that use that xcurl lib from Microsoft, since it seems they don't keep up with upstream and will miss important patches.<p>How that improves "Microsoft security requirements" is beyond me, really.
Speaking of strange Microsoft CURL variants, have you ever faced problem with HTTP2 in practically any network client (for example Eclipse strangely failing all attempts to fetch from new HTTP2-enabled Maven) that could be traced to<p><pre><code> C:\Windows\System32\curl.exe
</code></pre>
failing handshakes with such HTTP2 servers, whilst any other CURL (from e.g. git-for-windows, even with lover version) could connect to the same server correctly?
> I have not been able to figure out how to download xCurl in any form<p>I think it will be somewhere in here. It will probably get installed on your PC with this thing.<p><a href="https://github.com/microsoft/GDK">https://github.com/microsoft/GDK</a><p>edit: you can see references to xurl.dll and xurl.h here, which is GDK examples<p><a href="https://github.com/search?q=repo%3Amicrosoft%2FXbox-GDK-Samples%20xcurl&type=code">https://github.com/search?q=repo%3Amicrosoft%2FXbox-GDK-Samp...</a><p>so the xcurl.dll and xurl.h is really probably in the installer.
If you excuse some speculation:
(clarifications appreciated of course.)<p>If i remember correctly, ages ago (Windows Server 2003?) Microsoft introduced in-kernel HTTP-handling for the IIS web-server. I think it was for performance improvements with less copying between kernel- and user-space memory.<p>I suspect the for me unknown WinHTTP apis mentioned here could use these optimizations? Maybe that's why they mention security requirements? (Which would obviously be needed when doing parsing in the kernel.)
I'm aware that this is utterly childish, but still wondering how far one would get, forking Visual Studio Code and calling it XVisual Studio Code.
The tone of this article is really strange. It somehow sounds like the author is upset that someone forked his project. (There are several indicators of that throughout the post.) That's the whole point of free software. If you didn't want that, you shouldn't have chosen a free software license.<p>Also, as explained in other comments, it's unlikely this is actually a fork of curl. It's more likely it's just a wrapper around winhttp with a curl-like API.
Yeah those corporate kindlings deeming themselves "senior developers" or whatnot have those ideas all the time. In this case the schizophrenia is that on one hand Microsoft is using unmodified curl in Windows (used by "billions"), and it's okay. But on the other hand for their game blahblah SDK the "requirements" are higher so they do need to have to maintain separate fork. That's not curable I think.
Given that their own implementation of curl itself answers with "curl : The remote name could not be resolved: '--help'" just for trying to figure out how to use the damn thing, I wouldn't count on XCurl to be implemented with any degree of competence either.
I'm surprised that they don't just use Invoke-Webrequest from PowerShell.<p>That has to be good enough since Microsoft insists on having "curl" as an alias for Invoke-Webrequest.