-2

How can i force my linker to link against the Windows.h statically, so all the functions of the Windows library gets inside my executable ?

I want API calls like VirtualAllocEx, OpenProcess, and other API calls like Writing to another process's memory and such and CreateRemoteThread (basically all the communication API calls and memory allocation ones) to be inside my executable, so i don't have to use Windows.h for it, so basically my IAT would not contain these functions, what is the best way to achieve this?

Mery Ted
  • 129
  • 10
  • Thanks for the link but how can i force it to link windows.h statically? @πάντα ῥεῖ – Mery Ted Aug 18 '19 at 14:28
  • I think that what you *really* want to ask is "do I need to ship the compilers runtime libraries with my application?" and the answer to that will, in almost all cases, be "Yes". You need to ship the Visual Studio redistributable run-time alongside any application compiled with the Visual Studio compiler. – Jesper Juhl Aug 18 '19 at 14:30
  • @JesperJuhl I just want to know how can i force visual studio to statically link windows.h instead of dynamically? so all its functions would be inside my .exe – Mery Ted Aug 18 '19 at 14:31
  • 1
    "how can i force it to link windows.h statically?" - That makes no sense. "Windows.h" is a *header* file, *not* a library. It may expose things from a library (or many *different* libraries), but it is not itself a library. – Jesper Juhl Aug 18 '19 at 14:32
  • 1
    @MeryTed Is there something wrong with your google? I've added another link. – πάντα ῥεῖ Aug 18 '19 at 14:33
  • @JesperJuhl yes I know, what i meant was how can i statically link the windows library, considering the duplicate question suggest it is linked dynamically by default – Mery Ted Aug 18 '19 at 14:33
  • There's no such thing as "the windows library". The visual studio runtime is split into a multitude of libraries. – Jesper Juhl Aug 18 '19 at 14:35
  • @MeryTed Compile the program passing /MT instead of /MD to the compiler. It will instruct the compiler to statically link the CRT and other standard libs. This is usually not the correct thing to do. – andresantacruz Aug 18 '19 at 14:40
  • @dedecos so this will put all the windows APIs inside my executable correct? if so, would i face problems considering some syscalls might be different in different windows versions? – Mery Ted Aug 18 '19 at 14:41
  • The question isn't a duplicate IMO. The OP is asking if it is possible to **link statically** windows libraries. The answer should be **no you can't**. System libraries have special characteristic and can't be run in same space of user program memory. – Frankie_C Aug 18 '19 at 14:41
  • @Frankie_C I think OP is referring to CRT functions. – andresantacruz Aug 18 '19 at 14:43
  • @MeryTed give us 3 examples of "windows API" functions you want to ship inside your binary. – andresantacruz Aug 18 '19 at 14:44
  • 1
    @dedecos Even in that case we could explain that the crt libraries are compiler dependent because contains the basic functions necessary to run compiler library functions (fopen, get, printf, etc.). Some compilers, as MSVC, allow to choose how to link them, statically or dynamically, with a specific line switch, so he must refer to compiler documentation. More difficult is to explain that, due to technical reasons, the use of the 2 make difference. I.e. choosing static link don't allow to share file pointers between DLL's in running in the same process space. – Frankie_C Aug 18 '19 at 14:52
  • @dedecos like VirtualAllocEx, OpenProcess, and other API calls like Writing to another process's memory and such and CreateRemoteThread (basically all the communication API calls and memory allocation ones) – Mery Ted Aug 18 '19 at 14:54
  • 1
    @πάνταῥεῖ Again **you can't statically link system libraries** because each DLL use shared sections to keep track of interprocess arbitration and allow the kernel to interact with user code without interference between processes. That just in plain words, real things are much more complicate. – Frankie_C Aug 18 '19 at 14:57
  • @dedecos i tried setting it to MT, it did made my binary larger, but the function that i used (MessageBox in this example) was still in my IAT, but i thought IAT is only used for dynamic linking, so why the function i used is inside IAT (its the only function from user32.dll which is present in my IAT) it also got rid of all the other dlls, only kernel32 and user32 are present, some other dlls which was present before are gone for some reason – Mery Ted Aug 18 '19 at 15:14
  • @dedecos also my .text section got a lot bigger, so i assume these are the codes inside windows library that were added? – Mery Ted Aug 18 '19 at 15:17
  • You don't link a header file such as `Windows.h`. A header file is **source code**. You compile it into an object file. You link libraries and object files together to make an executable file - either an executable you can run, or another library. That linking process can result in a static or dynamically-linked executable. This is probably relevant: https://stackoverflow.com/questions/37398/how-do-i-make-a-fully-statically-linked-exe-with-visual-studio-express-2005 There are lots of results if you do a search for "static link MSVC" on your favorite search engine... – Andrew Henle Aug 18 '19 at 15:41
  • What you are asking for is possible, but it is difficult. Since that library is proprietary and part of the Windows operating system, you will need to get a job at Microsoft on the Windows team, and then extract those routines into your own custom static library and then link to that. – Eljay Aug 18 '19 at 16:18

3 Answers3

1

A I said in comments under MS Windows OS the dynamic library have some characteristics that don't pertain to static library code. Let try to explain in very plain way:

First of all a DLL is loaded independently from current executable, and directly from the OS module loading function, as a separate object which code memory is mapped in the current process memory, but retained to be mapped in a different process.

During the loading the loader creates different memory areas that can be unique for a single process or shared between processes or private to DLL internal functions.

The shared areas permits to create mutex's,semaphores and any data necessary to the kernel to arbitrate the multitasking environment and resources sharing.

On the reverse a static library is loaded only in the current process, the code segment lays together with the user program code segment, and the data segment, in same way, is added to the current executable data space.

For these reasons, and much more, you can't statically link any system library function to your executable.


A simple experiment on static and dynamic linking using the CRT libraries.

Create a main program in where you open a file:

#include <stdio.h>
extern void DllReadRoutine(FILE *);
int main(int argc, char *argv[])
{
    FILE *fp = fopen("Myfile.txt", "r");
    //Diagnostic omitted to keep it simple
    DllReadRoutine(fp);    //Pass the file pointer to the external DLL function
    fclose(fp);
    return 0;
}

Now create DLL (we omit DLL entry):

#include <stdio.h>
void DllReadRoutine(FILE *fp);
int main(int argc, char *argv[])
{
    int c;
    while ((c=fgetc(pFile)) != EOF)
    {
        putchar(c);
    }
}

Then compile the two linking the CRT statically the first time (use /MT on MSVC) and dynamically the second (use /MD on MSVC).

In the first case the DLL function will fail because the static linking to CRT creates local open files table that is incompatible with the table local to the main executable. The result is a crash.

In the second case the internal CRT data, as the open files table, is created in a shared area where both, executable and DLL, access. In this case the code will work smoothly.

Frankie_C
  • 4,764
  • 1
  • 13
  • 30
  • But when i used the runtime library option of /MT instead of /MD, it did kinda work because the size of my binary went from 9kb to 77, and the text section got a lot bigger so i assume these are the API calls from windows that were added to my .text section correct? but i don't know why the IAT table still contains the function that i used (MessageBox from user32.dll) and it contains this only, thought it would get removed from IAT since i linked it statically – Mery Ted Aug 18 '19 at 15:21
  • @MeryTed No. Using /MT or /MD you instruct the linker to respectively link statically or dynamically **only the the compiler CRT (Compiler Run Time libraries)**. Not the system libraries. Check the sample code I provided above. – Frankie_C Aug 18 '19 at 15:38
1

You can't.

These things are part of the operating system.

The operating system has permission to do things your own code does not.

In addition, the implementation with your operating system is correct for that version of the operating system.

This is a good thing. You do not want to statically link the OS's API implementation.

The header file Windows.h only provides declarations that allow you to call them.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
0

I think you may be misunderstanding the process of static linking. The Windows.h header file contains declarations for various types of activities, for example function calls. Note these are declarations not binary implementation of the functions themselves. Take a look at the ShellExecuteA documentation. Scroll to the end of the document and you will see a Requirements section that looks like this:

Requirements

Minimum supported client Windows XP [desktop apps only] 
Minimum supported server Windows 2000 Server [desktop apps only] 
Target Platform Windows Header shellapi.h 
Library Shell32.lib 
DLL Shell32.dll (version 3.51 or later)

Windows.h includes shellapi.h (Target Platform Windows Header). Shellapi.h contains the declaration for ShellExecuteA (function we looked up in the docs). This section also tells you the library containing a binary implementation of the function, Shell32.lib in this case. If you know the function declaration and the location of it's binary implementation you can link it. The linker just matches the (function) name to the (implementation) name available at link time. On Windows you should be able to statically link using the lib file, or dynamically link using the dll file. If you statically link you include the binary implementation from the lib file into your executable. If MS fixes a but in the function you use, you don't get that fix unless you recompile. If you dynamically link (link to a dll) your executable will be smaller and more inclusive of future MS changes.

Dweeberly
  • 4,668
  • 2
  • 22
  • 41