Fog Creek Software
Discussion Board




We don't write algorithms anymore, we call APIS

A discussion of "Working on CityDesk, Part 4"

http://www.joelonsoftware.com/stories/storyReader$412

Joel Spolsky
Monday, October 29, 2001

Erm, part 4 is really an eye opener.

I've always held a company like FogCreek in high regard. In a way it seemed like a programmer's utopia where good software engineering are the highest priority.

How on earth then does a major feature like passive FTP get left out? A feature which when left out makes it "useless to a large number of people". And this is a product that's already in beta.

Sorry, don't mean to rant, but I'm in a state of shock....

Victor Ho
Monday, October 29, 2001

This article reminded me that tool choice *does* matter.  When I write Win32 client-side applications, I generally use Delphi, which solves many problems quite effectively.

For example, with Delphi, in a few minutes I can find, download, and install native FTP components, capable of passive mode.  I can choose between multiple implementations, free or commercial, mostly with source code.  I can do all that needs to be done, right in Delphi, without a need to switch to C++ to wrapper WININET.DLL, for example.  If I choose native Delphi components, they can all compile in to the application, thus avoiding the problems which Joel may be experiencing soon:

* WININET.DLL might not be there, and might not be the right versions.  There may be different bugs in different versions.

* VB apps which use COM components are sometimes troublesome to deploy and support.

If I did decide to use WinInet, I still could do it all right in the same language; no need to switch to C++.

It's not my goal to engage in a language flame war, only to point out that there are consequences to tool choice.  There are no doubt problem spaces for which VB is a better choice than Delphi.


By the way, I'd love to hear the details on how to use Google to search the MS knowledge base.  Their search interface seems is painful.

Kyle Cordes
Monday, October 29, 2001

I hear you on Wininet.dll .. it's a mess. I write software for Windows CE, and found this nugget in the latest PocketPC 2002 devices:

FTP doesnt work anymore (it used to) on secure FTP connections. It will always transfer anonymous as username and password.

WHAT! Doesnt ANYONE test this? It USED to work.

Grr.

Steve
Monday, October 29, 2001

There are tried and trusted open source no obligation free libraries in Delphi. There would have been no sleepless nights, but a simple download would have sufficed. But alas with VB no luck...

Sunish Issac
Monday, October 29, 2001

On the previous posting with regard to searching MS knowledgebase, Use google advanced search and then search only in the domain support.microsoft.com. That should do, or you can use the normal serach page and then put in your keywords followed by site:support.microsoft.com

BTW a search in google groups on any programming problem will result in more hits from delphi related newsgroups as Borland has less documentation but more helpful community guys out there. See stuff like http://www.delphi-jedi.org and you will understand....

Sunish Issac
Monday, October 29, 2001

<quote>
By the way, I'd love to hear the details on how to use Google to search the MS knowledge base. Their search interface seems is painful.
</quote>

Enter a query such as:

site:www.microsoft.com wininet

Cedric
Monday, October 29, 2001

We seem to spend more and more time debugging obscure configuration and bugs in other people's canned software.

I just wonder how long it will be before all productive programming comes to a complete stop as we spend 100% of our time debugging the canned stuff.

You can search using google by just calling up www.google.com and typing your search in the box.  Even better, if microsoft has deleted the web page you are looking for, google has a copy under the cached entry.  If you don't see anything under the Web tab, just click on the Groups tab to search the Usenet.

Jim Crockett
Monday, October 29, 2001

Actually if you are running a packet filter on your network
and things "just hang" when trying to access something that the rules do not permit, it usually means you have misconfigured
your packet filter rules to just discard any packets instead
of sending back an appropriate error  ("connection refused" for tcp or an icmp "destination unreacahble" message for udp).

Anonymous Coward
Monday, October 29, 2001

I'm sooooo glad to be programming in Java! Great horror story!

Matthew Pope
Monday, October 29, 2001

As an author of ATL Internals and a close, personal friend of Don Box, I can tell you that you're absolutely right. Very few folks really understand COM or ATL, which is why I'm such a fan of .NET.

If you need help with COM or ATL in the future, let me know. I'm a fan.

