5 ms·

I claim MS Crypto API is even worse (I used both Crypto and ETW on the same project, it's by far not as bad, good luck tuning it not to lose buffers under load

by vl 12y ago

I claim MS Crypto API is even worse (I used both Crypto and ETW on the same project, it's by far not as bad, good luck tuning it not to lose buffers under load though): I was implementing TLS/SSL in one of the services working at MS. I couldn't figure out many things from MSDN and samples - they would not cover error and some variations code paths, and there was just no way to figure it out. And recovery would be something like "in third buffer there will be value x, you have to it pass to other function". And there was a need to do it correctly for obvious reasons, really. So finally I requested access to IIS sources to see how it's done correctly, and discovered couple thousand lines of code with comments like this "xxx told us that buffer X will contain value bla if condition Z is met, and this is why we are doing it here". I had no choice but to cut-n-paste it to my service. I can tell you for sure, nobody outside MS, without access to internal sources? can implement TLS/SSL correctly by using MS Crypto APIs.

klodolph 12y ago
I think it has to be the sheer number of APIs that Microsoft has developed: they just don't have the resources to care about very many of them. It stems from Microsoft's extremely insular culture in the 1990s and 2000s, where being a "Microsoft developer" meant that you just didn't read code for open-source projects, didn't look at competing APIs, just did everything your own way. Apple had its own bad APIs, and blew a bunch of them away when OS X came along. So you want TLS/SSL on OS X, the typical way to do it was to just use OpenSSL. OpenSSL has tons of problems, but at least they're well-understood problems, with source code and documentation.
- wfunction 12y ago
  > OpenSSL [...has...] documentation Did you really praise OpenSSL for its documentation? Honestly, until now I thought it was the de facto example of poor documentation.
  - kibibu 12y ago
    > well understood problems, with source code and documentation Perhaps the comma should be removed.
  - vl 12y ago
    While OpenSSL has bad documentation - there are both source code and real-world usage examples (from open source products using it) to help.
  - klodolph 12y ago
    My point was that even though OpenSSL documentation is bad, enough people understand how it works that using OpenSSL may be preferable to designing a new API... unless/until you have the resources to design a better API.

by vl 12y ago

klodolph 12y ago

I think it has to be the sheer number of APIs that Microsoft has developed: they just don't have the resources to care about very many of them. It stems from Microsoft's extremely insular culture in the 1990s and 2000s, where being a "Microsoft developer" meant that you just didn't read code for open-source projects, didn't look at competing APIs, just did everything your own way. Apple had its own bad APIs, and blew a bunch of them away when OS X came along. So you want TLS/SSL on OS X, the typical way to do it was to just use OpenSSL. OpenSSL has tons of problems, but at least they're well-understood problems, with source code and documentation.

wfunction 12y ago
> OpenSSL [...has...] documentation Did you really praise OpenSSL for its documentation? Honestly, until now I thought it was the de facto example of poor documentation.
- kibibu 12y ago
  > well understood problems, with source code and documentation Perhaps the comma should be removed.
- vl 12y ago
  While OpenSSL has bad documentation - there are both source code and real-world usage examples (from open source products using it) to help.
- klodolph 12y ago
  My point was that even though OpenSSL documentation is bad, enough people understand how it works that using OpenSSL may be preferable to designing a new API... unless/until you have the resources to design a better API.