I've got some experience with this issue, having had to make different versions of DLL from the same vender coexist, and perhaps some of you Linux whippersnappers will learn something. Windows DLLs can be used in a upward compatible manner; it's just that it's hard for most people to understand the issues of DLL compatibility.
When we're talking about DLL hell, the first thing to keep in mind is that usually we are talking about incompatible changes in behavior or interface in libraries that are *meant* to be shared. Once a software designer decides to expose an interface, he becomes hostage to his installed base. Effectively, as others have pointed out, the name of the DLL becomes its interface identifier. So by convention you should encode the lowest compatible revision number of the interface in the DLL name. You can keep the name the same as long as you are binary-compatible, not matter how much the implementation changes. For example, MFC didn't change much from version 4.2, so when Microsoft came out with MFC 5.0, the names of the DLLs didn't change from MFC42*.DLL because they were still binary compatible.
If you need to share some state even between different versions of the same facility (like a list of file handles for different versions of libc), you are going to have to factor the internal state into yet another interface -- and that one that better be evolvable for a very long time.
The sad fact of the matter is that maintaining binary compatibility is hard, because there are technical details to master, and because of the discipline required to keep all potential clients working without have to rebuild and relink. You can't change the names or signatures of functions, you can't change the layouts or sizes of structures or classes, and older bugs that clients rely on as features will become features that have to be supported. If it's a C++ interface, you can't add virtual functions to base classes, although you can add new nonvirtual class functions. Of course, you can add new functions. It is also possible to "version" structures for expandibility, but this is tricky.
By the way, while static linking is a way around some DLL problems, one of the cases in which it can't work is when a DLL implements in interface to functionality that requires shared state in the same address space. You can have multiple clients of a DLL in the same address space when both and application and its extension libraries refer to that DLL. This happens a lot with ActiveX controls on Windows (and in-process COM servers in general), and I suspect that this also happens in Apache on Unix as well.
Both Windows XP and Mac OS X have mechanisms for allow shared libraries to be hived off so that you can have private version for yourself, but I don't know much about how they work.
Note that shared Java classes are much easier to deal with, but isn't like there are no interface changes have binary compatibility implications.
The other way around this problem is to expose the interfaces(s) in a language-neutral object model that supports interface evolvability, such as [XP]COM or CORBA. Unfortunately, it's not always easy to use these kinds of interfaces, and most of these kinds of systems don't offer implementation inheritance (with the notable exception of.NET, which is Windows-only currently and also requires language extensions), which is a handy feature of a C++ class exposed in a DLL.
If the Linux distros are so god at picking up on hw, why do I have to give XF86config monitor timings, and know whether my video card has a timinhg chip (or whatever the hell it is that it asks...).
At least the Darwin/Mac OS X version of XFree86 doesn't require configuration -- it just works !
The potential Photoshop-killer (on MacOS X anyway) would use Cocoa and Quartz compositing, and let QuickTime handle the file formats, with zero attention paid to cross-platform issues (with the exception of data file compatibility, which is really a standards and application-level issue anyway). If such a beast could read and write layered Photoshop files (I know QuickTime can handle many PSD files already) and use plug-ins, and was scriptable, it might get some attention. The point is to leverage a bunch of really neat stuff that you get for free on OS X that Adobe has to carry around on all their applications, like an image processing engine and a Postscript-level structured graphics engine.
As neat as a GIMP port to OS X is, I really think that most Mac users are going to be wierded out by the X-based interface. I think I'll stick with GraphicConverter, thank you.
I met Brewster Kahle, the founder of Alexa, a few years ago and he was good-naturedly ribbing me about working for the Evil Empire of IBM (actually Lotus, which was acquired). Well, now the shoe is on the other foot, Mr. Kahle.
Actually, many companies DO care if you care if you play ping-pong on Tuesday nights.... Or maybe you'd be interested in donating some dough to a local youth ping-pong team so it can realize its dream of playing in China. Get the drift?
True, this slippery slope will lead us to slavery and genocide.
If Linux has any role to play on the desktop, it will have to be in turnkey or narrowly defined contexts first, because its competition is just too far ahead in the general-purpose desktop game. Hackers can keep hacking their skinned window managers 'till the cows come home, but that playground isn't going to sell Linux to most users.
When Mozilla was getting off the ground, my sincere hope was that, a powerful Mozilla combined with web-based applications would provide stiff competition to Windows for uses in business for computers users who mostly consume information, fill in forms, and use email. Web-based groupware and perhaps a few applets could fill in the gaps where most people use Office and Outlook.
The fact that was still no single consistent toolkit or desktop API that all applications used would be sidestepped by narrowing down the universe to the web browser and some Java applications. One could imagine a Mozilla+Linux distribution that could be slim, easily cloneable, and easy to administer, and maintain.
I really thought that such a strategy would play well to the strengths of IBM or other big machine vendors -- polish up a toolkit and Mozilla on the client side, and then start encouraging the use of web application servers on the server side. (Various vendors could then attack the problem of being data- and protocol- compatible with MS products like Office and Exchange.) Most companies have addressed Linux as a server, as far as I can tell. That left Eazel and maybe some of the distro companies to solve the harder, more general, desktop problem. And, in my opinion, trying to fix that kind of stuff requires concentrated programmer effort and management that the Open Source model is just very weak at attacking.
What I'm really surprised at is the persistence of the (Slashdot-)widespread misconception that porting a GUI app to Mac OS X from Windows or Mac OS Classic is somehow equivalent to porting it to Unix. No, no, no ! I've worked on a lot of nontrivial GUI applications, and I can tell you that the code that talks to something like a POSIX or Unix layer is usually not the interesting part of the project -- it's treated like a commodity, or plumbing, and most Windows/Mac C/C++ implementations have supplied this to various degrees of fidelity for a long time. The interesting bits of OS X are precisely the hard ones: a coherent GUI API and environment. Unless there appears a Carbon for Linux, or OpenStep makes great strides, don't count on Mac OS software going the Linux way.
Im all in favor of the frequent updates, but one place where they can cause problems is when apple updates some of it's core 'features' which are actualy open source software.
I think the way to fix is to come up with a standard version identifier structure for Darwin modules, and, by extension, *BSD and Unix executables in general. This would also help tools like the BSD package system that really have nothing to rely on but the date or name of the file or some entry in the package system to figure out if it's up to date.
When I upgraded to Toast 5 (which works just fine, by the way, maybe you Windows users should switch to a Mac), I noticed the switch to freedb.org as well.
I think it's pretty clear that unless FreeDB actually copied the data from CDDB, mistakes and all, that Gracenote has no grounds for the data.
Or maybe Gracenote is filing suit because the wire interface for FreeDB is exactly the same as CDDB, so that all Roxio had to do was change a constant somewhere. CDDB was also trying to foist a new advanced DCOM-only interface to replace the http-based one, but nobody seems to use it. Anyway, I am pretty sure than emulating an interface or protocol is not going be enough for Gracenote to claim damages. If mere emulation is enough to let Gracenote win, it will have a chilling effect on the ability for anybody to independently provide the same service as somebody else. And that's not good for the growth and use of web services.
If the use of cddbp is in fact a problem, I would advise the FreeDB people to implement the interface to their service in terms of SOAP instead.
RNext for the Mac ? That's kind of a surprise. The MacOS client has been deteriorating for about four years now.
Q: Does the Linux Notes server come with the Exchange emulation/Outlook client compatiblity features ? I read about this a while ago. If so, that would mean you could replace an Exchange server running Windows with a Linux box running Domino, and still keep Outlook for Windows.
Before everybody thinks they are so adept at pointing out NCR's mistakes, it might be the case that Apple, Casio, and the Windows CE groups have licensed those patents already. While I still think that patents are way off-base, in a court of law the fact that other companies didn't fight Palm might help NCR.
The one missing company in all of this is Sony. Did NCR not name them because they're so big, or because Sony licensed those patents ?
Somebody mod'ed this to "troll" ? Oh come now. Alex is absolutely right, it's a cool hack but useful for only a tiny segment of Windows users. Linux users might find it a more interesting toy in conjunction with an X server, but the rest of the world isn't going to bother with a piece of software that plays to Linux weaknesses (instead of its strengths).
IMHO, what GLibC needs to be is a skeleton library with a well-defined API but no innards. The innards would be in seperate, self-contained libraries, elsewhere on the system
Gee, that sounds like what Microsoft does for its Win32 C library DLLs. Not dissing you, I'm just amused at how the Linux community ends up reinventing Windows time and time again.
One of the problems with using a static C library is that it has global state, and sometimes various shared libraries written in C will need to cooperate -- in those cases, the shared state has to be managed by shared code. If the code is not shared at some level, the state won't be shared.
Isn't this just OpenDoc on steroids -- as the shell and only way of creating data ? Everything becomes contextual, a document is just a soup of connected objects, and so on. Not that it's a bad idea, I just this that getting the UI to follow along with the user's freeform intentions is really difficult, most people don't really seem to care about this ability anyway. I watched hundreds of developer days being spent on really implementing ActiveX and OLE right at Lotus, but the fact is that most peope I see using Windows applications that are good OLE contains, which could approach this concept (albeit crudely) don't really take advantage of the power of these features.
I agree. His comments are kind of puzzling, especially given his heritage. Maybe it's because his experience with UI implementation was done at a time when the line the OS and the GUI implementation had to be pretty thin -- modularity really did cost memory and speed.
But in a modern OS, the "desktop" or whatever interface of choice you'd like to implement is really just another application, with perhaps two added features:
a contract for the desktop application to fulfill (it must be able to open documents, launch programs, make links, and so on) so that it can be reimplemented or replaced
a class library or framework rich enough to enable desktop/activity/data nugget/component communication, whether it be SOM Workplace Shell classes, COM-based Windows shell, desktop and OLE interfaces, CDE specs, or the set of MacOS desktop interfaces that have been built up over the years. Note that at this level, windowing systems are really just a boring implementation detail. Really, for the most part, what we would strictly call on "OS" is not the interesting thing here.
Although there are some ways an OS could make details like object storage more like whatever the metaphor of the day is. For example, MacOS supports file types and creators, which really frees users from having to respect naming conventions. The Palm OS uses little databases and doesn't even have a Finder feature. The web extends Unix-style paths across the Internet (although I would argue that we've wimped out on real locators for resources that are spec'ed by content identity, not just location).
But I digress. As for MacOS X, what's really interesting is Cocoa, and that's already a powerful but unobtrusive framework. Too bad Mr. Raskin didn't address the relation of such frameworks to UI philisophy, where I think I might have actually had a point.
In some ways, the problem can be reduced to hacking executable formats and making them coexist. (Of course, it helps if the executable format actually was designed to help do this.) For example, it is possible for a.EXE file on a PC to support DOS, Win16, and Win32 all at the same time.
NeXTStep (now MacOS X) has "obese" binaries that can support lots of different architectures. However, I don't know if the packages that NeXTStep uses support the execution of non-trivial code at install time. Also, I don't know if obese binaries were parseable by Mach-O based implementations and those where OpenStep was just a library (like the Win32 version).
Probably the most portable "execution" formats that can be understood across platforms are HTML, Javascript, and Java. You could distribute an installer that was just a web page, used Javascript to sniff the platform, then executed the installer for the right platform. (This would be considered a privileged operation and the user might be asked to confirm it, and the applet or script snippet that was implementing this would have to have its code signed.) Check out InstallAnywhere, which uses some of these techniques (at least the last time I checked, anyway).
That's a sane way to do it. Doing things this way now has a buzzword associated with it -- "refactoring." I welcome the trend to actually study how to maintain programs instead of just writing new ones, because, almost by definition, you will spend a lot more time maintaining a useful program than writing a new one.
Yes, it is MacOS X Server -- I think the MacCentral interview confirms this. And, of course, there are cooling problems to deal with because convection isn't there to help.
Yes, yes, AOL/Netscape has to make money, but does Navigator have to whore itself out so obviously ? (Not unlike RealPlayer.) At least IE, during normal usage, is just a browser.
There was an NeXT-savvy (as opposed to merely friendly) version of GNUEmacs, I believe. It should pretty easy to take that code and make it work with Cocoa, avoiding the need for an X server to do the GUI integration.
Until then, most folks will just run it in Terminal.app.
Didn't NeXTStep get released as version 0.9 even after the hardware was selling ? It looked quite stable to me, but apparently it wasn't up the NeXT's idea of what a 1.0 release should have.
I think it's safe to say that the "blue box", perhaps some elements of Carbon, and the AltiVec code in certain libraries are PPC-specific. (Even then the AltiVec functionality is accessible as things that look like C function calls, so it could always be faked for other processors.)
But the Core Foundation (which also runs on MacOS 9), Darwin, and the Cocoa framework remain extremely portable. For example, Apple just released patches for WebObjects that run on NT, Solaris, and HP-UX.
Slashdot Mirror
When we're talking about DLL hell, the first thing to keep in mind is that usually we are talking about incompatible changes in behavior or interface in libraries that are *meant* to be shared. Once a software designer decides to expose an interface, he becomes hostage to his installed base. Effectively, as others have pointed out, the name of the DLL becomes its interface identifier. So by convention you should encode the lowest compatible revision number of the interface in the DLL name. You can keep the name the same as long as you are binary-compatible, not matter how much the implementation changes. For example, MFC didn't change much from version 4.2, so when Microsoft came out with MFC 5.0, the names of the DLLs didn't change from MFC42*.DLL because they were still binary compatible.
If you need to share some state even between different versions of the same facility (like a list of file handles for different versions of libc), you are going to have to factor the internal state into yet another interface -- and that one that better be evolvable for a very long time.
The sad fact of the matter is that maintaining binary compatibility is hard, because there are technical details to master, and because of the discipline required to keep all potential clients working without have to rebuild and relink. You can't change the names or signatures of functions, you can't change the layouts or sizes of structures or classes, and older bugs that clients rely on as features will become features that have to be supported. If it's a C++ interface, you can't add virtual functions to base classes, although you can add new nonvirtual class functions. Of course, you can add new functions. It is also possible to "version" structures for expandibility, but this is tricky.
By the way, while static linking is a way around some DLL problems, one of the cases in which it can't work is when a DLL implements in interface to functionality that requires shared state in the same address space. You can have multiple clients of a DLL in the same address space when both and application and its extension libraries refer to that DLL. This happens a lot with ActiveX controls on Windows (and in-process COM servers in general), and I suspect that this also happens in Apache on Unix as well.
Both Windows XP and Mac OS X have mechanisms for allow shared libraries to be hived off so that you can have private version for yourself, but I don't know much about how they work.
Note that shared Java classes are much easier to deal with, but isn't like there are no interface changes have binary compatibility implications.
The other way around this problem is to expose the interfaces(s) in a language-neutral object model that supports interface evolvability, such as [XP]COM or CORBA. Unfortunately, it's not always easy to use these kinds of interfaces, and most of these kinds of systems don't offer implementation inheritance (with the notable exception of .NET, which is Windows-only currently and also requires language extensions), which is a handy feature of a C++ class exposed in a DLL.
As neat as a GIMP port to OS X is, I really think that most Mac users are going to be wierded out by the X-based interface. I think I'll stick with GraphicConverter, thank you.
I met Brewster Kahle, the founder of Alexa, a few years ago and he was good-naturedly ribbing me about working for the Evil Empire of IBM (actually Lotus, which was acquired). Well, now the shoe is on the other foot, Mr. Kahle.
When Mozilla was getting off the ground, my sincere hope was that, a powerful Mozilla combined with web-based applications would provide stiff competition to Windows for uses in business for computers users who mostly consume information, fill in forms, and use email. Web-based groupware and perhaps a few applets could fill in the gaps where most people use Office and Outlook.
The fact that was still no single consistent toolkit or desktop API that all applications used would be sidestepped by narrowing down the universe to the web browser and some Java applications. One could imagine a Mozilla+Linux distribution that could be slim, easily cloneable, and easy to administer, and maintain.
I really thought that such a strategy would play well to the strengths of IBM or other big machine vendors -- polish up a toolkit and Mozilla on the client side, and then start encouraging the use of web application servers on the server side. (Various vendors could then attack the problem of being data- and protocol- compatible with MS products like Office and Exchange.) Most companies have addressed Linux as a server, as far as I can tell. That left Eazel and maybe some of the distro companies to solve the harder, more general, desktop problem. And, in my opinion, trying to fix that kind of stuff requires concentrated programmer effort and management that the Open Source model is just very weak at attacking.
- MacOS X is rapidly accumulating many ports of the open source/GNU/Linus userland world for non-GUI apps.
- The Mac software vendors are porting to Carbon, not Qt or GTK. If they're looking at anything else, it's Cocoa.
- As submitted earlier, Qt has been announced for OS X. Can GTK be far behind ?
What I'm really surprised at is the persistence of the (Slashdot-)widespread misconception that porting a GUI app to Mac OS X from Windows or Mac OS Classic is somehow equivalent to porting it to Unix. No, no, no ! I've worked on a lot of nontrivial GUI applications, and I can tell you that the code that talks to something like a POSIX or Unix layer is usually not the interesting part of the project -- it's treated like a commodity, or plumbing, and most Windows/Mac C/C++ implementations have supplied this to various degrees of fidelity for a long time. The interesting bits of OS X are precisely the hard ones: a coherent GUI API and environment. Unless there appears a Carbon for Linux, or OpenStep makes great strides, don't count on Mac OS software going the Linux way.I think the way to fix is to come up with a standard version identifier structure for Darwin modules, and, by extension, *BSD and Unix executables in general. This would also help tools like the BSD package system that really have nothing to rely on but the date or name of the file or some entry in the package system to figure out if it's up to date.
I think it's pretty clear that unless FreeDB actually copied the data from CDDB, mistakes and all, that Gracenote has no grounds for the data.
Or maybe Gracenote is filing suit because the wire interface for FreeDB is exactly the same as CDDB, so that all Roxio had to do was change a constant somewhere. CDDB was also trying to foist a new advanced DCOM-only interface to replace the http-based one, but nobody seems to use it. Anyway, I am pretty sure than emulating an interface or protocol is not going be enough for Gracenote to claim damages. If mere emulation is enough to let Gracenote win, it will have a chilling effect on the ability for anybody to independently provide the same service as somebody else. And that's not good for the growth and use of web services.
If the use of cddbp is in fact a problem, I would advise the FreeDB people to implement the interface to their service in terms of SOAP instead.
Q: Does the Linux Notes server come with the Exchange emulation/Outlook client compatiblity features ? I read about this a while ago. If so, that would mean you could replace an Exchange server running Windows with a Linux box running Domino, and still keep Outlook for Windows.
The one missing company in all of this is Sony. Did NCR not name them because they're so big, or because Sony licensed those patents ?
Somebody mod'ed this to "troll" ? Oh come now. Alex is absolutely right, it's a cool hack but useful for only a tiny segment of Windows users. Linux users might find it a more interesting toy in conjunction with an X server, but the rest of the world isn't going to bother with a piece of software that plays to Linux weaknesses (instead of its strengths).
Does anybody remember HP New Wave ?
Gee, that sounds like what Microsoft does for its Win32 C library DLLs. Not dissing you, I'm just amused at how the Linux community ends up reinventing Windows time and time again.
One of the problems with using a static C library is that it has global state, and sometimes various shared libraries written in C will need to cooperate -- in those cases, the shared state has to be managed by shared code. If the code is not shared at some level, the state won't be shared.
There's nothing in Linux to support architecture portability ? No hardware abstraction layer or the like ?
Isn't this just OpenDoc on steroids -- as the shell and only way of creating data ? Everything becomes contextual, a document is just a soup of connected objects, and so on. Not that it's a bad idea, I just this that getting the UI to follow along with the user's freeform intentions is really difficult, most people don't really seem to care about this ability anyway. I watched hundreds of developer days being spent on really implementing ActiveX and OLE right at Lotus, but the fact is that most peope I see using Windows applications that are good OLE contains, which could approach this concept (albeit crudely) don't really take advantage of the power of these features.
But in a modern OS, the "desktop" or whatever interface of choice you'd like to implement is really just another application, with perhaps two added features:
-
a contract for the desktop application to fulfill (it must be able to open documents, launch programs, make links, and so on) so that it can be reimplemented or replaced
- a class library or framework rich enough to enable desktop/activity/data nugget/component communication, whether it be SOM Workplace Shell classes, COM-based Windows shell, desktop and OLE interfaces, CDE specs, or the set of MacOS desktop interfaces that have been built up over the years. Note that at this level, windowing systems are really just a boring implementation detail. Really, for the most part, what we would strictly call on "OS" is not the interesting thing here.
Although there are some ways an OS could make details like object storage more like whatever the metaphor of the day is. For example, MacOS supports file types and creators, which really frees users from having to respect naming conventions. The Palm OS uses little databases and doesn't even have a Finder feature. The web extends Unix-style paths across the Internet (although I would argue that we've wimped out on real locators for resources that are spec'ed by content identity, not just location).But I digress. As for MacOS X, what's really interesting is Cocoa, and that's already a powerful but unobtrusive framework. Too bad Mr. Raskin didn't address the relation of such frameworks to UI philisophy, where I think I might have actually had a point.
NeXTStep (now MacOS X) has "obese" binaries that can support lots of different architectures. However, I don't know if the packages that NeXTStep uses support the execution of non-trivial code at install time. Also, I don't know if obese binaries were parseable by Mach-O based implementations and those where OpenStep was just a library (like the Win32 version).
Probably the most portable "execution" formats that can be understood across platforms are HTML, Javascript, and Java. You could distribute an installer that was just a web page, used Javascript to sniff the platform, then executed the installer for the right platform. (This would be considered a privileged operation and the user might be asked to confirm it, and the applet or script snippet that was implementing this would have to have its code signed.) Check out InstallAnywhere, which uses some of these techniques (at least the last time I checked, anyway).
That's a sane way to do it. Doing things this way now has a buzzword associated with it -- "refactoring." I welcome the trend to actually study how to maintain programs instead of just writing new ones, because, almost by definition, you will spend a lot more time maintaining a useful program than writing a new one.
Yes, it is MacOS X Server -- I think the MacCentral interview confirms this. And, of course, there are cooling problems to deal with because convection isn't there to help.
Yes, yes, AOL/Netscape has to make money, but does Navigator have to whore itself out so obviously ? (Not unlike RealPlayer.) At least IE, during normal usage, is just a browser.
Until then, most folks will just run it in Terminal.app.
Didn't NeXTStep get released as version 0.9 even after the hardware was selling ? It looked quite stable to me, but apparently it wasn't up the NeXT's idea of what a 1.0 release should have.
But the Core Foundation (which also runs on MacOS 9), Darwin, and the Cocoa framework remain extremely portable. For example, Apple just released patches for WebObjects that run on NT, Solaris, and HP-UX.
A Mac user berating Linux software for a lack of keyboard shortcuts. Hee-hee ! I mean, it's funny, and yet I agree completely !