Chris Sells
Monday, October 29, 2001

Once in a long while I find something in the Java API that's supposed to be threadsafe and it isn't. An example is SimpleDateFormat. But generally, nothing like "we don't do passive ftp".

Joel's argument about managed code applies better to Java than almost any language he mentions. Yet I don't understand the quote "WORA is more of a benefit Sun than it is to programmers"as it  simply flies in the face of analysis. My company, for one, would not exist without WORA (www.webhelp.com).

But languages aside, Joel could have taken a note from the gaming industry, who face the same constraints as he does with citydesk and file transfers through firewalls. How do they do it? They use one socket, not two like FTP does, and manage the file transfer via data framing the socket. HTTP File Upload works this way too.

But then why use any custom protocol for this? Citydesk s/b using an open stand for maximum interoperability: they should use DAV, which, incidentally, doesn't have issues with things like PORT and opeing the data socket like FTP does. But if you're weaned on Microsoft code for most of your professional life, interoperability is not at all a priority, so I understand the cultural forces at Fog Creek surrounding this.
You can love Microsoft all you want, but in this day and age, where the Internet is the single most influential force in computing, Microsoft would love for the Internet never to go beyond MSN and TCP/IP would be the idle dream of research scientists. Writing 'Net-based code, Joel should be mindful of this.

Nick Bauman
Monday, October 29, 2001

"Nowadays a good programmer spends a lot of time doing defensive coding, working around other people's bugs."

Actually, I would say *most* of my time is spent doing that.  Thanks to a few years of experience (and design patterns), I usually find the design phase to be pretty painless.  It's the unavoidable "gotchas" that take up all the time.

I'm just old enough to remember the good old days of writing BASIC for CPM.  Back then, the challenge was, how good an algorithm can you come up with?  How can you hand-tune your code to make it faster?

Nowadays the challenge is, how many websites are you familiar with that might have the clue you need to work around the stupid Microsoft bug you're fighting?  Not quite as inspiring, somehow...

Larry
Monday, October 29, 2001

Thank the Lord that my company uses Linux. If i found a moronic bug like that, i'd go find the source to the library, fix it by adding about three lines of code, submit a patch to help others who run into the problem, and go on with my day.

Think about that next time you're tossing and turning in the sheets.

.
Monday, October 29, 2001

