Date: Wed, 21 Jan 2004 00:07:04 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [Ux2bs_Archive] No. 261 ************************************************** Tuesday 20 January 2004 Number 261 ************************************************** Subjects for today 1 Re: Any new UX2BS testers? : Andreas Buening 2 Re: Any new UX2BS testers? : John Poltorak **= Email 1 ==========================** Date: Mon, 19 Jan 2004 22:32:43 +0100 From: Andreas Buening Subject: Re: Any new UX2BS testers? Stefan.Neis at t-online.de wrote: > > 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. Why do people increase the version number? Because there might be new features, support for three new graphics formats, maybe the last release was too long ago, so the maintainer thinks it might be a good idea to indicate the changes by a new version number, even if the old interface or even if the old code hasn't changed. All I want to say is, don't make a new dll just because of some new numbers. First, have a (short!) look at the code, at the NEWS file, at the content of the static library (e.g., by using emxexp) whether there were some _real_ changes. E.g., gettext is now reaching version 0.14. The announcement says 0.14 will provide support for C# (new dll GNU.gettext.dll), a new feature for Farsi (Persian) has been added, and the language code for Norwegian has changed in 2003. Great. I doubt that this justifies any significant code change for intl.dll compared to 0.13. If we used Knut's scheme we now had intl0A.dll, intl0B.dll, intl0C.dll, and intl0D.dll, and the last versions had just 2 or 3 programs using it before they were replaced by the next version. > > 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, I've never heard that any maintainer claimed "it's incompatible". Instead there is "Here is a new version, it has the following new features or bug fixes. Have fun!" He may have never thought about binary compatibility. But he should know that changing the interface or the behaviour of a library will break existing binaries as well as existing source code (except he provides some preprocessor macros to simulate the old behaviour). Therefore I claim that real binary changes a less, much less often than changes in the 2nd version number. > > 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... With module definition files we can provide binary compatibility for OS/2 in some cases even if it's not binary compatible for any Unix system. > 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. Again: Having a new library version does not automatically mean that it's not binary compatible. Maybe you're talking about different libraries than me. ;-) > > 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. Of course, the import library is the reason why the program expects a different (ordinal) structure of the dll. So don't use ordinals! Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 2 ==========================** Date: Mon, 19 Jan 2004 22:50:05 +0000 From: John Poltorak Subject: Re: Any new UX2BS testers? On Mon, Jan 19, 2004 at 10:32:43PM +0100, Andreas Buening wrote: > Stefan.Neis at t-online.de wrote: > > E.g., gettext is now reaching version 0.14. The announcement says 0.14 > will provide support for C# (new dll GNU.gettext.dll), a new feature for > Farsi (Persian) has been added, and the language code for Norwegian has > changed in 2003. Great. I doubt that this justifies any significant code > change for intl.dll compared to 0.13. I'm still struggling to create an INTL library which will work when building an old version of GREP! UX2BS is at something of an impasse until I get this fixed. As far as I am concerned I see GETTEXT as an essential requirement for UnixOS/2 and would prefer INTL.DLL to always be based on the most recently available GETTEXT. Of course, it's inclusion in any UnixOS/2 distro would require some integration testing with every app which used INTL.DLL > Bye, > Andreas -- John _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs