Cluebat-man to the rescue - All Comments

re: Preventing a DLL from being unloaded by the app that uses it

bullet — Sun, 28 Jun 2009 18:13:52 GMT

From what I read your "right way" shouldn't be done this way. The MSDN says calling LoadLibrary() in a DLLMain() should not be done which you do. I don't even understand why this doesn't get a lock-up, you call LoadLibrary() on a DLL that hasn't finished loading. From my understanding this should go into an infinite loop. I didn't read the referenced article on the NT Loader though. I assume it tags loaded-but-not-intialized DLLs?

re: Installing Zune software without internet connection

noko — Mon, 15 Jun 2009 19:38:34 GMT

I bought a zune and found that microsoft made it so that the zune software can't be run on a linux-based operating system with wine. this annoyed me, but i prepared a desktop computer with XP installed so that i can get the zune software going on it. come to find out, i needed an internet connection. i was pissed. thanks for the tutorial though. helped me out a lot!

re: Creating a thread safe producer consumer queue in C++ without using locks

Sauvaget — Thu, 11 Jun 2009 06:41:32 GMT

Hi,

To have atomic manipulation on basic types like integers (readIndex and writeIndex ) you can use (only under linux with the pthread library) the __sync_fetch_and_add() function to increment it for example.

I guess you have to align your basic type.

Theses atomic functions are made to be used with basic types, not structures.

Nicolas.

re: Creating a thread safe producer consumer queue in C++ without using locks

Angelovic — Fri, 05 Jun 2009 10:21:02 GMT

Hi Bruno,

thank you a lot for this useful article.

I'd like to ask you for an expert advice :-) since I'm not sure about 1 thing. I was considering why elements in the queue need to be volatile.

Proper instruction ordering is still ensured even if queue is not volatile: since m_Read and m_Write are volatile, and they have proper Acquire/Release semantics - the compiler will not reorder memory instructions and so flag is always set after the queue has really been updated.

So it appears to me that the only important reason why the queue is volatile is when there are multiple processors, each one having its own cache. That way reads/writes to the queue are immediately reflected in the shared memory, am I right ?

I'm asking because type T in my case is a class which is not under my control, and compiler insists on having operator= for that class defined as volatile.

And one more question: If I'm right with the above presumption, then even if I do use locks to synchronize access to the queue, it still needs to be volatile to work in multi-processor enviroments. Is this correct... ?

I thank you in advance for your reply,

S. Angelovic

re: My 2 new kitchen knives

Vic — Sat, 18 Apr 2009 18:34:18 GMT

Wusthof are excellent choice for kitchen knives, there are many types of Wusthof knife. If you got the right type to cut meat, then Wusthof will be better choice than The Kai. Yes its true there are saying that japan knives are sharper than any other knives in the world, but nowadays choice of sharp knives also available from different brand.

re: Scheduled task would not run

vanDooren — Wed, 15 Apr 2009 12:39:52 GMT

In the scheduled task properties you can specify that the task has to be aborted if it runs for longer than x time. And after that it can be restarted.

Bear in mind that IF the task is aborted, any processes started with it are NOT aborted.

In some cases, the first thing my task does is to kill all processes normally associated with that task to avoid problems. I have one task that starts Excel to produce a report via some macros. And sometimes it fails.

To avoid problems, it kills all Excel processes and instances of teh ActiveX servers that are running.

re: Scheduled task would not run

Tom — Fri, 10 Apr 2009 15:28:06 GMT

What happens if the Task is already running when the Scheduler calls it again. Is there a configuration setting that allows you to stop the current or delay the new task until the previous one finishes, etc.?

I had the same issue as you and used a program called IsUsedBy mstsoftware.com to determine what program is using the Task. It showed me I had 17 calls to the program that had been abandoned. A reboot would have fixed mine as well but I would not have known.

re: Practical ATL: Understanding the class object

glass — Thu, 09 Apr 2009 11:30:02 GMT

So good article!I have kown lot of detals about COM,Thanks very much! I think I will read more of your blog articles in the feature !

re: Good riddance to /clr:oldSyntax

vanDooren — Mon, 16 Mar 2009 22:19:17 GMT

There are 2 ways that spring to mind. The first is that /clr:oldSyntax is configured under configuration properties ->general->Common Language Runtime Support which could still be set to 'Use common language, old syntax.

The other place where it could be specified would be under configuration properties ->c++->command line

But my money would be on the first option.

NOTE: this can also be specified on a file by file basis.

So first check the project settings. if you don't find it there, have a look for which file generats this problem, and then look at the file settings.

re: Good riddance to /clr:oldSyntax

Dilip — Mon, 16 Mar 2009 18:15:19 GMT

I am a little late to this party but how in the God's name do I remove this compiler option from the set of compiler switches? I have migrated my project to VS 2008 and I get that dreaded D9035 warning which says that the /clr:oldSyntax option will be deprecated in a future release. Ok I get that but how do I remove it?

re: Preventing a DLL from being unloaded by the app that uses it

Frank Young — Fri, 06 Mar 2009 04:53:41 GMT

By the way, I believe your idea of injecting second dll to the remote process and having that dll unhook the first one would definitely work.

And it seems easier. I try my current method is just out of curiosity.