he developers life has changed indeed and not in better :(. Oh, how I miss the good old times.

When I decided to make my company I tried to live from Open Source work only because when I switched completely to Open Source, the quality of my life has increased considerably. It's still hard, but the stress is less, if something doesn't work I always have the sources and I'm able to fix it. Even more submitting the patch I'm almost sure that a future version will have the things fixed. The company is entering it's second year, we live, we won't be the reachest people in the world but who cares. Let's hope it will work for ever. Let's hope that when we will have an product will be able to find a business model around OS.

BTW, I don't know if it helps, but what about libcurl (http://curl.haxx.se), it's quite popular in 'nix world and if I remember well, the license is business safe ;) + it has support.

Remus Pereni
Monday, October 29, 2001

I was wondering how many 'you wouldn't have this problem if you used [Java|Open Source|Delphi|whatever]' replies Joel would get. And maybe he wouldn't. But he would have other problems instead. And it's not like incomplete or flawed libraries are unique to Microsoft.

Dave Rothgery
Monday, October 29, 2001

Nick Bauman:

They use one socket, not two like FTP does, and manage the file transfer via data framing the socket. HTTP File Upload works this way too.

But then why use any custom protocol for this? Citydesk s/b using an open stand for maximum interoperability: they should use DAV [...]

Easier said than done; I bet the FTP upload is required
to PUT a file somewhere, and you have to support what's installed NOW.  A custom file transfer doesn't cut it, even HTTP upload isn't supported in a lot of configs, and DAV is not widely available yet.  Joel, I feel your pain ;)

Love the bit about the magic constant in the ATL wizard-spooge, BTW.  That sums up why Code Generating Wizards Are Crap, IMHO (unless they're implemented right -- but that would be another story I'd guess...)

Remus mentioned (in UNIXland) libcurl; it does work well, or just shelling out to 'wget' or similar works nicely too. But then, they're UNIX stuff, so wouldn't work in this situation... although it makes me wonder if bundling a Windows command-line tool which does this, would be possible?  (that's my UNIX-centric thought processes
coming through, I suppose, where the command-line sometimes *is* the API ;)

As someone mentioned, I try not to use third-party
libraries unless I have to -- and when I do, I try to make
sure they're open source.  That way I can fix the bugs myself when I run into them.  After all, Murphy almost guarantees that you will.

Justin Mason
Monday, October 29, 2001

Ahh, ATL nightmare.

I couldn't agree more. I developed an ActiveX control for the Web and while the MSDN tutorials got me something working quite fast, working around the quirks was a nightmare.

//

Example #1 : try reading contents from an array (VT_DISPATCH) from your control. I spent 4 to 5 hours trying to find only an example. Of course, arrays in VBScript and Javascript are stored differently, because it makes so much sense. I found ONE example (for JScript arrays) which enumerated the array and crashed Visual C++. Oh, great. I gave up, and got away with strings. I love strings, there's nothing you can't do with them.

//

Example #2 : package your control for use on the Web. Now, packaging a standalone control works fine. Packaging a control along with one DLL works fine. Packaging a control with multiple DLLs is ... wow. I actually spent about twice the time than Example #1 on only SCOURING THE WEB. That was a nightmare. And I had ... no success.

Scoured Google, groups.google, MSDN over and over, nothing. Found wealth of information on lots of things, some related, some unrelated. Had to listen to an archived audio webcast to learn that IE was generating an error file in its temporary folder (Memorable quote : a Microsoft engineer explaining the process ... "And of course, if IE has some internal problems, like, like ... crashing" gee, thanks). Did I mention the error file did not contain any useful information ? (Merely something like "oh, it failed").

Finally, aching for a little sleep, I tried something out of despair and it worked. So now when I want to package a control along with multiple DLLs, I don't waste time listing them in dependancy order (unlike what's specified in the documentation) and do not include any class-id information (again, unlike what's specified in the documentation).

//

Meanwhile, kudoos to Google. It's the most useful programming tool I ever used. Microsoft's search engine is a mess, returning results for WinCE and all ... gee. And thanks for the Google search tip.

patrick
Monday, October 29, 2001

Joel writes "What I discovered is that Internet Explorer doesn't crash in this situation -- it shows an hourglass and freezes for a couple of minutes, waiting for the time-out it knows it will get. This proves that Microsoft's programmers knew about this bug in WinInet and worked around it, instead of just fixing the code in the first place. "

Here's a different explanation:  The programmers who built the FTP UI in Internet Explorer believed that the Internet has the same latency and reliability as Microsoft's internal network. They never thought to add a mechanism for canceling an FTP hang because they thought that the hangs were the network's fault.

A poster on this forum writes "Thank the Lord that my company uses Linux. If i found a moronic bug like that, i'd go find the source to the library, fix it by adding about three lines of code, submit a patch to help others who run into the problem, and go on with my day."

Even if the fix is three lines of code (and I doubt that it is),  this is not a one day project as the poster implies.  WININET requires extensive regression testing because of all of the products that depend on it.

Kyle Cordes writes that WININET.DLL might not be there.  WININET.DLL has been part of the base system installation since Windows 98 & Windows NT 4.0 and possibly before.  In other words, it's installed on all of the systems that Joel cares about.

Nick Bauman writes that "Citydesk s/b using an open stand for maximum interoperability: they should use DAV, which, incidentally, doesn't have issues with things like PORT and opeing the data socket like FTP does. "

DAV is not the best solution for a couple of reasons. First and most importantly, DAV is not widely supported by web hosting providers.  Second, you are still on the cutting edge with DAV.  The standard is new and complicated.  The interoperability glitches have not been worked out of all of the DAV implementations.

Victor Ho writes that he's in a state of shock that Fog Creek released a beta without support for passive mode FTP. 

Give Joel a break Victor.  It's very reasonable to assume that WININET.DLL supports passive mode FTP.  In any case, one of the primary purposes of beta testing is to find compatibility problems like this.

gary
Tuesday, October 30, 2001

The Wininet.dll FTP ptotocol can be _very_easily_ called directly from Visual Basic, even in passive mode. Maybe a little bit more difficult than calling those crippled OCX´s.

Microsoft used to have a sample program - called VBFTPJr if I remember the name right. And the sample file had and include file where most of the call declarations for Wininet.dll we listed - even for HTTP.

I have used it nearly 2 years without any big problems.
 
And BTW: this Wininet.dll seems to be the only WIN32 implementation for HTTPS  i.e. SSL.

Igor Pronin
Tuesday, October 30, 2001

The sample VBFTPJr was still there (at the MS site) and downloadable

http://msdn.microsoft.com/downloads/samples/internet/default.asp?url=/downloads/samples/internet/networking/vbftpjr/default.asp

Igor Pronin
Tuesday, October 30, 2001

Others have already mentioned libcurl, which has already been ported to Windows and includes support for thing like http, ftp,  https, ....

The beauty of using soemething like libcurl though is that, whenever I have found a bug in it, I have been able to fix it myself, and when I couldn't, it was fixed maybe a day after reporting it.

Andres Garcia
Tuesday, October 30, 2001

Joel, think about this: how on earth are you going to get solid software when you're relying on dozens of nasty workarounds like this?

And another thing: instead of complaining about ATL and COM+, try something else for a change. Something that will give you less headaches and nightmares. Something that will make you love exception handling. Here's a hint. It starts with a D, and it ends with "elphi". Why don't you just try it?

Frederik Slijkerman
Tuesday, October 30, 2001


Now, I will be very happy if some day when reading JoelOnSoftware I find something like "Today I started using Delphi...". I bet Joel will find his life happier, and will start spreading his happiness to the world.

(BTW, sorry for any mispelling. I speak spanish.)

Leonardo Herrera
Tuesday, October 30, 2001

<Thank the Lord that my company uses Linux. If i found a moronic bug like that, i'd go find the source to the library, fix it by adding about three lines of code, submit a patch to help others who run into the problem, and go on with my day.

Think about that next time you're tossing and turning in the sheets. >

The problem is, he might sell three or four copies of the app if it were written for Linux. :-)

