design an application that runs without a DLL in the same directory?

Your question is very confusing....

If the application in question uses any of the exported functions from the DLL, then the DLL is REQUIRED and you must have it available.

If this is your application, then remove any dependencies on the DLL and rebuild it.  Then the DLL will not be needed.

If your problem is something else, I dunno, you've not provided enough details.

By the way, this is off topic here in the C++ topic area.

From the title of your question, it seems you want to put the DLL somewhere else on your computer, besides in the folder where your program runs.

The DLL must be in the PATH or the local folder.  (go to an MS-DOS command prompt and type SET PATH to see what your path is.)

When your program runs, it looks first in your local folder for needed DLLs, then it looks in the PATH folders.  If needed DLLs are not found in any of these locations, then the program will fail.

A lot of people put DLLs in the c:\WINNT\system32\ folder.  This is ok, but you can lose track of your custom DLLs in there because there are so many other system DLLs in there.

If you're logged in as an admin, you can add a folder to the PATH environment setting (My Computer/Properties/Advanced) so that all your custom DLLs will be in one location.

Hope this helps...

To run an application that uses a DLL which is not in the same directory any of the following methods can be used:

1. Place the DLL in question in some system directory where windows look for DLLs.

2. Place the DLL in question in some directory on the path or include the directory where the DLL is in your path.

3. IF you can load the DLL file explicitely yourself - as opposed to implicitely by windows at startup. You have far more options available. You can even select at run time which DLL to run and what to do if it wasn't found etc, where to find it and so on. This just tells you to find the DLL somewhere - wherever you want - and call LoadLibrary to load the DLL into your process memory space. When LoadLibrary is done you get a handle to the module and using that handle you can search for functions in that DLL:

int __stdcall (* some_func)(int x, const char * str);
HMODULE DLL_Handle = LoadLibrary("c:\\whatever\\dir\\SomeDLL.DLL");

some_func = (int __stdcall (*)(int,const char*))GetProcAddr(DLL_Handle,"SomeFunction");

Now you can call SomeFunction from that DLL.

int res = some_func(13,"some string");

In this last method you have full control for everything.

Alf

I agree with jhance, you need to give more details.

Name of dll, Framework/compiler etc.

ok, i better repeat the ques.

i see that lots of programs run without DLL(or not without it, but it's invisible to the user)

i am using Borlad C++, when i'm writing a 32-bit program,
it must run together with a DLL(name: cw3230.dll)<-- this must be in the same directory with program.

what i want is to know how to write program without having to put it in the same dir or to include it in the main program. invisible to users

CS3230.DLL is Borland C++'s C++ RUN TIME LIBRARY.

Either us IT or WRITE YOUR OWN RTL!

HLLau,

I am not sure what that cw3230.dll does but your best bet is probably to arrange it so that that dll is stored in some directory and your program access it from that directory.

The most clean way to do that is to put the dll in the same directory as the .exe. The reason for this is that it is easiest for the user, if he wants to remove the program he just delete the directory and gone is both the program and the DLL. Placing the DLL in another directory means that the user must search for this DLL and then he finds it and he possibly do not know it is together with your program and he might end up deleting it without deleting your program etc etc. Then when you run your program it won't find the DLL and chaos arise.

So, the program require the DLL to be in the same dir as the exe. This is the best way to solve the problem. Why would want to do it differently?

If you don't want the user to have the DLL in his local directory, don't install the program in that local directory, install it in some other directory and place the DLL in that same directory.

As I wrote before you can use LoadLibrary("cw3230.dll") and that function can be given full path to the DLL so it can be placed anywhere, you can also handle that the file wasn't found at that place and for example try LoadLibrary() with a different path to search for the file in several places and also be able to terminate gracefully if the DLL couldn't be found. So you CAN have full control if you want.

On the other hand, why would you? Why is it so bad that the DLL have to be in the same dir as the EXE?

Placing the DLL in any other directory runs the risk that the user may some day see this DLL residing all by itself in a directory and not recognizing that the DLL is needed by your application he deletes it. Then when your application starts up you complain that you can't find the DLL and the user may have forgot that he deleted that DLL or it is a different user who at one time deleted it and the poor user who wants to run your program is stuck.

Why make things so difficult for your users? Why can't you just make things easy for them? PLace a DLL where it belongs: If the DLL is used by one application, place it together with that application. If the DLL is used by several applications place it in some common place and give the directory name something like "FooAppShared" so that the user knows that this is a DLL which is shared among all the Foo applications and won't delete it unless he has deleted all those applications.

Alf

jhance,

HMmm.....

so he wants to get rid of the run time library?

well.....then he really is in for a hard time.

HLLau,

What do you have against the library?

You could define to load the static library (.lib) instead. It is possible that you cannot do that because you don't have the big enough version of the compiler to do it. Both Borland and Microsoft operate with several versions of their compiler platforms - a "student" version which has several limitations and one of them - I think - is that you cannot use a statically linked C library. In this case you have to buy a bigger compiler if you want to get rid of that DLL.

Secondly, it is just right and proper that a DLL is installed in the same dir as the exe that uses it. In this way when you upgrade to next version they both get replaced and you don't end up with the chaos that an old version of the program attempt to access a newer version of the DLL (which might work) or that a newer version of the program attempt to access an older version of the DLL (which most probably will not work).

HLLau's "problem" strikes me very much as a "no-problem", it isn't any problem at all, just leave it as it is and it works fine. A problem is when something doesn't work. In this case you want to make a change so that it does work. Placing the DLL with the EXE strikes me as a solution that does work and doesn't need to be changed.

Alf

Oh - also, on the Packages tab in Project|Options, remove the tick from "Build with runtime packages" and rebuild.
;-)

thanx alot!