Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

326 Neutral

About moeron

  • Rank
  1. moeron

    windows "home directory"

    Like Colin Jeanne said you can use SHGetFolderPath. This works for XP and Vista. There are a number of pre-defined folders you can get by using this function. It sounds like the one you would want is CSIDL_PROFILE... Quote: CSIDL_PROFILE (FOLDERID_Profile) The user's profile folder. A typical path is C:\Documents and Settings\username
  2. threadpool is a thread pooling library based on boost::thread. Could be a useful resource.
  3. This same issue struck me a couple days ago. In my case the problem was caused by including some files that had modification dates in the future. I know that may sound odd - but it was because some of the core technology I use is developed in Bulgaria ( about 6 hours ahead of me in Baltimore ) and I had just got a brand-spanking new sdk to work with. I solved the problem by writing a quick Ruby script to go through and set the access / modification times for the files to my current time. I don't know if this applies to your situation - but it may be worth a shot to check it out.
  4. moeron

    Some wxWidgets questions.

    You might have better luck finding an answer at the wxWidgets forum.
  5. I haven't tried this myself - but maybe try running VS 2003 with compatibility set to be XP SP2? You can change the compatibility settings by right-clicking over the shortcut/exe you use to launch VS 2003 and going to the "Advanced" tab. There should be a compatibility section at the top of that page.
  6. I'm guessing you are talking about Win32? If so, I've never tried this before but I suppose you could use EnumWindows and EnumChildWindows to figure out which windows are behind your window in Z-order. Then you would just need to get their device context where they overlap with your transparent window and apply whatever your algorithm is for the foggy glass effect to that and store it in your window's device context. *edit* You can also check out the GetWindow function - but you need to be careful using it as you can get handles to destroyed windows that way.
  7. I've also banged my head against this issue many times. I don't understand the logic of not being able to expand returned values in the auto window. I guess you just have to assign the return value to something and look at it through the usual methods. Pain in the ass and illogical? Yes.
  8. SetWindowsHookEx is the Win32 API function used for creating hooks. General Hook Information
  9. Quote:Original post by Serge K Quote:Original post by Shadow Wolf The difference between the two is that "Multi-Byte" is your standard day-to-day ASCII 255 bit patterned formatNot at all. Multi-Byte normally referes to the extensions to ASCII designed to cover huge character sets by using variable length encoding. On Windows platform you may meet Big5 for Chinese and Shift JIS for Japanese. If you do not care about Win98 — you don't have to use Multi-Byte strings in your application. I think he may have just been referring to what its called in Visual Studio. The only two choices are "Multi-byte character set" and "Unicode" - and in this case the MBCS does just yield you regular ASCII chars ( I've never done anything with any extended characters so I'll defer to your knowledge on that ). But thanks for clearing that up - I'd always wondered why it was called a multi-byte character set when a char was one byte.
  10. Well I've got my little test app to work with delay-loaded dlls from memory. After doing some reading I found... #include <DelayImp.h> #pragma comment(linker, "/DelayLoad:DLLTest.dll" ) // delay load my test dll #pragma comment(lib, "DelayImp.lib") // microsoft helper funcs for delay loading The DelayImp.lib brings in a function called "__delayLoadHelper2" (and a couple others) which wraps the LoadLibrary / GetProcAddress stuff. This stuff is found in "delayhlp.cpp". So I just made my own version of this file and removed "DelayImp.lib" as a dependency. My little tester app works fine - but I still have the uncomfortable feeling that comes from messing with crap I don't fully understand. Even though I have successfully delay-loaded a dll from memory- I'm thinking I still might just throw in the towel and find a better solution. I'm sure me hacking around in that stuff is bound to cause issues on some Window's platforms...Oh well. [Edited by - moeron on May 22, 2007 5:55:22 PM]
  11. Quote:Original post by Evil Steve If you're linking statically, then you'll need the .dll file as a file, in which case there's no need for any form of LoadLibrary(). If you want to do runtime linking (And get delay loading for free), then don't link to the .lib file and use [Memory]LoadLibrary(), and GetProcAddress(). If I could ditch the import lib then I could use the code I found for the MemoryLoadLibrary with no problem. But, unfortunately, it isn't an option for me due to the wide scope of usage of functionality from this particular dll. It would be a pretty large undertaking at this point to stop relying on the import lib. I guess I'll have to come up with some other way to avoid my licensing issues. Quote:Original post by iMalc So what is the problem with simply setting the project up to delay-load the secondary DLL? It's a piece of cake to do. Delay loading isn't difficult - its getting delay-loading to work with a library loaded from memory. The actual goal I'm going for is being able to keep a dll hidden in memory ( see OP for full explanation ).
  12. Yeah I'm not sure. My "knowledge" on the subject is based solely off a few hours googling and looking at some articles. I was kind of hoping someone else has already went through this before. I'm linking to the dlls import library - so I was under the impression I would need the delay-load to make it so my application wouldn't automatically load the dependency so I could load it from memory. [edit] I misread the article, MemoryLoadModule is not CRT - your right. [Edited by - moeron on May 22, 2007 1:03:02 PM]
  13. I know it is possible to delay-load a dll using VC 2005 - and I'm aware of a way to load a DLL from memory using MemoryLoadLibrary from the CRT. However, is there anyway to combine these two methods? The basic reasoning behind this is I have an application that uses dll "x" - in the application this dll is wrapped up in some license protection scheme. Now I have a couple other little "helper" tools that are free-of-charge and should be distributed freely. However, these helpers also depend on dll "x". But I do not need these to get the protection scheme. I shouldn't really distribute the non-protected "x" dll or someone could realize that if he copies our unprotected "x" over the protected "x" it will circumvent the protection scheme. So thats what led me to the idea of loading the dll from memory. But that won't work on its own since I link to an import lib ( and have to ). Delay-loading will get around the import lib issue - but that creates its own functionality to wrap a LoadLibary - GetProcAddress when accessing the functions from the delay-loaded dll. I guess if I could just somehow replace the LoadLibrary to a MemoryLoadLibrary call then all would be fine - but so far I've not seen anyone discuss such an implementation. I'm leaning toward a solution that isn't super-complex as I am on a bit of a deadline to figure something out. Thanks!
  14. moeron

    STL Map

    Quote:Original post by brain21 ah yes, that's what I was affraid of. I typed this simple program into my MSVC++ 6.0 and compile and get 241 errors. Most from some file called xiosbase. This is what I tried: *** Source Snippet Removed *** Have you modified your project's include directories or otherwise modified the original MSVC 6 installation? I copied and pasted your code into my MSVC 6 Service Pack 5 and it compiled and linked with no warnings or errors. I'm not sure if the difference is the fact that I have a later service pack, or if there is some other strangeness going on. Maybe you should repair your installation? Again, as everyone else has said - if you have any choice whatsoever not to use VC 6 you should avoid it. But I can't see a reason why that code wouldn't work.
  15. google "RAII" - it stands for Resource Acquisition is Initialization. Its a long name for saying "grab resources in constructors - release them in destructors". By doing this you are more exception-safe. If you wrap those calls up in the constructor/destructor then your interface is acquired automatically whenever you instantiate an object - and it is released properly automatically whenever that object falls out of scope and is destroyed. If, for example, you directly call your createInterface function and then an exception is fired off you are not guaranteed to release the interface - but if that call is in your destructor it will be released as the stack unwinds and your object falls out of scope. This could also come up if you return out of a function earlier than you expect (an error condition maybe ).
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!