An exaggeration perhaps, but not that much of one.

The fact is, if you're trying to write mainstream applications and counting on the apps to pay the mortgage, it's Windows or Chapter 11.  Nobody much likes it, but that's the way of things at this kind of time, as Capt. Smith said to his crewman when the bow of the Titanic lurched under the waves.

How many copies of Linux CityDesk do you realistically think Joel could sell?

Chris Dunford
Tuesday, October 30, 2001

Joel says:
<I tried it. What I discovered is that Internet Explorer doesn't crash in this situation -- it shows an hourglass and freezes for a couple of minutes, waiting for the time-out it knows it will get. This proves that Microsoft's programmers knew about this bug in WinInet and worked around it, instead of just fixing the code in the first place.>

I don't follow this line of reasoning. You are implying that they had a UI to cancel, realized they had this bug, and changed the UI so they would just display an hourglass without a cancel option. Maybe this happened, but if it did, I am assuming the bug was difficult enough to fix (or found late enough in the product cycle) that they didn't want to risk the destablization of changing a core component.

I agree with your comments on ATL, as do many developers who've shared your frustrations. An alternative to your approach is to just export a couple of functions from a C++ DLL, rather than a COM component. This obviously won't work if you need a real object model, but seems ok for what you are trying to do. It also avoids you having to register a component globally.

Needless to say, .NET was created to alleviate this pain and should be a real possibility for CityDesk v2.

--John

John Veson
Tuesday, October 30, 2001

Chris: I'm not sure that CityDesk really counts as a mainstream app as such.  But your point is valid - my own response to Joel's article was, "and if you used decent free libraries, you could fix it".  Followed by the admission that the only OSes using free libraries aren't viable targets for CityDesk.  You can certainly pay the mortgage writing Linux code, just not necessarily for the shrinkwrap market.

And I doubt Joel feels like porting libwww or libcurl to Windows and giving then VB APIs.

