Pelles C forum
Pelles C => Feature requests => Topic started by: Anonymous on January 25, 2005, 03:13:28 AM
-
Ok, I'm just thinking out loud here, but...
Since there is an obvious correlation between headers and libraries in your C distribution, wouldn't it make sense to put #pragma lib "..." lines in each of your headers?
eg. in the shellapi.h header add #pragma lib "shell32.lib" so that the correct library is automatically added to the linker's list whenever we include a header. It would completely eliminate the linker errors related to us forgetting to manually add the libraries (or not being sure which libraries to add) to the linker settings...
-
I don't have the entire Windows #include file tree at the top of my head, but it can't be an exact 1:1 mapping between include files and libraries (100+ libraries and 300+ include files). Part of the process of producing import libraries (*.lib) is automated, so maybe I can do something in that area... I will look at it.
Not sure how useful it is, but the linker will accept a *.lib file specification (using wildcards) - maybe this feature can be used? I havn't actually tried it (from a project file)...
Pelle
-
I don't have the entire Windows #include file tree at the top of my head, but it can't be an exact 1:1 mapping between include files and libraries (100+ libraries and 300+ include files). Part of the process of producing import libraries (*.lib) is automated, so maybe I can do something in that area... I will look at it.
As I said I was just thinking out loud... almost wishing.
It sounds like I might be setting you a massive task, and I rather suspect you have a full day already.
Tell you what... don't do anything on it for a few days... let me look at a couple of ideas and see if I can't solve this one for you, without massive changes to your headers or code.
-
It sounds like I might be setting you a massive task, and I rather suspect you have a full day already.
For the moment, yes. But it's a good idea - it would simplify things.
Tell you what... don't do anything on it for a few days... let me look at a couple of ideas and see if I can't solve this one for you, without massive changes to your headers or code.
OK - thanks.
Pelle
-
First Aid:
You could make include file for example libs.h
and insert known libs to there.
// libs.h
#ifdef _SHELLAPI_H
#pragma lib "shell32.lib"
#endif
-
First Aid:
You could make include file for example libs.h
and insert known libs to there.
// libs.h
#ifdef _SHELLAPI_H
#pragma lib "shell32.lib"
#endif
Yep. I was, in fact, just thinking about that. It needs to be a little more complex than the example and it would have to be the last on the list but it would work.
Something like...
#ifdef _SHELLAPI_H_
#ifndef SHELl32_LIB
#define SHELL32_LIB
#pragma lib "shell32.lib"
#end if
#end if
... repeated for each header. The extra would be necessary to prevent duplicating the pragmas since there is often more than one header for each library and sometimes more than one library for a header.
The ideal would be to include the middle part (between the blank lines above) into the actual headers themselves... I'd be happy to do the work and contribute it to the project... From there, Pelle would just have to keep it up to date. What I need, though, is some kind of crossreference to work from... What goes with what?
I wonder if there's a list someplace???
-
The ideal would be to include the middle part (between the blank lines above) into the actual headers themselves... I'd be happy to do the work and contribute it to the project... From there, Pelle would just have to keep it up to date. What I need, though, is some kind of crossreference to work from... What goes with what?
I wonder if there's a list someplace???
This is the big question. I'm not aware of any such list, but maybe there is one. With this info, I can easily write a small script to insert the necessary lines into the #include files.
Pelle
-
I wonder if there's a list someplace???
This is the big question. I'm not aware of any such list, but maybe there is one. With this info, I can easily write a small script to insert the necessary lines into the #include files.
Pelle
Fear Not! :) I'm half way there!
1) I took your sysdefs.tag file and parsed it down to a csv list of functions in each header. As : <function>,<header>
2) I used polib to list all the stuff in the libraries, giving me a list of functions in each library. (300 + files worth... Thank goodness for batch files!)
3) Next I just have to tap up a little code to transform the library list files into a csv list of functions by library. As : <function>,<library>
4) Then all I have to do is tap up one last bit of code to sort and correlate the function names producing a list of libraries by header. Take out the duplicate lines and the final output would be a text file consiting of:
<header name>,<library name>
<header name>,<library name>
<header name>,<library name>
It shouldn't take long... From there it would be a matter of sequentially opening each header, locating the header's #define _HEADER_H line and tucking in the required number of #pragma blocks, as in my earlier message.
(There will be multiple lines for some headers, if they call in more than one library, so your script will have to account for that. It's also possible some headers won't be referenced at all, if they don't match up to a library.)
Will this do as a source list for your script?
-
Will this do as a source list for your script?
Sure - this list (in pretty much any format) is exactly what I need!
Pelle
-
Will this do as a source list for your script?
Sure - this list (in pretty much any format) is exactly what I need!
Pelle
Excellent...
I just finished transforming all the library listings...
One more editor nacro to correlate names and we're home free!
You should have it sometime later today...
-
Will this do as a source list for your script?
Sure - this list (in pretty much any format) is exactly what I need!
Pelle
:) Here ya go!
I think I should say how I built this list...
As I explained before I used polib to give me a list of all the function calls in the libraries. I then took your sysdef.tg file apart to get a list of stuff in the headers.
This means 2 things... first, the list is only as complete as the matchup beteen your data base names and the library names. This might be further degraded if I didn't "undecorate" some of the OBJ libs correctly. I'm pretty sure I got the DDL imports right, though...
I had my little quicky code include a match in the list if:
A) the library and header names were the same
B) a function name was listed in both places.
To play it safe I had my code output a list of library functions that didn't get crossreferenced. (H2LRept.txt) I'm sure a lot of them are deliberate, avoiding conflicts, internal functions and such. But it struck me that maybe some of them weren't so I thought I'd give you the information and let you decide what to do with it.
The main crossreference is in HDR2LIB.CSV which has 241 matchups. Given that not all headers reference libraries and a lot of the headers are simply included in other headers I'd say I got a good 90% of them for you.
Let me know how it goes!
-
Thank you for the files! I will report back when I have something to report...
Pelle
-
Thank you for the files! I will report back when I have something to report...
Pelle
My pleasure, Pelle.
(and "reporting back" is hardly necessary :) )
=======================================
Afterthought...
The more I look at this the more I'm amazed that windows works as well as it does. Those headers are a tangled up mess of crosslinks and repeated declarations with little or no relationship to the actual code they describe. Given that Windows is a C code project, I'm given to wonder if the gang at MS really knows what they're doing at all...
Really... if you're going to make this DLL caled Shell32 why would you name it's header Shelapi? Or, for that matter, if you're going to create kernel32 why wouldn't you make a Kernel32 header? That one's spread out across about a half dozen headers...
:roll: or maybe I was just spoiled by the cleanliness of Pascal units???
-
The more I look at this the more I'm amazed that windows works as well as it does. Those headers are a tangled up mess of crosslinks and repeated declarations with little or no relationship to the actual code they describe. Given that Windows is a C code project, I'm given to wonder if the gang at MS really knows what they're doing at all...
Looking at the different Windows #include files, even newer ones released about the same time, it seems there must have been a lot of different people/groups involved (some are very clean, while others are a complete mess). I read somewhere recently that much time is spent today just trying to coordinate all the changes. The normal case, when software projects gets too big, I guess. Maybe we should be "happy" it's working at all...
Windows isn't just an operating system anymore, it's grown into somthing much bigger. Not always a good thing...
Pelle
-
Looking at the different Windows #include files, even newer ones released about the same time, it seems there must have been a lot of different people/groups involved (some are very clean, while others are a complete mess). I read somewhere recently that much time is spent today just trying to coordinate all the changes. The normal case, when software projects gets too big, I guess. Maybe we should be "happy" it's working at all...
Windows isn't just an operating system anymore, it's grown into somthing much bigger. Not always a good thing...
Ain't that the truth. I would rather they stuck to the basics... get the multitasker and peripheral IO working to a science... leave the fancy stuff to us application programmer types. I'm no linux fan by any stretch, but I do have to admire the concept of providing a kernel and letting users and programmers set the direction for the rest.
The more I climb into windows programming (I'd still be a DOS programmer if I had a choice :wink: ) the more I find myself wondering what the h_ll they were thinking... Lets hope the 64bit system isn't just an add-on... it's been a long time since anything truly new came from MS and they're about due. They've got lots of experience with the concept and the market now... cleaning up the mess and getting their act togeter is just about the only thing they haven't done.
Interestingly, they *could* release a set of cleaned up headers, all done by the same team, without changing the libraries at all. Why this hasn't been done, we may never know.
Oh well... it is what it is. The best we can do is try to make it as foolproof as possible :)
-
Lets hope the 64bit system isn't just an add-on... it's been a long time since anything truly new came from MS and they're about due. They've got lots of experience with the concept and the market now... cleaning up the mess and getting their act togeter is just about the only thing they haven't done.
I have been around long enough to remember the move from 16-bit to 32-bit Windows. Now that was useful - getting rid of the segmented memory architecture (having to lock a memory block to access it, then unlocking it so that Windows could move it around until the next time...), getting protected memory (so a crashing application didn't bring down the entire system), getting cool stuff like memory mapped files, and so on.
For compatibility reasons (easier to re-compile), a lot of "baggage" was kept around. This is why we still have stuff like LocalAlloc, GlobalAlloc, for example. Existing code will always be a factor - the costs of rewriting working applications, just because the operating system changes, is too high.
I havn't actually looked at 64-bit Windows, but I suspect there will be some new stuff, but mostly the things we already know and love/hate (take you pick).
Pelle
-
I have been around long enough to remember the move from 16-bit to 32-bit Windows. Now that was useful - getting rid of the segmented memory architecture (having to lock a memory block to access it, then unlocking it so that Windows could move it around until the next time...), getting protected memory (so a crashing application didn't bring down the entire system), getting cool stuff like memory mapped files, and so on.
I was lucky, went straight from DOS to Win32. But I still liked running win 3.1 the best. It was fast, small and very easy to setup. Win95 was a big improvement for programmers but a lot of security and stability issues surfaced. What most people don't realize is that right up to NT4 windows still ran on 16 bit drivers and the hybrid nature of the system caused a lot of the problems. Most of the win98 and ME users I worked with were resetting their computers 4 and 5 times a day. WinNT cleared all that up by going to a fully 32 bit architecture and 2000 made it user friendly again. Still, I hanker for the simplicity of the good ole DOS days when a programmer knew exactly what was available all the time.
For compatibility reasons (easier to re-compile), a lot of "baggage" was kept around. This is why we still have stuff like LocalAlloc, GlobalAlloc, for example. Existing code will always be a factor - the costs of rewriting working applications, just because the operating system changes, is too high.
Yep. A LOT of baggage. What they should have done instead of keeping all the 16bit dlls was to create a fully 32 bit system with a win 3.1 emulator for older programs. Would have saved us all a lot of trouble.
I havn't actually looked at 64-bit Windows, but I suspect there will be some new stuff, but mostly the things we already know and love/hate (take you pick).
Pelle
Apparently the AMD64 is the favored CPU for the win64 (longhorn) platform and they are trying to keep 100% 32 bit compatibility as part of the distribution. I've seen it on screen but haven't had the chance to climb inside yet... It is FAST, I'll give it that. But, frankly, I'd rather dual boot or have to launch an emulator than see more hybrid code.
In any case, I rather suspect the 32 bit stuff will be around for a few years to come... I still have customers running XTs with DOS 6 and win 3.1... oddly enough, they're the ones I almost never hear from....
-
I was lucky, went straight from DOS to Win32. But I still liked running win 3.1 the best. It was fast, small and very easy to setup. Win95 was a big improvement for programmers but a lot of security and stability issues surfaced. What most people don't realize is that right up to NT4 windows still ran on 16 bit drivers and the hybrid nature of the system caused a lot of the problems. Most of the win98 and ME users I worked with were resetting their computers 4 and 5 times a day. WinNT cleared all that up by going to a fully 32 bit architecture and 2000 made it user friendly again. Still, I hanker for the simplicity of the good ole DOS days when a programmer knew exactly what was available all the time.
Looking back, I really don't miss DOS, Windows 3.0 (yuck!), Windows 3.1 (better) and Windows NT 3.X.
Windows 95, Windows NT 4, at least had a user interface that made sense. Sure, you had to reboot Win95 5 times a day, but it was much better than 50 times a day - with Win 3.X. It affected normal users too, not just programmers. Too much trouble, too much support. Been there, done that, don't want to see it again...
Yep. A LOT of baggage. What they should have done instead of keeping all the 16bit dlls was to create a fully 32 bit system with a win 3.1 emulator for older programs. Would have saved us all a lot of trouble.
Maybe. The fact that you could start your 32-bit journey with a simple re-compile of your 16-bit code (provided that you followed the guidlines) really simplified things. You could immediately get access to a more stable program, more memory and so on. Then you could gradually add more stuff - important if you try to maintain a large project...
Apparently the AMD64 is the favored CPU for the win64 (longhorn) platform and they are trying to keep 100% 32 bit compatibility as part of the distribution.
Well, it's the favored CPU right now. Didn't they have a Itanium version before? That didn't work out...
In any case, I rather suspect the 32 bit stuff will be around for a few years to come...
I'm pretty sure it will be around for a long time. Less good reasons to upgrade this time. Win32 is a pretty stable platform, after all. Many people will probably run it as long as they can - "why fix it, if it ain't broken"?
Pelle
-
Looking back, I really don't miss DOS, Windows 3.0 (yuck!), Windows 3.1 (better) and Windows NT 3.X.
Ok, I admit it, I'm a freak :? I still fire up an old Exidy Sorcerer from time to time and play with the 8 bit z-80 basic... cassette drives and all. Even still own a p1 that runs win95 for "retro" testing.
Seriously though... I didn't mind win 3.1 and DOS 6. I found it very easy to get along with. Thing is not to tinker it to death. Get it set up and leave it do it's thing. Mind you the lack of built in uninstall was a real nuisance.
Windows 95, Windows NT 4, at least had a user interface that made sense. Sure, you had to reboot Win95 5 times a day, but it was much better than 50 times a day - with Win 3.X. It affected normal users too, not just programmers. Too much trouble, too much support. Been there, done that, don't want to see it again...
Awwww... you're no fun :lol:
Maybe. The fact that you could start your 32-bit journey with a simple re-compile of your 16-bit code (provided that you followed the guidlines) really simplified things. You could immediately get access to a more stable program, more memory and so on. Then you could gradually add more stuff - important if you try to maintain a large project...
Yeah there was that. I never did write for Win3.1, though. I had something of a gap in my programming career as I got sidetracked for about 6 or 7 years in hardware. Building custom high end systems (some of the first home theater PCs in fact... computer and data projector in a coffee table kinda stuff) was a bit of a money maker so I went that way for a while. Just after the millenium I started drifting back into coding and made the big Delphi mistake. My partner and I just recently closed down and retired... so it's back to hobby coding. (Thanks mostly to your version of C and the excellent support you give, by the way)
Well, it's the favored CPU right now. Didn't they have a Itanium version before? That didn't work out...
Well, the skuttlebut I'm hearing over on this side of the pond is that the whole Itanium thing is something of a bust anyway. P4s are running circles around them... I rather think they'll end up being server chips and not much else. AMD seems set to take the 64 bit market by storm. Even better since they finally learned how to make a decent heat interface...
I used to build AMD-XP systems (use one personally) and got really tired of the heat alarms going off all the time. the problem was that mouting a heat sink on those little buttons was like balancing a barrel on a brick. The mechanics of it were totally unstable and those silly foam rubber pads did nothing to help. I finally solved the problem by using (are you ready for this) little bits of tire patch rubber on the corners of the chips to keep the thing steady. But I didn't figure that out before we lost a ton of money on repeated service calls... everytime someone moved their computers around we ended up replacing the pads on their heatsinks.
I'm pretty sure it will be around for a long time. Less good reasons to upgrade this time. Win32 is a pretty stable platform, after all. Many people will probably run it as long as they can - "why fix it, if it ain't broken"?
This is true. Win32 has evolved very nicely. WinXP pretty much clobbered the instability problems and the faster cpus don't show up it's laziness the way older chips would. Win2000 is still my platform of choice, it's fast, stable and more than a little fun to program for. I've been using the same installation of win2k for almost 5 years now.
I think I'll probably be at this for a while :wink: