Hi !
I would like not to use windows.h, so I am defining all the type myself for portability sake. Unfortunately it seems I can't find the lib to link with to get default functions like :
POLINK: error: Unresolved external symbol '_ReadFile'.
POLINK: error: Unresolved external symbol '_CreateFile'.
POLINK: error: Unresolved external symbol '_GetLastError'.
POLINK: error: Unresolved external symbol '_CloseHandle'.
though I link with:
kernel32.lib advapi32.lib delayimp.lib shell32.lib
where are those functions ?
thx for your time !
PS I already checked in the .h files to see the pragma libs and stuff like this but couldn't find anything interesting
Those are all kernel32 functions. Look them up in the SDK...
The thing is you need to "undecorate" and expand them... For example, "_ReadFile" is actually:
BOOL ReadFile(HANDLE hFile,
LPVOID lpBuffer,
DWORD nNumberOfBytesToRead,
LPDWORD lpNumberOfBytesRead,
LPOVERLAPPED lpOverlapped );
I've often contemplated making a "most used" subset of windows, a single header and library with all the most common stuff in it.
The problem with that is that you run into things you don't count on, like DLLs with newer versions of standard functions, functions that move to new DLLs during updates, system functions that rely on other functions, interdependency between headers, etc.
Making a LIB to go with your header is a logistics nightmare.The minimum linker unit is 1 object file (i.e. 1 compiled C source code file) So, each function has to be in it's own separate object file. This also means each function or declaration has to be in a separate C file. If they aren't, you end up linking in a whole lot of "dead code" into your projects, bloating them rather significantly. Keeping track of the thousands of windows functions is going to be a seriously difficult and error prone process. Maintaining it could eat up all your time and it's likely your productivity as a programmer will suffer.
If you choose not to make a LIB, you have to direct your header file (using #pragma lib or #pragma comment(lib : <library>)) to hook up to all of the existing libraries, bringing about almost no advantage in compilation time or efficiencey.
Finally there's the matter of documentation. The SDKs currently available all list the header and libraries needed for each function. Creating your own subset (or superset) renders that part of the documentation useless.
As much as I dislike the tangled up mess Windows headers are, it realy is best to go with the ones supplied ... a lesson I learned the hard way!