But it also highlights a bigger problem: while Joel is correct that more programming work becomes knowing how to glue the right bits together, it also means work stands or falls on the quality of those bits.  I don't find this a problem in the Perl world, because the army of Perl modules are easy to debug and fold fixes back into; but in the Java/C++ world, a big barrier to this kind of reuse seems to be the opacity of a large chunk of the code you'd want to fix, with that opacity mostly driven by commercial issues.

Rodger Donaldson
Tuesday, October 30, 2001

I enjoyed reading and I found my own situation in almost every sentence. Well, almost.
Back in the early 90s I worked with Netware SFT (some of the old guys will remember that PITA). Almost every 3rd week I discovered a severe bug that made parts of the product unusable. Novell support said they had never seen that bug before.
Later on when Windows entered the arena and things got much worse. The problems were the same and still they are. They let you pay for finding their damn bugs now and when you report them using your support contract they don't fix it.
The amount of time between 2 releases of Windows is too short to waste time on bug-fixing because next year there will be a new release anyway and it will be totally different code.
However, I have discovered that to a significant amount I was the first one to have a particular problem (and in this regard I'd like to contradict Joel).
Well, I wouldn't complain if I would receive a bug-fix after I reported it.
When I bring my new car back to the dealer because of a missing steering-wheel or because they forgot the window panes I don't have to wait until they release their next model and, most importantly, I get it fixed for free! They guarantee for it!
With software I'm not even guaranteed that does what it is supposed to do! Imagine you buy a car just to discover that it only drives backwards! Or it needs some exotic oil that is not available on earth!
I think that's a major problem in this industry. Selling something when you're basically not responsible for it doesn't force you to build the product with an appropriate quality.
The big players (like M$) show us how to still earn money while delivering crap. It's like a drug: first they make you addicted and then they milk you.
And, not that this makes any difference, but I use Delphi. Just like Joel said, I wasn't able to understand C++ as good as I understand Pascal. And I wasn't able to learn Visual Studio within reasonable time.
So I stuck with Delphi which turned out to be pretty good but (of course) not bug free. However, I see the source code of the libraries and it's fairly easy to find and understand. The Delphi community is very helpful and there's tons of freeware including source out there.
If Borland let's me I'll still be programming Delphi when I retire in a few years.

Joe Meyer
Wednesday, October 31, 2001

Gary: "Give Joel a break Victor. It's very reasonable to assume that WININET.DLL supports passive mode FTP. In any case, one of the primary purposes of beta testing is to find compatibility problems like this."

That's not it, programmers make wrong assumptions all the time, that's why debuggers and s/w development forums exist. : )

It was that he Realized that CityDesk didn't do passive FTP. I mean a feature like this should have been specced out when CityDesk first came into conception. The whole development team wasn't even aware that the FTP library they were using didn't support passive FTP.

Now how this  slipped through the feature specification process of product is what i would like to find out.

Victor Ho
Wednesday, October 31, 2001

>Now how this slipped through the feature specification process of product is what i would like to find out.

At a guess it was buried in a set of assumptions such as 'whatever socket library we use will support all the protocols we need'.  Assumptions always look foolish if they don't turn out to be true, sometimes they turn out to be serendipitous events as well.

As in some entirely unforseen Good Thing is the result of a design decision,  naturally the designer takes full credit for having the perspicacity to make that decision.

Simon Lucy
Wednesday, October 31, 2001

Babak, Michael and I did some Archaeology to figure out how this slipped through.

Turns out we had a FogBUGZ titled "test ftp through proxy servers". We couldn't find any ftp proxy servers or anyone using them, so we didn't know how to test this feature (which the old ICP control claimed to support).

Later Babak added a comment to this bug that said something like "And what about PASV"?

When we were cleaning up bugs, I finally decided that ftp proxy servers were too rare in the field to spend any more time on, so I close the bug "as won't fix." I didn't notice the PASV comment.

In conclusion ... this slipped through because we used one bug ID for two bugs, which I've now learned never to do.

It also slipped through because I had a mistaken belief that Microsoft's FTP code *always* did Passive FTP. I do not know why I thought this, but there you go.

