As to this msvcrt.dll i heard that this is not system (at least win xp i am using) dll - this must be installed - You sure mingw links against that, where is the import.lib for that?

Yes, I am sure this is the system CRT. I do not install anything anywhere, all my MinGW programs just run like this. (OK, that's only half of the truth, usually OpenGL and OpenCL need to be installed on the computer, but that's unrelated to this question as it's something that users usually do without knowing by installing the display driver anyway -- not my job to do that).

The only exception where you have to "install" something is a compiler build that links against libstdc++ dynamically, but these builds are rare -- they existed historically because libstdc++ contained helper libs to enable throwing exceptions among DLLs and executables and for making TLS work reliably (without leaking), both of these work without helper libs in modern builds. And in those cases, you would just have bundled the DLL in the zip file within the executable's directory. That somewhat leads the "shared" part of shared library to absurdum, but it reliably avoids version conflicts, and you need not installer that does obscure stuff with the Windows directory (which is something a lot of people despise).

well i just want to throw away whole includes (it is about c standard library headers and also windows.h) and write declarations with my own hand only

Again: Not including headers will not prevent linking to the system libraries. Not including headers will only have the effect of the compiler not knowing the signatures of the functions as well as the definitions of many types which are defined for portability (such as off_t, size_t, or time_t).

You can of course declare the functions yourself, but it will not gain you anything except for ten or so milliseconds of compile time. The only header that has a significant compile time impact (and notable side effects) is <windows.h> if you haven't defined NOMINMAX and WIN32_LEAN_AND_MEAN.

The chance of screwing things up in a more or less nasty manner by writing your own declarations is significant, however.

also i would need to know exactly where are all the binaries mingw is linking my binaries against?

Several locations within the compiler's directory (including the bin, lib (for import libs), and libexec dirs, possibly different among different compiler builds), plus any extra paths that you specify on the commandline, and finally %windir%/system32

http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx explains the different msvcrt libraries. It is all of the c runtime library (with exceptions spelled out in that link). That's what the crt stands for: C RunTime.

But i never managed to understand is "c run time" == "c std lib"

or is "c run time" only implementation of some part of "c std lib"

(and there is some part of "c std lib" contained in the other binaries than "c run time"?

You can of course declare the functions yourself, but it will not gain you anything except for ten or so milliseconds of compile time. The only header that has a significant compile time impact (and notable side effects) is <windows.h> if you haven't defined NOMINMAX and WIN32_LEAN_AND_MEAN.

The chance of screwing things up in a more or less nasty manner by writing your own declarations is significant, however.

well i am just trying to get rid of windows.h but it is hard because window functions are heavy macroprocessed and i dont know its raw

form

for example i got some call to SetWindowText(hwnd, text);

i was trying to delete windows.h and declare

int __stdcall SetWindowText(void*, char*);

C standard library is defined by the C language spec and is fully included in a C runtime library. What else is also included in a C runtime library varies. glibc obviously includes POSIX stuff and GNU-specific stuff in addition to the standard library. msvcrt obviously includes Windows stuff and whatever else Microsoft felt like throwing in there.

for example i got some call to SetWindowText(hwnd, text);

i was trying to delete windows.h and declare

int __stdcall SetWindowText(void*, char*);

but gotlinker error

undefined reference to `SetWindowText(void*, char*)@8'

how i should write it? where to find a raw declatarion for this, raw declaration i could type here?

The symbol SetWindowText is itself a macro than expands to either SetWindowTextA or SetWindowTextW. Most functions that take strings have A and W variants for char * and wchar_t * strings, respectively.

for example i got some call to SetWindowText(hwnd, text);

i was trying to delete windows.h and declare

int __stdcall SetWindowText(void*, char*);

but gotlinker error

undefined reference to `SetWindowText(void*, char*)@8'

how i should write it? where to find a raw declatarion for this, raw declaration i could type here?

The symbol SetWindowText is itself a macro than expands to either SetWindowTextA or SetWindowTextW. Most functions that take strings have A and W variants for char * and wchar_t * strings, respectively.

Ye i was conscius of this vaguelly (bus as usual was trying blindly for a moment)

now i deleted the windows.h and used

The point of the Windows API is that you don't know these implementation details and you are not supposed to know them. You make a unicode build, and it will just work. You do a normal build, and it will work anyway.

You do a 64bit build, and it will still work.

The way you've declared the function (using void* and char*), your code will break if at any time e.g. the assumption typedef void* HANDLE; isn't true any more. Microsoft may change the API (it's unlikely but possible, and it has happened), and the same types may not work the same between 32 and 64 bits.

By using <windows.h> you account for all this. It will work, no matter what. By doing your own stuff, you are out alone in the dark.

Same is true for all the standard headers. If you use off_t in your code as defined in your system headers, your programs will compile successfully and run without errors, regardless whether off_t means unsigned int, or uint64_t or something else. You just don't care.

C standard library is defined by the C language spec and is fully included in a C runtime library. What else is also included in a C runtime library varies. glibc obviously includes POSIX stuff and GNU-specific stuff in addition to the standard library. msvcrt obviously includes Windows stuff and whatever else Microsoft felt like throwing in there.

Alright much tnx, (youre cleared the vagueness tah doomed me last half a year) this was a surprise to me, i suspected that cruntime is only a part of c std lib, not c std lib + yet more

The point of the Windows API is that you don't know these implementation details and you are not supposed to know them. You make a unicode build, and it will just work. You do a normal build, and it will work anyway.

You do a 64bit build, and it will still work.

The way you've declared the function (using void* and char*), your code will break if at any time e.g. the assumption typedef void* HANDLE; isn't true any more. Microsoft may change the API (it's unlikely but possible, and it has happened), and the same types may not work the same between 32 and 64 bits.

By using <windows.h> you account for all this. It will work, no matter what. By doing your own stuff, you are out alone in the dark.

Same is true for all the standard headers. If you use off_t in your code as defined in your system headers, your programs will compile successfully and run without errors, regardless whether off_t means unsigned int, or uint64_t or something else. You just don't care.

I agree, you right. Windows.h is some program ;/ that let do some

few types of builds. but here im doing some hackish thing like disassembly (many people are doing that yet more strange things ;/

so i decided to tinker with this for a while,..

second think, i think if doing right it is not so dangerous and wrong,

microsoft will not change the binary interface i am linking to, so if i

link properly it will work

ONE thing i need though are the raw-physical sugnatures of this 20 or something winapi calls I use (like the one above) this is the signatures

after unfolding al macros - i do not know from where to get this and do not risk the mistakes in types (becouse if i do mistake i will have a runtime corruption) :/ i would like to avoid this