Microsoft is certainly within the rights afforded to them by the curl license to do this, but:
> 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.
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".
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.
(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.)
Oh that's a huge dick move. And this behaviour you mention, "people seeking help from libcurl for xcurl" is an already documented and detrimental problem. You can see why Sqlite temp files has an extension of "etilqs". That's a grandiose example of this. That was not even a documentation link!
Another common example is people seeking help at upstream projects for packages provided by their linux distro that have subtle changes which upstream knows nothing about.
Honestly though, that's life. I don't think its that big a deal, if you've ever done open source user support you'll know that people ask about all sorts of crazy things. You're lucky if they are even asking about software and not how to wash a car.
> It seems inevitable that doing this will cause users with questions about xCurl to seek out curl maintainers/forums for support with xCurl
I doubt this will be a large number of people. If xCurl is only available via the GDK, then you get access to it you need to be working for a company that has developer contract signed with Microsoft. If you are such a dev, you will also have access to the Xbox dev forums which _should_ be your first stop for GDK-related questions.
> you can basically deploy stuff to your own Xbox by just signing few things online
Is this true? I've been wanting to be able to develop my own console stuff for a long time, but the hoops have seemed insurmountable so far. Can I really deploy my own stuff to Xbox without having to pay huge fees and have calls with a sales team?
For publishing to some store, that's fine, but just for development I just wanna be able to get a build running without too much red tape, otherwise it's not fun and therefore not worth it.
Ah, this is specifically for Xbox apps, not games. You're not getting access to a bunch of things with this method (especially w.r.t. graphics APIs.) As far as I can tell, the full GDK is still behind a contract and NDA.
> How do I run a GDK game built for the Xbox App on Windows 10 or Xbox Game Pass for PC on Xbox Consoles?
> Xbox console development requires the “Microsoft Game Development Kit with Xbox Extensions (GDKX)”. Games will need to retarget and rebuild for Xbox One or Xbox Series X|S with the GDKX installed.
> You need to download, install, and retarget your project for Xbox consoles using the GDKX
> The GDKX is currently only available under confidential license within an NDA Xbox program (e.g. ID@Xbox).
Yeah, its a somewhat unfortunate reality that if you want to get full access to the consoles, you need to be an actual gamedev and sign some contracts. Microsoft does not suffer poor fools just trying to learn how to get the most out of the Xbox. Sony is much the same in this regard, and nevermind Nintendo.
I do wish they made Xbox more available to students in gamedev/cs degrees. When I was in school, Microsoft actually sponsored the program I was in, and I had a chance to work on Xbox stuff that as a student I would not have had any access to otherwise; That ended up being really useful to my early career -- not a lot of college grads have experience with developing and publishing for real on Xbox.
I think that's the case for 'Apps' but not games. Like I said in another post, my info is several years dated at this point, so things may have changed, but when I was in this field, if you wanted to publish a game vs a non-game app, there were many more requirements. Apps had pretty limited amounts of scrutiny and certification hoisted on them, while games had several hundred certification requirements for a ton of different things they had to meet. Apps also did not get access to the full capabilities of the console, whereas games did. Under the hood there were quite a few differences between how apps and games were provisioned, published and run -- games are almost like a container image rather than a regular windows app.
Oh if you want to _publish_ I'm sure it's a whole different ballgame, but if you're just playing around and/or developing a game (and don't need a full on DevKit), it's relatively straightforward.
AFAIK this isn't really true. Microsoft made the GDK public, but only for targeting Windows 10/11. The portion for targeting the Xbox is still under NDA. You can get access to developer mode for your Xbox by signing a few things online and paying a nominal fee, but that level of access only lets you deploy UWP apps to your Xbox, not do native development.
I don't know what it's like on Xbox, but I recently had to set up an identity provider in AWS that delegates to Azure AD, and Microsoft's documentation claims the integration is single-click with IAM Identity Center to generate the SAML config using an app tile available in their app catalog in Azure. This may be true in general, but it's not true for their FedRamp environment, and the devs with access to Azure, which I did not have, couldn't figure out how to do it manually. This customer obviously had a paid account in Azure, along with plenty of other enterprise IT services purchased from Microsoft, and it still took four weeks for Microsoft to finally get them a scheduled meeting with a solutions architect who knew how to do what they needed to do.
I agree it is. A fitting return volley would be to insert a note in the documentation along the lines of "derivative implementations of curl may have important differences from the documented implementation. Please refer to the derivative implementation's documentation for any behaviors that don't appear to conform to curl's implementation".
Yes, they should make it clear that xCurl has nothing to do with real curl.
But if it intends to implement the same interface, I don't see any problem with saying look at the curl docs for what its supposed to do. I don't see how that would be much different then if you implemented your own web browser and was like, look at MDN for how its supposed to work.
"Hey, your docs say that curl should be doing this, but it's not working for me?"
<2 pages of back-and-forth posts later>
"Oh you're using xCurl, yeah you need to talk to Microsoft."
It probably depends on the reach this has within the intended audience (people wanting to deploy libcurl on Xbox?) as to how much of a support burden it will end up, but I suspect more than Mozilla has to deal with from similar situations.
bawolff says it wouldn't be a problem to just link the curl docs.
Cogito says it would, since users would just ask Daniel for help, thinking xCurl was the same as curl, despite them having different implementations. This would place a large burden on Daniel.
The point I'm supporting is that users will not realise that the documentation that is linked to is from a different project than the one being used.
Hopefully, by focusing on an example of how a support interaction could go (clueless user, lots of back and forth before the key issue is identified), it shows how this practice is good for neither users nor for the curl team who will end up dealing with the fallout.
I also address the MDN example by stating that I suspect the audience and reach of xCurl will create a larger support burden for curl than Mozilla would see in similar situations (aside: even though it wouldn't be reasonable in that case either!)
Unless it's done very carefully, pointing users to the parent project's documentation will cause a support burden on that project, and that's just not reasonable for Microsoft to do in this situation.
If this was an Alpha software that was created a few months ago and is rapidly changing then sure, link back to the original.
But we’re talking about curl here. MS could have an intern copy paste the curl document, delete the stuff that doesn’t apply to XCurl, and host it on a shared OneDrive Word document all within a day, and it would be orders of magnitude a significantly better experience.
Instead curl maintainers will end up spending man years supporting XCurl issues instead.
What if you called your browser xFirefox, and suggested it would be equivalent to "Firefox" on the MDN "Browser compatibility" tables. And you have 1000x the resources of Mozilla at your disposal.
Based on the limited implementation surface and marriage to WinHTTP I would've imagined simply writing their own API distinct from curl's would've been a smarter choice, albeit with worse SEO to leech from curl.
> 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.
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".
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.
(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.)