Could old timers comment on that? Undoing things is not my favourite
activity but in this case I can't say it's giving that much of "profit"
for the project. I think I'll take a look at the archives to learn a bit
the motivations behind this.
Mike Madore is the founder of this project and still has probably done the
most research and work for the project. He wanted to add GLIB because it
had all sorts of functions for working with linked lists, dynamic, arrays,
etc... if he used GLIB, he wouldn't have to write his own routines, debug
them, and try to get them to run flawlessly on 20 different OSes.
IIRC, at the time, he had just been hired (based on his work on this
emulator) to write a 5250 server for Linux/Unix systems. I believe he was
also working on a 3270 server at the same time. A lot of his code for
these servers is still found in lib5250 (although it hasn't been used or
developed in a long time.)
This may not be obvious to a Windows developer. For the most part,
Windows is the same from system to system. There are some changes when
you upgrade to the latest version, but they're relatively minor.
In Unix, however, there are many, many different operating systems that
are all similar but not quite the same. GLIB gives you portability... it
provides routines that have been tested throughly throughout the Unix
world, plus on Mac and Windows as well... and there's definitely value in
Sure, we COULD write our own routines and test them everywhere, but why
reinvent the wheel?
Right now, the issue is that we're reinventing the wheel ANYWAY... because
we're supporting both the 0.16 and 0.17 branches with and without GLIB
support. We're using very little from GLIB, since only a little bit of
the functionality was actually changed -- yeah, there's g_free and
g_malloc, because those were really easy to chnage, so someone went
through and did it.
There are some cases where we've got some of the list stuff in use,
though. I know that conf.c uses them... not sure where else, but I bet
there are some other places.
The problems I have with GLIB are as follows:
a) I'm not intimately familiar with it. It's easier for me to use the
standard C library, because that's what I'm familiar with.
b) It complicates the building & deployment of TN5250 because of the
c) I don't know that we're using enough of it to really reap the
advantages of it.
So, I could go either way on this issue. There were some people who felt
very strongly in favor of it at the time that we implemented it, but I
wasn't one of them.
Carey may have more to say...
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.