re: Preventing a DLL from being unloaded by the app that uses it

Frank Young — Fri, 06 Mar 2009 04:41:38 GMT

Hi vanDooren,

Thanks.

It turns out I have to inject the binary executable code to the remote thread and have that code to call the GetProcAddress("MyExportedFunc") to obtain the function pointer.

A weird thing is: when I WriteProcessMemory to copy the &LocalThread to RemoteAddress, the copied binary isn't exactly the same as the original code. There are 4bit error in the 5th byte

I verify this by reading the runtime memory address in the processes, respectively. And I also memcpy the binary code to a local buffer and the same error happens.

I guess this may be due to Windows Vista has some protection on reading data from the code segment.

I work around this by declaring a const char[] to maintain the machine code I want to inject and now everything sees ok.

Thank you for your help and hope my experience can be of any use.

Frank

re: Preventing a DLL from being unloaded by the app that uses it

vanDooren — Wed, 04 Mar 2009 18:33:44 GMT

what you could do is to export a function in your dll that will perform the unhook function. the hook handle will be stored in a global variable in your dll.

then a second application will inject a thread in the target process that will call that dll function. this should unhook the hook.

to be honest, I never tried this, so there might be a caveat or 2. one thing that could be necessary is to store the hook handle in a shared data segment (using declspec). But if the unhook function executes in the context of the target process, this shouldn't be necessary.

Another thing that could be necessary is to have your thread function call LoadLibary after it is injected to load the dll, and then use getprocaddress to load the function pointer for the DLL function that will perform the unhook.

re: Preventing a DLL from being unloaded by the app that uses it

Frank Young — Wed, 04 Mar 2009 04:37:22 GMT

Hi vanDooren,

Your description here is valuable to me since I'm having trouble to unload the dll that contains some Detours code. And Your solution 3) on Dec. 17 exactly matches my requirement.

However, I don't know how to obtain the function pointer in my DLL module which unhooks the system calls.

Existing sample codes I found leverage GetProcAddress() to obtain a well-known function pointer (which is assumed to be the same across different processes) in Kernel32.dll (like LoadLibrary). But the function in my DLL is not shared across process. Even it's shared, different process may load it onto different memory address.

Are you aware of any solution to this?

Thank you very much!

Frank

re: Scheduled task would not run

Andy — Tue, 03 Mar 2009 20:46:43 GMT

Thanks! This helped me solve a problem i was having.

re: Practical ATL: Implementing an enumerator object

vanDooren — Mon, 02 Mar 2009 23:25:10 GMT

Sorry we were talking about 2 different things.

I just read that section in the C++PL, and it says what you mean, but that is not why I had the NULL. I should perhaps rephrase that part.

I know I can simply do something like end=begin + size, for example, and the pointer will work for the sake of arithmetic.

But there is nothing there to dereference. I misinterpreted your earlier remark to mean that you thought that C++ inserted a dummy element that could be dereferenced. My bad.

Anyway, yes I know the address value will be valid.

But I have learned the hard way never to pass pointers to other components without making sure that there is something valid there.

I have worked with enough programmers who had problems with the concepts that pointers had to point TO something. I learned not to give out pointers on the understandig that it was for arithmetic only.

Yes, they should have known these things. But it's not like I had any say in whom I worked with, since I was the outside consultant.

And if their component causes trouble, they are to blame. But unfortunately, I was the lead programmer who had to fly to France to figure out why this very expensive satelite testing system was crashing regularly.

So learned to apply 'defensive driving' skills to programming. Adding the NULL doesn't have any significant cost, but if someone else screws up by making a simple mistake, using my pointer, it doesn't take down the system.

re: Practical ATL: Implementing an enumerator object

Daniel Anderson — Mon, 02 Mar 2009 15:54:19 GMT

you can doubt as much as you can, read TC++PL 3rd edition, chapter 5, section 3 state:

"Taking a pointer to the element one beyond the end of an array is guaranteed to work."

re: Creating a thread safe producer consumer queue in C++ without using locks

vanDooren — Sat, 28 Feb 2009 10:34:30 GMT

Aieee....

Yes you are right. I know this is true. The default compiler settings of gcc and vc make this a non issue in normal circumstances, but you are right that changing the default packing size can cause serious problems if the integers are not naturally alligned.

I should have though to mention it. I'll see if I can update my article. Thanks.

re: Practical ATL: Implementing an enumerator object

vanDooren — Sat, 28 Feb 2009 10:20:14 GMT

I'll check it out to see if I can find a mention of that in the C++ reference. I doubt this is true, because I would have noticed it in e.g the size of a struct with embedded arrays. It could cause other problems as well (the dummy unconstructed elements)

I'll post a follow up with the answer, regardless if I am right or wrong. Thanks for commenting

re: More Terminal Server License Server weirdness

Allen — Sat, 28 Feb 2009 01:14:54 GMT

I had this same event happen.

I was running Server 2008 for 120 days and when the terminal license server expired, it was offline for a day or so. I reset the actual server and now I have been running Terminal License Free for about 3 months.

I have purchased 20 extra license just in case it flips out on one day and tries connecting to the terminal licensing server, but for now, its alll good.

Strange.