Date: Tue, 20 Jan 2004 00:07:02 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [Ux2bs_Archive] No. 260 ************************************************** Monday 19 January 2004 Number 260 ************************************************** Subjects for today 1 Re: Any new UX2BS testers? : Stefan.Neis at t-online.de 2 Re: Any new UX2BS testers? : John Bijnens" **= Email 1 ==========================** Date: Sun, 18 Jan 2004 15:23:57 +0100 From: Stefan.Neis at t-online.de Subject: Re: Any new UX2BS testers? Hi, > Now we're talking about different things. If there is anything like > a "binary release number" which means that the versions _are_ in fact > not binary compatible That's what the numbers appended after the .so-Suffix by libtool are supposed to be, and that's what I supposed we were talking about... Otherwise, I don't see how Knut would hope to fit e.g. gettext-0.10.40 into his numbering scheme... > and that they can't be made compatible by just > playing around with the module definition file and that they can't > be made compatible by a tiny patch to the source code that will be > accepted by the maintainer, That relatively hard to verify. Do you really assume that Linux people break compatibility just for fun if a tiny patch could avoid it? I sure hope even they won't do that. > then and only then we have no choice other > than to use a new dll name. But I refuse to deal with zillions of new > dll names just because the new version _could_ possibly be incompatible > to the old one (if nobody has ever checked this). How are you able to check it? If the library maintainer says "it's incompatible", are you going to find/download/test all OS/2 programs and then declare "it's compatible on OS/2, the maintainer is stupid, let's keep to same name"? Or are you even going to do this based on e.g. 30% of existing OS/2 programs (e.g. everything included in UnixOS2)? Personally, I'd rather not waste my time with that kind of tests. Rather, one could add a little program replacing old DLL name by new DLL name (see Innotek's font engine for Mozilla...) and if somebody really cares, he can test his own programs and throw away the old DLL once he's sure to no longer need it.. > In the case of the famous intl.dll all existing versions (with the > only exception of the binary release of 0.10.40 because it's missing > a symbol) can be made binary compatible when dealing with the > module definition file. These are the 0.10.x and 0.11.x versions > (I haven't looked closely at 0.12.x but I think it's similar). I cant find any suitable *.so files on the systems I have access to to check the numbering, but I do hope that the numbering reflects this fact... > > Now, if we ommit that second digit and additionally ommit the first > > digit as long as it's zero, we still have a mostly reasonable numbering > > system (with the drawback I just described) and won't normally see any > > version numbers. > > This is basically, what we IMHO should do. Well, maybe - I'm not quite convinced, though... It can get quite frustrating to tell/be told all the time "Oh, you do have whatever.DLL already? Well, never mind, just get the updated version" from one person and "Oh, you do have the updated version? Well, get the original version that I based my work on" from the other. > > Guess who is recompiling all old programs included e.g. in > > Solaris/IRIX/AIX on such occasions? Right, it's SUN/SGI/IBM. > > Exactly. And the programs for UnixOS/2 should be compiled by the UnixOS/2 > people (at least, in theory). But we don't want the libraries to be used for UnixOS/2 exclusively and be unusable for user's own programming, do we? Even if UnixOS/2 people are recompiling all programs as needed, that doesn't automatically imply that Innotek or whoever is going to distribute recompiled versions of their software, just because it doesn't work with the new DLL any more - assuming UnixOS/2's DLL actually do get used by other people, of course... > > Also, those companies all take backwards compatibility very seriously. > > If you take a program compiled on e.g. Solaris 2.5, you can still > > run it on Solaris 10, without having to install tons of libraries. > > Try the same with e.g. SuSE-7.2 vs. SuSE-9.0... > > This is no reason for us to use the worst example from the real world. ;-) > IMHO, if we use the Linux philosophy for compatibility then we'll end > up in chaos since we have not the capabilities to release a new distro > every few months and to recompile all old programs. What I try to explain all the time - and seemingly without success - is this: It's not up to us to choose the philosophy of compatibility. We have to cope with whatever the library maintainer chooses. If we can't, then users are in trouble. And if you look at where the ported libraries could possibly come from, AIX, Solaris, HP-UX etc. and their closed source system libraries that are slowly evolving the way we like it are pretty irrelevant. > > Those libraries, that we are typically porting just are changing > > much faster in incompatible ways than any system library of a > > commercial (non-Windows) system. > > Then distribute only stable releases as dlls and everything als > static library or as beta release. What's a "stable release" of e.g. libpng? Should png.dll be the old version, with the new (incompatible) version being distributed as static lib only, or vice versa? And if vice versa, how would you get rid of existing DLLs of the old version? > Except that you may have to install the same dlls (but with different version) > over and over and over again. So what? Even if I have five copies of every DLL, that'll "easily" fit on my hard disk (well, after some cleaning). But that's still better than having to set the magic flag to not ignore path's for DLLs, reboot, install the five _different_ copies of the "same" dlls in five different directories and wrap all your applications with startup-scripts setting up the needed LIBPATH. BTW, thanks for making me think about it, I guess I'm now able to finally upgrade GNUmake-3.75 to something newer. ;-) > You just have to write your own dll with export by ordinals (because it's > faster), and as soon as somebody wants to use your program with the official > dll (export by name): *BOOM* Is this actually true? I.e. is that a property of the DLL or is it a property of the import library? To me, after all the explanations I heard/read so far, it seemed to be the latter. However, if you create an import library for import by ordinal _matching_ the official DLL and link your program with it, all will work fine with the current official dll, but might break with the next one when a new symbol was added that changes the numbering... One more reason to go with the two numbers in the DLL name - it would give those insisting on ordinals give a chance to use them even on "official" DLLs. Regards, Stefan _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 2 ==========================** Date: Sun, 18 Jan 2004 15:51:01 +0100 (CET) From: "John Bijnens" Subject: Re: Any new UX2BS testers? On Sun, 18 Jan 2004 15:23:57 +0100, Stefan.Neis at t-online.de wrote: > Hi, > >> Now we're talking about different things. If there is anything like >> a "binary release number" which means that the versions _are_ in fact >> not binary compatible > >That's what the numbers appended after the .so-Suffix by libtool are >supposed to be, and that's what I supposed we were talking about... >Otherwise, I don't see how Knut would hope to fit e.g. gettext-0.10.40 >into his numbering scheme... > .... and so on and so on. I must admit that I'm lost. I can't follow it anymore. I want to help port UNIX apps to OS/2. So if I can help anywhere please let me know. For now I just stay with the simple things as Analog, Xstat, ... Unix/Linux libraries, multiprocess stuff (forks, ...), and graphical interfaces make me usually go nuts. Best regards, John Bijnens -- CAD/CAM Resp. KHLim - Dep. IWT, Cel Kunststoffen Website work : http://celkunststoffen.khlim.be Portal ProE : http://celkunststoffen.khlim.be/cad/ IRC : irc://irc.celkunststoffen.khlim.be/#ecs Nickname : Orac ICQ : 346927648 You might also want to try another alternative operating system eComStation : http://www.ecomstation.com http://www.ecomstation.biz _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs