RE: win32 update -- LINUX5250

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 that.

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
    additional dependencies.

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...