And to be fair, it didn't really "slip through." We caught it in the beta, long before we exposed it to the world. There will probably be something ghastly that really does slip through. Murphy's law.

Joel Spolsky
Wednesday, October 31, 2001

If Beta 1 ships and no one finds any major bugs, than you've waited too long to ship beta 1 anyhow.

Either that, or no one cares about the product.

Mike Gunderloy
Thursday, November 01, 2001

Actually, IE does not using WININET library. That because explorer works in case that library doesn't.

Ian Kojurin
Thursday, November 01, 2001

<If Beta 1 ships and no one finds any major bugs, than you've waited too long to ship beta 1 anyhow. >

I think that's probably true--in most cases.  If, however, the beta goes to a large audience of existing users, major bugs can be very, very, very bad, as in ruin-their-data-bad.  I've worked on some projects where this was the case, and you really have to work hard, and hold out on the beta, to make sure to the maximum possible extent that there aren't any serious flaws.

But I certainly agree with your basic point, which I think was to disagree with the comments about it being sorta inexcusable to ship a CityDesk beta with the passive FTP problem.

Chris Dunford
Thursday, November 01, 2001

Another poster wrote:

"Thank the Lord that my company uses Linux. If i found a moronic bug like that, i'd go find the source to the library, fix it by adding about three lines of code, submit a patch to help others who run into the problem, and go on with my day."

I hate it when people make comments like this.  Sure, you'd just pick up 50,000 lines of source code that you've never seen before and make a bug fix.  Right.

James
Friday, November 02, 2001

The coalition of "I'm glad we use Linux because we could just change the source code..." has struck again.

I don't care much for the Linux analogy either.  The person making that comment did not get the point of Joel's commentary. The whole article had a theme. It is a continuation of past articles that describe the emphasis placed on specifications made in the design phase.

Correct me if I'm wrong, Linux had nothing to do with it.

I also believe that calling APIs in Linux can render the same problems Joel is commenting on in this article.

Thanks for taking the time to share your views with us Joel.





Hmmm...

Scott Tracey
Saturday, November 03, 2001

Rodger Donaldson said:

"And I doubt Joel feels like porting libwww or libcurl to Windows and giving then VB APIs."

I'd never heard of libcurl; a quick google found:
    http://curl.haxx.se/libcurl/

It runs on windows and there is a C/C++ API that looks straightforward, so I would expect that Joel could use it quite easily (from his original post it seems that he is more than comfortable writing C++ wrappers around libs).

This, BTW, is exactly the sort of thing that gives me indigestion.  For any component that I find myself needing, I assume that someone, somewhere, has spent the time required to make a stable, fast, easy to use implementation.  But I have to find it.  And if it has problems, I have to fix it (and more likely than not it won't have unit tests, or show any sign of ever being refactored...sigh).

I guess finding good components really is the crux of modern development.  Who would have thought that all of that algorithm stuff would turn out to be mostly useless?  :)

Which leads to the question: why aren't there more good components out there?  Languages?  Tools?  Lack of skilled OO/component designers?  Hard to make money at it?  No demand (i.e. lots of software is written under the MS umbrella, and those developers typically just use the MS offerings)?

And why is it that so many useful, reusable components like libcurl are simply straight C libs?  I thought OO (and OO languages) were the king of reuse?

John Lindsey
Saturday, November 03, 2001

If I were to guess, I'd say C libraries predominate (for cross-platform and Unix stuff; on Windows COM components, usually built in C++ if they're sold commerically, or in VB if they're internal-only, dominate) because...
1) virtually any programming language has a way to call a C library
2) virtually any platform has a good C compiler
3) Almost anyone between 25 and 40 with a CS degree grew up on C.

Dave Rothgery
Sunday, November 04, 2001

Scott: Sure, Linux APIs have bugs too, but you can fix them.

And James, yes, you can pick up a project with thousands of lines of code that you've never seen before, make a quick change, and get on with your life. I do it all the time.

Here's what i would do if i had the source to the FTP library:

Run CityDesk in my favorite debugger and get to the part where it freezes up

