I'm currently using Python 3.7 and Pycharm for my work. Recently I got a code that is done at Python2.7

You shouldn't use Python 3.7 to run code that was written for Python 2.x, unless you can port that code to Python 3, or you know that it works fine. There are some caveats, and it depends on what the functionality of that code is. In some cases it might be very time consuming to convert it. 2to3 might help here.

So, depending on your use case, you may want to keep a legacy version of Python 2.7 around on your system to run that particular code, but note that Python 2.x will not get any (security) updates anymore, so you're better off using Python 3 from now on.

Try running the code in Python 3.7 and see if it works.

and it includes a library named 'ctypes.'

This is included by default in Python, so you don't need to install anything. Assuming you have the correct Python 2.7 interpreter and all other required packages, the code should just run fine as-is.

If the person who wrote the code was doing a good job, he or she should have left a README and/or a requirements.txt file or something similar that would specify which other packages or libraries are needed to run it.

In the conda documentation for using shared libraries, different approaches are described depending on the operating system. On Linux, shared libraries in conda packages typically have a modified rpath (using patchelf). For example:

>>> import importlib.util
>>> importlib.util.find_spec("_ctypes").origin
'<$CONDA_PREFIX>/lib/python3.10/lib-dynload/_ctypes.cpython-310-x86_64-linux-gnu.so'

CONDA_PREFIX/lib/python3.10/lib-dynload/
$ ldd _ctypes.cpython-310-x86_64-linux-gnu.so
        linux-vdso.so.1 =>  (0x00007ffe565c0000)
        libffi.so.8 => not found
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fadad8de000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fadad6c2000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fadad2f4000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fadadae2000)

Since libffi is not found, in python an import ctypes will give the error: ImportError: libffi.so.8: cannot open shared object file: No such file or directory. Now, libffi is installed as a conda package in this case, so

$ patchelf --set-rpath '$ORIGIN/../..' _ctypes.cpython-310-x86_64-linux-gnu.so

will fix that problem. Now if I create a shared library test.c:

#include <stdio.h>

void special()
{
    printf("special\n");
}

and compile it i.e. cc -shared -fPIC -o special.so test.c, Then special.so will exist in this directory but ctypes won't be able to find it. Now, if I do cp special.so $CONDA_PREFIX/lib, then in Python loading it works fine:

>>> import ctypes
>>> ctypes.cdll.LoadLibrary("special.so")
<CDLL 'special.so', handle f86430 at 0x7ff44691e5f0>
>>> libsp = ctypes.CDLL("special.so")
>>> x = libsp.special()
special

On windows, to answer your specific question, the documentation states:

This path [(install prefix)\\Library\\bin] is added to os.environ["PATH"] for all Python processes, so that DLLs can be located, regardless of the value of the system's PATH environment variable. This is the difference between the "raw" and the conda installation.

See also: How does conda work internally?

Installing libffi-dev and re-installing python3.7 fixed the problem for me.

to cleanly build py 3.7 libffi-dev is required or else later stuff will fail

If using RHEL/Fedora:

sudo yum install libffi-devel

or

sudo dnf install libffi-devel

If using Debian/Ubuntu:

sudo apt-get install libffi-dev