NO

Author Topic: no windows.h  (Read 4437 times)

drakoh

  • Guest
no windows.h
« on: May 17, 2005, 03:16:27 AM »
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

Anonymous

  • Guest
Re: no windows.h
« Reply #1 on: May 17, 2005, 02:29:32 PM »
Quote from: "drakoh"
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:
Code: [Select]

 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!

drakoh

  • Guest
no windows.h
« Reply #2 on: May 18, 2005, 01:57:40 PM »
Ok, I was half ok with the idea of removing the windows specific code, to please my linux friends, but I guess they will have to work a bit on their side so I can at least have something working on windows !

thx for your long and clear answer.

have a great day !

Anonymous

  • Guest
no windows.h
« Reply #3 on: May 18, 2005, 02:31:43 PM »
Quote from: "drakoh"
Ok, I was half ok with the idea of removing the windows specific code, to please my linux friends, but I guess they will have to work a bit on their side so I can at least have something working on windows !


Edit:  Isn't there a windows library for Linux (called WINE?)?

This is, I think, one of the real problems with "cross platform" developement.  Languages like Free Pascal have so compromised themselves in the zeal to get it compiling on as many platforms as possible that they've actually sacrificed the power of the language to do it.

I chose Pelles C in part because it is platform specific.  I wanted a language that was as optimized for Windows as possible.  95% of all desktop computers run Windows, about 4% run Linux, the rest are a mix of experimental OSs and BeOS.  I see no point in ditching the power of the language in order to please about 4% of my potential audience.

(Beside which, nobody has ever even asked me to write for anything except Windows!)

Quote

thx for your long and clear answer.


You're welcome.  

I hope I didn't discourage you from experimenting and playing around with new ideas...

jtegan

  • Guest
Thanks for this
« Reply #4 on: June 03, 2005, 10:45:02 PM »
I am not a newb to c and for the most part to win programming but I am new to DLL development.  I have been pulling out the few "Rogaine" induced hairs the past 2 days trying to figure out why my winldap dll would not compile...This answered the bigger part of my questions. THANKS
 

Give an idiot a skill saw and watch in hysterics his lack of skill!


buzz buzz =D>