Also, I always use a macro to define the export type of classes and functions so that they can be used in both static and dynamic libraries easily.

I'm pretty sure they wouldn't take to kindly to that :) Like I mentioned before, if I had my druthers, they'd all be forced to use XP SP3, no exception. Unfortunately, the reality is that this will not happen, and there is no reason for them to update the old machines, in their minds, since none of the boxes face the outside world. It will slowly happen, however, as they retire old hardware: so I'll just bide my time. Regards, -B "[F]reedom isn't a licence, it's responsibility." [David Gerrold, Author's Note in "The Man Who Folded Himself", 2003, p. 119]

Thanks, I figured it'd be a tough one... just thought I'd ask :) One option I was already looking at was generating a map of all the function addresses and giving plug-in builders a stub to link with that would find the location of the function in the loaded executable, properly construct the stack for its calling convention, and then call it. Very harry. As for the API idea: we were planning on exporting a simple and well defined API for public plug-ins, but we would like to have private plug-ins have first-class access to all the symbols in the running process, which is the problem area. As for shared memory, I'd love to do that too, but it would require some time to track down all the globals we export, and I'm not sure I'm up to spending the next few days (years?) tolling though 20+ years of code to find all the interdependencies. So, although it's a great suggestion, I think this part needs to be automated, to be done at build time, such that any new globals will automatically be exported/shared. Also, I've little faith that the Linux/UNIX developers would appreciate me making them add extra dressing to their globals (and even if they loved the idea, if someone forgets once just before a release, then our users are out of luck if they want to access that object). I think we'll just scrap the idea of "private" plug-ins for now, and just define a basic public API. We already support SOAP, among other network based communications channels, so we may just expand the SOAP interface to allow for a greater range of hackery. Thanks for the input. cheers, -B

Here is how, for anyone who's interested. // ... template< class Element, class Traits = std::char_traits<Element>, class Allocator = std::allocator<Element> struct MyContainer { typedef std::basic_string<Element, Traits, Allocator> string_type; typedef std::map<string_type, string_type> type; }; // ... template< class Element, class Traits = std::char_traits<Element>, class Allocator = std::allocator<Element>, class Container = MyContainer::type class basic_configuration { // ... }; // ... cheers, -B

Cool. I'll drop you a line a few days before I'm in the area. I guess I'll see you in a few weeks. cheers, -B

No, I never really looked into it any further. Regards, -B "[F]reedom isn't a licence, it's responsibility." [David Gerrold, Author's Note in "The Man Who Folded Himself", 2003, p. 119]

That sounds great. I use the VC6 version all the time. It's one of the reason I haven't completely moved to VC7 yet. Todd Smith CPUA 0x007 ... shaken not stirred

Well, no. Remember that a program (including device drivers) allocate memory above and beyond that which is stored on the hard drive. Consider that some kinds of drivers (such as file system drivers) can allocate huge amounts of memory for caching and other things. One could write a custom filesystem driver which created a static 500MB cache in memory for your data acquisition project. This isn't for normal, run of the mill devices, but rather custom situations. -- Where are we going? And why am I in this handbasket?

Yep, and if that fails, there's always the beer! ;) Andy Metcalfe - Sonardyne International Ltd (andy.metcalfe@lineone.net) http://www.resorg.co.uk "Lots of people want to ride with you in the limo, but what you want is someone who will take the bus with you when the limo breaks down."

BS in Computer Science. Started in Pre-Med Majoring in Chemical Engineering. The Fortran course for Engineering got me interested, but the Assembler course got me hooked. I loved the way those '1's and '0's worked. And I'm thankful everyday that I found my true calling. But, when I hire Programmers now, I don't put a lot of emphasis on the Degree. All 3 of the BEST PROGRAMMERS I've ever worked with did not have CS Degrees. It's the experience that counts. I STRONGLY believe in Testing for a position. I've tested newly graduated CS Majors who didn't have a clue about programming or life for that matter. I hate being a CodeProject LURKER because this site has been truely helpful to me, but I swear I am working on documenting and making examples for a couple of my classes and as soon as I get the time ..........

LOL, I though you would have known what it looks like. I guess I need to break down... ... um, break down and get one too. Tim Smith Descartes Systems Sciences, Inc.

haha... thats pretty good

Yeh right, lets find a pair of toilets right next to each other on either side of the equator and flush......... :confused:

LOL!! :laugh: -Ben --------- On the topic of code with no error handling -- It's not poor coding, it's "optimistic" ;)

Yes its true. There are too many people just talking religiously about MFC vs WTL vs ATL etc... Each technology has got a use, thats why it was invented in the first place. A wise programmer will know what technology to choose for his application, or part of his application. Personally I have used most of the technologies like MFC, ATL, WTL, STL, and even JScript for the same sofware package. They all blend in nicely if used properly. Regarding the MFC issue, well they say it is bloated, slow and large to distribute. Well, I totally agree, however UI applications are, by nature, bloated, slow and large to distribute when compared to their server side counterparts, so MFC is the best suitor. James (2b || !2b)

> I also have an old Pentium that has Linux running, I > suppose I could set it up as one... but I think it might > slow things down, seeing as its only running at ~75 MHz. Unless you've got a really fast outside line, you are more than fine with that machine. I'm myself running an OpenBSD 2.8 with ipf and NAT on a 486/66 (yes, I saved that machine for this special purpose) with (an overwhelming) 20MB of RAM and an almost ten year old SCSI drive, and the OS has an average load of less than 1% CPU.