DLL vs Static Library

[Captrick458]

We have a huge 'C' applications that we are porting from Unix. Because the application, for the time being, will continue to exist, be updated, etc. in Unix, we are trying to limit the differences to the absolute minimum.

We think that we have determined that the Screen I/O, and to a lessor degree the printer output need to be placed into classes, and therefore one or more DLLs are fairly easy to create, and save a lot of space. Is this a reasonable assumption?

What about the functions that we don't place into classes?
Should they stay in static libraries, and just be linked? There seems to be a mechanism to place these un-classed functions into DLL(s), although I am not certain that I understand all of the conventions.

Are there any libraries available in Unix that provide a Windows work-alike functionality for screen I/O?

Any advice that you can provide will be greatly appreciated.

Rick

 

[PerFnurt]

Why do you want to use DLLs instead of libs? Nothing prevents classes from being statically linked.

>placed into classes, and therefore one or more DLLs are fairly easy to create

Easier than just creating .libs? Don't think so.



/Per

_{www.perfnurt.se}

 

[Captrick458]

Perfnurt:

Thanks for taking the time to answer.

There seem to be two considerations driving this train: 1. It seems to be the "Windows" thing to do, and 2. It should ultimately save some space. The folks who use our application are heavily regulated by the US Govt, and depending on what types of work they do in their office, they may need to have some sort of update several times each year.

Our application has about 100 different programs, and much of the underlying library routines are common. We can make one extremely large piece of bloatware, in which case the whole library vs DLL issue becomes moot, or we can make a menu program that calls the other programs as necessary.

For instance, we have a function antoi(char *buff, int len) that plucks len characters from a buffer, and performs the traditional atoi(char *buff) function. I would guess that virtually every program in the package calls this function at least once. We can add it to a class, and easily place it in a DLL (we lose the ability to maintain the same code from Windows to Unix), we can have the object file linked into 100 different programs (use a lot of extra space, longer update times, etc.), or, if it is reasonable, we can create a non-class DLL that would contain this function. BTW, there are probably 500+ functions, some trivial, some very complex that fall into this category.

Thanks again, Rick

 

[xwb]

DLLs are as much a Windows thing as .so and .sl are Unix things. It is just a lot easier to develop code using shared libraries than using static libraries. Linking time is in the region of 10 to 20 seconds as opposed to minutes/hours when using static libraries. Also, the machine doesn't run out of space.

Can't see why if you place a class in a DLL you lose the ability to maintain the same code in Windows and Unix. Unix has shared libraries too: either .so or .sl.

You can keep to the DLL idea: it makes more sense.

Alternatively, you could have a configuration file to tell you which DLLs to load. Windows has a dynamic load feature, similar to dlopen in Unix.

 

[Captrick458]

xwb:

Thanks for your reply.

I am constrained by the fact that we have well over a million lines of 'C' code that is all contained in static libraries on the SCO Unix OS.

I have no problem with the idea of using DLLs, but, as yet, I have only figured out how to do this by creating classes. Needless to say, where ever I create classes, the original source must change, and the process of conversion and future updates become much more complicated.

So, assuming that we want to use a shared DLL, and assuming that I don't want to make a change to the original source where a function is called like
ii=antoi(cc,5);
how will I configure the shared DLL, and what sort of declarations are required to import/export the function?

Rick