Joel On Microsoft's API Mistakes 690
AceMarkE writes "Joel Spolsky of Joel on Software has posted an article entitled "How Microsoft Lost the API War". He covers why the Win32 API is important to Microsoft, what they've done to keep it working, why Microsoft's switch to the .Net platform is both a good and bad idea, and why he feels the browser will be the real future of application development. Definitely worth a read no matter what your opinion of Microsoft is."
Re:Why it has to die (Score:5, Informative)
Say what you like about MS's evil ethics but *do not* mock their API docs [microsoft.com]. They're very good.
Visual C++ now free (Score:5, Informative)
Re:Visual C++ now free (Score:1, Informative)
Yeah, they released it a few months ago [slashdot.org]. It's got a few limitations - mostly you only get static libs to link to - but it's still great.
Re:Good idea (Score:5, Informative)
Apple, on the other hand, only broke the API once, with the transition from Classic to Cocoa (the MacOSX API), and even then, they did their best to maintain compatibility, with Carbon.
Re:SourceCode != QualityDocumentation (Score:5, Informative)
KDE's are at http://developer.kde.org/documentation/library/cv
Thats every function call to program in KDE and Qt all completeley cross-refrenced, with examples.
Re:Joel Might Be Wrong (Score:3, Informative)
Anybody who has tried to explain to someone why WINE is not an emulator has probably had to confront this confusion face to face.
I recently got lectured that WINE would always have emulation overhead by a guy who was sitting there writting Win32 binaries . . . on his Linux box.
He still didn't get it when I asked him if he weren't concered about the emulation overhead when he ran those Linux binaries under Windows.
Some people have troubles with the abstraction layer between the physical machine and the logical machine.
KFG
Re:Marc was wrong (Score:3, Informative)
I love this argument about state tracking. Every single server side scripting language posesses some kind of session tracking functionality. Based on IP address as well as some other odds and ends (depending on implementation). No cookies, no mess, and totally invisible to the user.
Saying thats not a valid form of state tracking would be like me telling you that because your unix terminal doesn't lock itself as soon as your keys leave the keyboard, its just a security risk waiting to happen.
Re:Why it has to die (Score:3, Informative)
You haven't done anything very unusual then. I'm writing software that has to support NT4. Try searching for NetSetupComponentInstall. It's a valid API function, but all you'll find are a couple references on Google Groups. .Net for the same reason I won't use Java for anything serious: it requires you to install a huge VM on each machine.
And I have to say I refuse to use
Re:As a (former) die hard web developer (Score:1, Informative)
Re:Why it has to die (Score:4, Informative)
+ finding documentation on ASP vs finding documentation on PHP
In the index, you click "Web Development", "Server Technologies", "Active Server Pages". If that's too hard, you type 'ASP' in the search box in the top left hand corner. OK, the ASP language reference is under the IIS docs but you'll find a link to it from the easy-to-find ASP pages above.
+ finding documentation on VB.NET vs finding documentation on python
OK, I couldn't see this one in the index myself. But I searched for 'VB.NET' in the box on the left and the sixth or seventh link goes to the VB and VC# language docs, complete with reference, which is in the Visual Studio documentation section.
Re:Try POSIX next. (Score:3, Informative)
Re:Increased Irrelevancy, however. (Score:2, Informative)
The IBM technology arm continues to innovate a lot of core technologies. They aren't big and visible to the general public, but they do affect how the world spins. You aren't the world's 17th largest company and become "irrelevant."
Re:Good idea (Score:2, Informative)
Mostly true, but the original Carbon API (IIRC) chopped around a quarter of the cruft that had built up between System 1 and OS 8. There are some apps that don't work well with Carbon (Excel 5, but not Word 6, for example), presumably because they used some of the deprecated API calls.
So in effect, they chipped away at the API by making Carbon, and then made a new one for Cocoa.
Re:Increased Irrelevancy, however. (Score:5, Informative)
Have a chat with Sun, BEA, HP, SCO, Oracle, Linus, or any bank about how "irrelevant" IBM is. I think you're in for an eye-opener.
Garbage Collection (Score:5, Informative)
The main productivity boost in Python, for example, is its dynamic typing. Its simplicity second, and automatic memory management as a third, perhaps.
Also, his claim that you don't have to debug memory leaks with Garbage Collection is a common fallacy. Garbage Collection makes it very possible to leak memory, often in more difficult ways to debug, since the developer is typically unaware of what memory is behind held by which objects as usually there is no need to put much thought into the issue.
Re:Why it has to die (Score:2, Informative)
There's absolutely NO "16-bit windows" support in .NET!
And, since it's written for a virtual machine environment you can't possibly claim it has its roots in old Win16 baggage.
I program professionally on both Mac and Windows and I'd have to say that the Windows .NET API is MUCH easier to deal with than all the "baggage" I have to deal with on Apple's platform! (Like using QuickTime for images, Carbon/Cocoa/NextStep/Objective C, etc.)
MFC has not been actively supported from Microsoft for years. I'd say MFC was their biggest failure. Few people used it for real applications, and MS didn't use it internally for much.
Re:Repeating my comment on OSNews... (Score:4, Informative)
You would be lucky if a GNOME app for GNOME 2.0 even compiles for 2.6. It will most certainly not run if it's already compiled.
I call for BS on this one. Now, if you'd have said "GNOME app for GNOME 1.4", then you'd have been right; but, you know: API breaking does happen, from time to time, especially when an API overpasses the point of being sucky enough to be unextensible.
On the other hand, a GNOME 2.0 app will run, without the need for recompilation, under GNOME 2.6. Flawlessy. In fact, I'm using apps written, tested and compiled with libraries released for GNOME 2.0 under GNOME 2.6.
Another point worth to be noted is that, under Un*x, the DLL Hell is a non-issue, as we've had libraries versioning since day 1. So, I might as well install multiple versions of a library, and yet do not have the need to recompile an application.
Re:Repeating my comment on OSNews... (Score:3, Informative)
BTW, you know there are numerous tricks to do this very thing, right? Such as hidden frames, hidden iframes, dynamic script generation (foo.innerHTML="http://my.server/my/script.js?foo
Flash is where it's at. (Score:3, Informative)
Re:Why it has to die (Score:5, Informative)
I don't think he was saying you want to debug other people's stuff. If you have a full debugging version of all the libraries (your and other peoples) it is *much much* easier to debug problems.
And even though I may not want to debug other people's libraries and such, I have had to. This is how I have found bugs in things like PHP, mod_python and such. They were corner cases to those developers, but they weren't for my applications. I'm thankful I could track those problems down, because my application got back up and running again. Not usually the case when I have proprietary closed libraries.
Ciao!
Re:Repeating my comment on OSNews... (Score:3, Informative)
Misunderstanding WinFS (Score:3, Informative)
While on general lines I agree with the article, he clearly misunderstands WinFS -- the effect might still be the same, as either MS itself is misunderstanding WinFS, or at least selling it badly.
WinFS, or files on a SQL -- not relational [dbdebunk.com] -- database is not about organising for search, but about not having to organise, yet being able to.
With current hierarchical filesystems, we are forced to organise files hierarchically, and that's very often cumbersome. So search functions have to dig into each document and kinda Google it, building a full-text index, and that takes lots of resources and is difficult to do. Not even Apple does it good enough, at least it didn't in my then-Mac OS 9 366MHz iBook.
With an SQL database as the filesystem, even if SQL is so inferior to the relational potential, we get rid of the necessity but not of the possibility of hierarchies: we can still put some or all of our files in hierarchies, but now the specific nodes in the hierarchies where the file is are just some more attributes, so any file can be at several places at several hierarchies, or at none at all. Searching too becomes more efficient, but the real benefit is alternatives to organisation, and therefore the possibility of richer queries and easier remembering.
Re:Why it has to die (Score:4, Informative)
Actually Classic and Carbon are pretty much one and the same. Carbon is Classic with some of the less-used and less-functional API removed, plus some of the newer Mac OS X-related stuff added in.
Classic has a TON of documentation, the print form of it was mostly the Inside Macintosh [amazon.com] series, which had literally dozens of books. The books were separated logically by category (interapplication communication, graphics, human interface, etc) and had extremely detailed documentation on the Classic API as well as tons of examples. Most of that information is still good to use for Carbon, in fact most Classic programs will recompile easily using the Carbon API - just a few minor changes have to be made.
As for ease of use, Carbon and Classic seemed pretty intuitive to me. Certainly no harder to use than the Win32 API and, IMHO, probably easier.
Now the new entry into all of this is Cocoa. Cocoa is the new API that Apple is using for Mac OS X. Cocoa is based on Objective C, a Smalltalk-like language which adds object-oriented ideas to the C language. It does this in a fairly simple manner and doesn't feel as kludgey as the additions which C++ added to C. You can also use both C and C++ code within your Carbon code without too many hang-ups.
The Cocoa API has the poorest documentation of all of these API but it is definitely the most simple to use. It has a form of garbage collection, it has some very nice helper classes, and the method names (they are called messages in Objective C) and class names are very descriptive and intuitive. Of all the API I've discussed Cocoa might be the most difficult API to get information about but once you learn the basics you can really fly in coding with it.
Re:Repeating my comment on OSNews... (Score:5, Informative)
It's not exactly sockets, but you can do an awful lot with the XmlHttpRequest object. Microsoft did it first, I think, and Mozilla has a complete clone. Check out the XulPlanet documentation [xulplanet.com], the Mozilla documentation [elemental.com], the Microsoft documentation [microsoft.com] or this tutorial called Using the XML HTTP Request Object [jibbering.com]
The XmlHttpRequest object is poorly named. Really you're just making an HTTP request, and if the response happens to be XML, there are convenience functions for getting a fully-parsed DOM view of the document. If the response is anything else (plain text, JavaScript, Perl, HTML, etc.) you can do what you want with it, including calling eval() on it from a JavaScript script. You can do synchronous (blocking) or asynchronous (non-blocking) calls to your web server, and either be notified of completion by a callback for non-blocking calls, or just treat it like a function call for blocking calls. It's quite handy, and we have a project at work that makes extensive use of this technique. We have a "thick" or "rich" client application that runs in the web browser. Our client looks like a native application--it has table widgets, with clickable headers that resort the columns, it has a tree widget that looks like the tree in Windows Explorer, it supports drag-and-drop and custom context-menus, and if you open our application in a chrome-free browser window, it's almost possible to forget it's not native (the speed is usually what gives it away, the GUI is a little sluggish...). It works equally well in Mozilla, Firefox, IE 5.5+, and Netscape 7.1+ on Windows 9x, 2000, XP, and many flavours of GNU/Linux (tested on Gentoo and Redhat 7.3, and 8.0 using GNOME, KDE, and some kind of *Box wm). Well, "equally well" is a bit of a stretch. IE's implementation of the DOM is dog slow, so some things run a bit faster in the Gecko-based browsers, but all functionality is equally available in all the configurations listed above. We've managed to stay standards-compliant for the most part, and have abstracted away the quirks in IE, so as soon as Konqueror, Opera and $YOUR_FAVOURITE_BROWSER fully support JavaScript 1.5, DOM 2.0, and CSS 2.0, our app will work in your browser, too. (I don't know which parts these browsers are missing, so maybe our app already works there.)
The only remaining hurdle is to convince management that it should be open-sourced so that other people can use it, too. If you can't wait, you might want to check out SourceForge. There are some other widget kits available for building browser-based apps. We chose not to go with them because, at the time, they were too Alpha-ish, and we disagreed with some design decisions. Our decision not to use those projects has not been revisited for a while though, now that we are rather comitted to our in-house implementation, so things may have improved significantly since the last time I had a look.
Also, if you're going to actually build any significant JavaScript apps (we have more than 40k loc that turns out to be more than 1 meg of JavaScript to download), I highly recommend JSDoc [sourceforge.net]. The main developer, Gabriel, has been very responsive and helpful, and the documentation that his scripts produce is excellent. Especially considering he builds JSDoc in his spare time, I can't compliment his work enough. Now that our codebase is too large for me to keep it all in my head, the API has saved a lot of my time.
Ian
Re:It's about the APPs silly. . . (Score:3, Informative)
Hence the announcement of no new versions of IE except for with future versions of Windows. There has been some recent work on it with the popup blocker + extensions manager and security tweaks for XP SP2, but no major work on the rendering engine.
It seems likely that IEs web standards support will continue to stagnate even after Longhorn is released, there will be no SVG or xsl-fo etc. the best we can hope for is that they fix transparent pngs and css2.1, anything more complicated and interactive will need to be written as a web-installable
You ARE dumb. Stop programming now. (Score:1, Informative)
Someone told me I'm really dumb, because I didn't put a "yield" in my read input loop, but the "comprehensive" documentation in MSDN didn't quite cover that point.
I learnt my multithreading theory using Java 1.1 [sun.com] (by chance at university, but that's not the only place to learn). So far ALL of that knowledge has been perfectly applicable to any language I've written in (C, C++, even VB6, which supposedly doesn't have multithreading).
Yielding is basic thread behaviour and not related to any specific API or OS. If you don't know why you need to specfically yield, then you shouldn't be writing multithreaded applications. Just from your explanation, I can raise issues in basic design. You show a clear lack of understanding on how to accomplish the task. It's scary. It's unfortunate that switching OS "fixed" your problem, since you didn't understand what caused the problem in the first place.
MSDN is not there to teach you how to program properly. It's there so you know how to use the API's that MS supplies. No amount of documentation will allay a dearth of programming skills. In fact, the flexibility and high backwards-compatibility of the windows API is partly to blame for programmers like the parent giving windows a bad name. Bad programming practice gets propagated and continued because it's gotten away with.
/rant
Productivity boost by managed memory is overblown (Score:3, Informative)
I have experience writing for both platforms, and I prefer C++, despite VB's garbage collection. VB certainly makes it easier to do some things, but that's mainly because it offers an abstraction for all the Win32/COM red tape (dig through the MSDN to find which of the eleven or so Close...(), Delete...(), Free...() functions you need for this thing, and Release() all those COM pointers in every conceivable exit point).
C++ itself provides the means to relieve the programmer of much of this menial work, though. Microsoft doesn't take advantage of C++'s capabilities, but that's probably because C++ hadn't evolved enough when much of the Win32 code base was written.
In my recent work, which has all been C++ on Win32, I almost never have to manually delete anything. The Boost Smart Pointer Library [boost.org] has been tremendously useful, both for internal program logic and for taming the Win32 memory management nightmare. The reference-counting boost::shared_ptr template class and its relatives can be used to automatically free memory allocated with new when the last pointer is destroyed. What's more, you can specify a templatized deleter, so that a shared_ptr can manage COM objects, GDI objects, file handles, memory allocated in any of the dozen or so Windows APIs (GlobalAlloc(), VirtualAlloc(), HeapAlloc(), ThrashDiskAndThenCrashAlloc(), etc.)
It's possible to augment the API in such a way as to boost productivity without breaking backward compatibility. The .NET framework is a huge misstep, in my opinion, because it needlessly throws away a decade's worth of existing code. We were going to use it in a recent product, but we decided to go with MFC instead, because it couldn't link with our existing C++ code (well, it could, but huge marshalling bugs [codeproject.com] that have gone unfixed for years made it completely unusable).
Re:Backwards compatibility is possible. Forever (Score:3, Informative)
QEMU is more what I mean by emulator.
Want to run Windows 95 applications? Run them under Windows 95 in QEMU, or VmWare, or maybe VirtualPC.
Given the project's momentum, within 1 year QEMU will be as good as VmWare in OS compatibility. It will be Free in all possible ways.
Crossover Office version of WINE works very well. With the abandonment of Win32 the API will be anything but a moving target.
I'm just saying that you can have as much backward compatibility as you like pretty much for free. Just quarantine those old apps off into their little sandbox subsystem.
What you don't want to do is keep growing the old API till its horrifyingly crufty and creaking under its own weight as Win32 is.
Re:Repeating my comment on OSNews... (Score:1, Informative)
Re:Repeating my comment on OSNews... (Score:3, Informative)
Unix versioning is based on sym links. Given that it doesn't look like sym links came into play until somewhere around SVR 3.2 [cqu.edu.au] which seems to have come from 4.2BSD [iis.nsk.su] (I base the "come from" on a diagram on page 5 of The Design & Implementation of the 4.3BSD Unix OS [bookfinder.com]), and Linux didn't get them until
Now, I don't know what your definition of "since day 1" is but if it's 14 years (First Edition released in 1969, 4.2BSD released in 1983) then you're absolutely correct.
I'd also point you to the fact that Unix didn't have passwords on day one. They were added later. So much for security can't be added on, it's gotta be designed in. Not that you claimed that they did but it's an example of where Unix came from.
You see when Unix was designed it was a stripped down Multics. Multics was too big, too bulky, too much operating system with too many features [multicians.org]. But if you look at the features of Multics we all have them on our desktops (and Unix systems). So Unix barely had anything from day 1. You wouldn't want to use day 1 unix today. Oh, maybe you'd find some level of nostalgia in it - it'd be like whipping out a Pong console - but you wouldn't ever make it your desktop, let alone attempt to install multiple versions of software on it.
Re:Joel Might Be Wrong (Score:2, Informative)
Strictly speaking binary compatability is a machine issue. Will this set of machine instructions run on this particular machine. Note that in the SimCity bug there was no flaw in the program logic and no conflict with an API. Physical memory barfed on what the machine instructions told it to do. The only reason it didn't barf under DOS was because DOS wasn't asking the machine to do much of anything, whereas Windows does.
When you write a program as a single executable and compile it you then have two things, a binary which is an actual "thing" which interacts with the physical machine, and the logic of the program, which is a pure mathmatical abstraction. The binary and the machine don't know about that abstraction, they just know to put this here, move that there, increment that, etc.
An API is the next level of abstraction up. While there are exceptions it is software that talks to other software, not the machine, and while it may be implimented in binary form (which must, obviously, run on the machine) it is the logical structure of the communications between the software that is actually the API, not the binaries themselves. Just as your code logic is distinct from the compiled binary.
So you can type "make me a window" instead of the actual code to draw a window, and the code of the API sends a signal to the OS to run the window drawing code, which is in the OS itself, not compiled into your own code.
So API compatability means sending the right signals at the right time. The binary may run fine, and yet the program may fail due to API incompatibility.
You type "make me a window," which sends a "39 Hike!" to the OS, but it wants a "1" to draw a window. "39 Hike!" tells the OS to send all your personal data to Bill. Everything runs flawlessly, but the result is not what you intended. Binary compatible. API incompatible.
Are you talking about the difference between a new OS that supports older binaries with binary interfaces but which no longer provides an SDK to use the deprecated API? If so then I guess binary compatibility would be a subset of API compatibility - in C, binary compatibility would just mean that the linker would need to be able to do its thing, but API compatibility would mean that header files would also be needed.
. .
In the case of Linux and WINE I'm talking about an OS that is distinct from the Windows OS and which does not share its APIs. Things are simplified by the fact that they both share a hardware architechture, Intel, and that's why no real emulation is necessary. They both work to the same machine instruction set. For that matter they're both written in the same language, C (at least 98 is).
Now, if you want to run Windows programs under Linux you can do it the eBay way. Buy a license for Windows. Then you can run Windows itself under Linux in a virtual machine, the VMware way. This isn't actually emulation. It's running two OSs simultaneously. Ok, so it eats up system overhead like an emulator, so from the end user point of view it may amount to the same thing performance wise, but it still isn't actually emulation. It's identity. An Intel OS running on Intel hardware.
But let's you don't want to support that overhead, or say that you're running Linux in the first place because you don't want a Windows license ( crazy, I know, but just suppose), but you're compeled to run MS Office anyway, or you want to run a Windows only game. The essential thing standing between you and doing that is the Windows API.
You send the main executable to the cpu, which starts to run it, which sends out a signal to. .
Re:Why it has to die (Score:3, Informative)
Re:Security implications of kludged patches? (Score:1, Informative)
Finally let me point out that if you can choose the name of the executable on the OS you already almost undoubtably have full control as that user. So you own the system. Why are you trying to mess with the memory allocator when you can just rmdir
Hey now (Score:4, Informative)
It sounds like this guy is a kid playing around, or at least he was when he wrote the program.
Anyway, yield is actually only needed on OSs that do not have preemptive multithreading, which NT does. Yield wouldn't have solved his base problem anyway, just that he could have seen it didn't work when he set the thread to real-time, rather then seeing his machine lock up. (When you set a thread to real time, it's like running it on an OS without preemption, sort of).
In java, the threading behavior is determined by the underlying OS. If it has preemption, your java code works, if it doesn't, it doesn't. Back in the 1.1 days, Macs didn't have preemption (didn't get it until OS X(!)), and since java might want to run there, they you needed to yield.
Re:Win32 API will live forever (Score:5, Informative)
The problem is WINE is not "undocumented Win32 API calls". CrossOver Office can run MS Office just fine, and if there's any Windows application that would be using "undocumented Win32 API calls", it'd be Office. The fact is that there aren't any useful undocumented API functions. What's not documented is undocumented for a reason and is not used, even by Microsoft apps.
The problem with WINE is that the Win32 API is so mind-bogglingly huge because it covers just about everything you'd ever want to use an OS to do, that the WINE developers haven't been able to implement the whole thing. They go for the "most bang for the buck" APIs.
Maybe not a must, but there's a reason behind it (Score:3, Informative)
I wouldn't have the OS assume complete responsbility for switching, (especially in the case of time-sensitive tasks), as it can be important to make switching as deterministic as possible. With better thread handlers (like there is in linux) it can be less of a pain to manage, but that doesn't mean it shouldn't be be managed at all. It all comes back to understanding what you're doing.
And the very next sentence... (Score:3, Informative)
In other words, in order to get started, you need to understand data organization, basic logic, and basic layout. Anyone who has made a web page with DHTML has these prerequisites, and that's a lot of "anyones." Hell, using even basic DHTML will have taught you DOM.
The rest of the tech is covered in the tutorial itself. All of it is using the concept of Separation of Concerns. Where do you put the structure of your documents? XML (XUL). How do handle events and call object methods? JavaScript. How do you make it look pretty? CSS. How do you set labels and do internationalization? RDF. How do you make objects that can be called in any language without making explicit language bindings? XPCOM. Etc. Want to change the look without breaking the event handlers? Edit the CSS. That's SoC. In this case, people could call it MVC (Model/View/Controller) as well.
Re:Repeating my comment on OSNews... (Score:3, Informative)
2. It should enforce that the URLs accessed are issued from the same server/port as the script requesting it.
Socket is way too low level.''
IIRC, this is exactly how socket access works in Java applets (unless the applet is signed and given more permissions). There is no theoretical limitation that prevents you from making sockets work like you describe. This curbs the security argument.
In the past, people have suggested that I create a Java socket from JavaScript (I think it's called LiveConnect). However, this would still require Java, and when I tried it, it completely trashed Mozilla.
Re:Why it has to die (Score:3, Informative)
You can also add comments to individual enumerated values in an enum. Want to know what SYSTYPES.XCORSYS really means, or what its scalar value is? Put it in the docs.
Re:Increased Irrelevancy, however. (Score:1, Informative)
Or go work for IBM and see from the inside how quickly they're trying to make themselves irrelevant.
I think the GP was talking about IBM being irrelevant to the "desktop" market, to which I heartily agree. Yet as you point out, for backoffice applications IBM still has a very strong position. I personally LOVE DB2, and WebSphere is pleasant enough (but has some frightening unfinished corners inside the code -- do some random decompiles to see for yourself).
Let's leak some information about IBM's internal structure. (This isn't secret to IBM's longtime customers or competitors BTW.) IBM's *best* software comes out of Server Group, not Software Group. Server Group is *old* (mainframes), and has lots of down-to-earth managers that have been around the industry for a while. Software Group OTOH has essentially never created a cool application on its own: it buys something and then rebrands it (Lotus, Rational, WebSphere). Software Group's management culture is very different than Server Group's, slimy-er if you will, more like fresh MBA graduates and less like an experienced engineering group. DB2, while branded Software Group, was originally Server Group and follows that management style.
I just came out of a team (Tivoli) that had Band 8 developers ($95,000 salary range in the flyover states) that (I shit you not) were just starting to figure out how to use a ResourceBundle. They didn't know that in production environments you have to support other languages, or that WSAD and WebSphere are very different and require separate testing. None of them even knew how to install the code they were working on onto a Unix-y system, even though it was mandated that it had to run on five platforms. (Guess which platform they did their development on?) That level of inexperience -- akin to high-school hobbyist code -- shouldn't be compensated at that level, but Software Group management doesn't have the engineering emphasis in their culture to weed that crap out.
So yeah, I kind of support the GP's position: IBM is still going very strong on momentum, but the only serious "invention" I saw going on was basically out of the research and mainframe groups. IBM won't ever go away, but they aren't really leaders anymore.
Re:Repeating my comment on OSNews... (Score:2, Informative)
It really annoys me when MICROS~1 come up with some bullshit bandaid for creaky old Windows like "Side by side instalations of multiple versions of the same DLL", and all the Windows sycophants claim it's the second goddamn coming of Christ, when it's been working over in Unix land for decades. Argh.
Re:I don't agree--To fix Slashdot under Firefox... (Score:2, Informative)
fix Slashdot's horrible, invalid HTML output. It is has been discussed to death before but the Slashcode devels have not put any effort into fixing it.
Take a look at these [slashdot.org] articles [alistapart.com] for more info on how this can be fixed. [slashdot.org]
Note: That last link is about a Slashcode user who has already tackled some of the major issues with fixing Slash to output valid XHTML and CSS
Re:Why it has to die (Score:1, Informative)