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]

Why not just have a start-up item of you own always set the values for you, every time you log-in. That way, even if they are reset every time you reboot, you're logging with auto-start-up scripts will set the correct value (assuming they run AFTER the policy scripts--in which case you'll have to find way to to triggered once the policy scripts have done their thing.)

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]

Hi All: I'm sure there are a number of you who have gone through this experience in the past, and rather than reinvent a method, I thought I'd ask first. Has anyone converted a large number of static libraries to DLLs using an automated method (or semi-automated)? Is there any advice you would give someone trying to do this for the first time? We have about 20 or so to convert, and ideally we would like to find a method that also allows us to use the conversion information to make *nix dynamic objects as well (but it not a hard requirement).

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]

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]

My condolences ;) I believe we dropped that flavour of Windows just before I joined the team. A lot of the core kernel calls was there, but some of the niceties are only just being address now.

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]

We may just have to; I was just hoping that we could cover everyone, including those who do not want to touch any of their perfectly-ok-and-running-machines. If I had any say in it, I'd make XP the base requirements, period; unfortunately, we have far too many people with production Windows 2000 machines for this to be feasible. Thank you for your help. I'll need to further contemplate how backwards compatible we care to--or can--be.

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]

I actually have an implementation that uses those functions; unfortunately, they are not all necessarily supported on Windows 2000: it depends on how up-to-date the machine is. Sorry, I'm just making this really difficult :) (It's not intentional, however; it just our current predicament.)

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]

Sorry, I should have made myself clearer. This is to be done programmatically. We would like to determine if a network interface can wake a machine. Also, we would like to give our user's the option to turn this on for any network adapter they may be using to route our application's traffic.

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]

modified on Monday, September 15, 2008 10:48 AM

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

Howdy: I'm new to the driver scene and I need a small pointer or insight to a situation I'm encountering. The Vista (Server 2K8) SDK has a plethora of power management calls, making power management trivial. Unfortunately, we still support Windows 2K, so we cannot rely on these calls. After a bit of registry and internet trolling I found which registry entries need to be modified in order to allow a device to bring the computer out of a sleep state. My question is: how do I ensure that the changes are applied to the hardware, rather than just being a new entry in the registry? It occurs to me that reboot would do the trick, but that seems a little drastic to me. Is there a less disruptive way of telling Windows that a device's PnP (where the power settings are stored) settings have changed? Maybe I don't need to?

cheers, -B

I was wondering if anyone knew of a straight forward way of calling (non-exported) functions in an executable from a DLL. We are building a, for lack of a better name, private plug-in system that will grant the plug-in access to all of a processes internals, without having to export the hundreds of methods and classes we have.

cheers, -B

We used to build our software with VC 6.0 and use rebase.exe to split the debug information off into a separate file (after adding debug information to the Release builds). Once we moved to VS 2005 and Vista, the same procedures stopped working. The Release build still have the options turned on to add debug information to executables; however, rebase.exe fails to find it. We need the .dbg files so that we can create crash reports, if the software ever fails on a remote system.

cheers, -B

We used to build our software with VC 6.0 and use rebase.exe to split the debug information off into a separate file (after adding debug information to the Release builds). Once we moved to VS 2005 and Vista, the same procedures stopped working. The Release build still have the options turned on to add debug information to executables; however, rebase.exe fails to find it. We need the .dbg files so that we can create crash reports, if the software ever fails on a remote system.

cheers, -B

Why not just save the pen size and colour information along side every path? cheers, -B

Nice! I've got 2 1/2 years under my belt. cheers, -B

Christian Graus wrote: Did you think ? Were you already a Mario fan ? I've finished them *all* and I think the only scope for disappointment is that it's not the quantum leap that Mario 64 was, and that the story does not allow for the variety of levels that M64 had. But it's still awesome IMO. I was a huge Mario fan, but that was back when version 3 was all the rage, they really haven’t interested me much since—I guess I just bought it out of habit. Christian Graus wrote: Me too, have you played Cel Damage ? Yes, I did, but I didn't enjoy it all that much, I was just interested in the graphics themselves. Christian Graus wrote: I agree, I can't wait to get an Advance and use it. Wish they had thought about it ages ago, it makes playing quest games in pairs all that more fun. cheers, -B

I'm defiantly behind you on that one Christian. I've had mine for just over a year and I'm really happy with it. As for the games, Mario Sunshine was so-so, Metroid Prime was excellent (wonderful attention to detail) but the new Zelda is by far the best game I've played in years. Some people complain about the 'cartoon' graphics, but I’m a big fan of them. I must admit I did have my doubts initially, but after a few minutes playing, I changed my mind completely. They are so well done that I sometimes forget I'm playing a game and not watching Saturday morning TV. My only complaint is that they could have used a tinge of anti-aliasing, there are a few times when the jaggies (sp? word?) creep in… but I hear that was more of a hardware issue than software?? Someone please correct me if I'm wrong. Oh yeah, and the ability to hook up the GameBoy Advance to it is really cool. cheers, -B

You can find the word by using the multimap container's find method. As for the index to the word, what do you mean by that? There are no indexes in maps, per-say; however, you can get an iterator that references the matched pair (Which I gather is a CString-to-int), but not an integer (unless you mean the int that is paired with the CString in which case you would just dereference the iterator returned by find and access the second data members). cheers, -B

It compiles fine for me, are you sure it's not some other thing that is causing the trouble? Maybe post some of the code surrounding this snippet. cheers, -B

Nitron wrote: Maybe I will have to attempt my own STL replacement for CString... Before you dig in, check out the Boost Format library[^]. It might just be what you're looking for. cheers, -B