Take a look at the stack trace. Look at each function all the way up, and find the best place to stick a timeout. Ideally there's already a version of the "open socket" function which takes an optional timeout, and you just have to change a line of code. At worst, you need to write a short signal handlder and use an alarm() syscall, or whatever the Win32 equivalent is.


And if that didn't work, lets move on down the article...

"The Microsoft documentation for WinInet was pretty decent, as these things go, but not decent enough. In the page documenting FtpOpenFile, you find both of these mutually contradictory quotes: No file handle is returned
Return value: Returns a handle if successful"

So if you have the source to FtpOpenFile, you can immediately write FtpOpenFile2 which returns a filehandle. This is a five-minute job, including the time it takes to find the function.

Moving on down the article... "When you hit the Cancel button, my code tells WinInet to give up and close down the connection. But as I discovered, if you do this in one of these packet-filter situations, WinInet will simply crash, bringing your program down with it. It's clearly a bug in Microsoft's code."

Again, pull it up in the debugger, find out where it crashes, write a short program which demonstrates the flaw, and post it to the mailing list. I've done this with open source projects literally hundreds of times in my career, and when it really is a bug, a patch is always posted in a day or two and incorporated in the next version of the software. Always.


My experience is the same as the person posting as "." -- we simply don't have these problems in the open source world. Yes, there are other tradeoffs -- as someone humorously put, Joel would have about six customers if CityDesk only ran on Linux. But one benefit is that you can always fix these little bugs, or customize your own version of the library.

Mike Schiraldi
Sunday, November 04, 2001

I suppose as a working hypothesis we could assume that open source code is written with absolutely zero coupling between the tiny chunk you're viewing in the debugger and the rest of the project.

But as a practical matter, I don't believe it.

Mike Gunderloy
Sunday, November 04, 2001

Hi (me being lead developer of curl and libcurl)

<a href="http://curl.haxx.se/libcurl/">libcurl</a> is already ported and works for most modern operating systems, <b>including</b> Windows. Since many years in fact.

As "support" goes, I promise you more and faster support for libcurl issues on the mailing lists than you'd ever get from Microsoft on use of their components. For free.

Need fixes fast and you are a company? Pay a consultant to fix your libcurl/curl issues instantly. Wanna know who could do it? Talk to the curl guys.

Wanna add custom stuff or just know how things work internally? Well you got the source, you do the digging.

You found a bug? We're a large crowd who wanna know and who are likely to be able to fix it. At least we've been that for the last couple of years.
Why libcurl is plain C? The reasons were given in previous posts. There's just <b>no way</b> to make a portable, really widely used library using any other language. That's why we encourage and develop "wrappers" or "modules" for interfacing libcurl from other languages. We currently offer eight or nine of those. Feel free to submit yours!

Why there aren't any C++ wrappers? Well, we're an open source project dammit, we wait for <b>your</b> contributions. You don't complain on missing features in open projects, you submit patches that make them come true!

/ Daniel - An open mind in an open world.

Daniel Stenberg
Monday, November 05, 2001

MikeG sez: "I suppose as a working hypothesis we could assume that open source code is written with absolutely zero coupling between the tiny chunk you're viewing in the debugger and the rest of the project.But as a practical matter, I don't believe it."

We're not talking about huge changes here -- Joel's problems were:

- The connection attempt doesn't time out, and that's a tiny, local fix with no impact on any other part of the program.

- A function doesn't return a file descriptor. If you leave the original function as-is, and simply make a clone that returns the fd, it's not going to break anything, and again, you have a localized change.

Again, i make these kinds of changes all the time to unfamiliar code.

Mike Schiraldi
Monday, November 05, 2001

I think the problem was a crashing bug, not a missing timeout feature. By nature, nobody knows how easy or hard that is to fix until the cause has been found. Given source code, adding a timeout feature could be estimated.

Still, I believe that choosing between distributing an app installer with a patch for a shared OS component, or working around the bug is easy for someone who's developing shrink wrap software that needs to ship on time. Patching the OS is just asking for configuration problems.

Johannes Bjerregaard
Monday, November 12, 2001

Hi Joel, thanks for sharing. = )

Victor Ho
Wednesday, November 14, 2001

*  Recent Topics

*  Fog Creek Home