registry tweaks

every now and then I need some Windows tweaks.
i''ll put here all the things i need.

here's the first ones:

make OutlookExpress independent from Messenger (restart: no)
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Outlook Express]
"Hide Messenger"=dword:00000002


Add 'Explore from here' to Windows folders(restart: no)
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\shell\Command]
@="CommandPrompt"
[HKEY_CLASSES_ROOT\Directory\shell\Command\command]
@="cmd.exe /k cd \"%1\""


matching file names each time you press TAB in cmd. works in XP but doesnt by default on Win2000
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Command processor]
"CompletionChar"=dword:00000009

windows install date

useful when u need something unique from the PC and easy to get

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

installdate value

InstallDate
REG_DWORD
Time (in seconds) since 12:00 A.M, January 1, 1970

here's a VBS script which displays the info:

Dim WshShell, TimeStampSet WshShell = WScript.CreateObject("WScript.Shell")TimeStamp = WshShell.RegRead(_"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\installdate")WScript.Echo "Install date :" & _DateAdd("s", TimeStamp, DateSerial(1970, 1, 1))

before debugging ...

.. you need to make sure you have the right pdb
on microsoft website there is a debugging package(holding WinDbg and other debugging tools) which has a tool called SymChk which can be used to bring the right pdb files from microsoft website.
the tool reads the version of your dll and exe files and tries to find the corresponding pdb for that version.


C:\Program Files\Debugging Tools for Windows>symchk /r c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 /S srv*c:\dbg\symbols\*http://msdl.microsoft.com/download/symbols

/r tells symchk to look in the 'c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322' path and in all subdirectories in it

/s Specifies the directories containing symbols
c:\dbg\symbols\ is the location where the symbols are downloaded

if you need a specific DLL file to get symbol for, you can use this (for ole32.dll for example)

symchk c:\WINDOWS\system32\ole32.dll /S srv*c:\dbg\symbols\*http://msdl.microsoft.com/download/symbols

Now, in WinDbg you can set in File menu the location of the symbols.

also, if you want to start using adplus tool (info:http://support.microsoft.com/default.aspx?scid=kb;en-us;286350) you must set the debugging symbols path in the environment variable
_NT_SYMBOL_PATH
in the value put the path of the symbols(c:\dbg\symbols\)

usually adplus is used in 2 modes:
unexpected haning(used with -hang)
unexpected crushing (used with -crash)
see the msdn link above

i am using it for crashing:
"C:\Program Files\Debugging Tools for Windows\ADPlus" -crash -pn MyApp.exe -o c:\dumps

MyApp.exe must not include a path just filename.

another tool useful is this one: gflags (http://support.microsoft.com/default.aspx?scid=kb;en-us;286470)
usually pageheap is used like this:
"C:\Program Files\Debugging Tools for Windows\gflags.exe" /p enable MyApp.exe /full

again, MyApp.exe must not include a path just filename.

process termination

Ive just looked to an interesting blog article talking about when a process terminates.
http://blog.kalmbachnet.de/?postid=65

It seem that there is a subtle difference between how a console application (the main() CRT function) and a Win32 application (WinMain) is handling the process termination.

if you have this:

DWORD WINAPI MyThread2(LPVOID)
{
while(true) { }
return 0;
}

#pragma comment(linker, "/entry:myMain")
int WINAPI myMain()
{
DWORD dwThreadId;
CloseHandle(CreateThread(NULL, 0, MyThread2, NULL, 0, &dwThreadId));
return 0;
}

the application is a windows application (using myMain entrypoint) and it run infinitely.

but a similar console application:

int t_main()
{
DWORD dwThreadId;
CloseHandle(CreateThread(NULL, 0, MyThread2, NULL, 0, &dwThreadId));
return 0;
}

will return immediately after the 'return 0;'

the difference is this one:

the console application uses CRT which, after the user code return from main, it calls ExitProcess which terminates the application.

it seems that when a thread terminates, Win OS internally calls EndThread. The EndThread internally looks if there is any other thread running in the process and calls TerminateThread(if there are any) or ExitProcess (if there isnt any).

hence, in a Win32 application, if any thread returns, internally EndThread is called and this in turn, if no other threads are still running, will call ExitProcess.

in a CRT app, when the main thread returns, ExitProcess is called directly.

testing memory failure allocation

there is a difference of how the memorey failure is handled in C++.
int *pa = new int[10000];

in the article "The new and delete Operators" the MSDN says:
"Beginning in Visual C++ .NET 2002, the CRT's new function (in libc.lib, libcd.lib, libcmt.lib, libcmtd.lib, msvcrt.lib, and msvcrtd.lib) will continue to return NULL if memory allocation fails. However, the new function in the Standard C++ Library (in libcp.lib, libcpd.lib, libcpmt.lib, libcpmtd.lib, msvcprt.lib, and msvcprtd.lib) will support the behavior specified in the C++ standard, which is to throw a std::bad_alloc exception if the memory allocation fails."

hence is vital to know which one you are using.
"Normally, if you #include one of the C++ standard headers, like , you'll get a /defaultlib directive in your object that will reference the appropriate C++ Standard Library according to the CRT model you used (the /M* compiler options). Generally, that will cause the linker to use the throwing operator new from the C++ Standard Library instead of the nonthrowing one from the main CRT, because the order of defaultlib directives will cause libcp.lib to be searched before libc.lib (under /ML)."

hence if you have the following code:

int *pn = new int[1000];

if(pn)
{
// ok, pn is valid
}


the testing is valid only if you use the CRT new and not when you use the std::new. with the std::new this is not valid, it will throw an exception (i am not sure what will pn point to).

remember the rule

sometimes its hard to figure out which method is called when looking at a hierarchy of classes, which use virtual specifier for their methods.

but, as always, if you know how the things works internally, you will always find the right answer.
I always think that instead of remembering 10 specific cases (which it might not be hard at all for many people, but me for example, I have a bad memory) its much easier to remember 1 thing only, how it works.

this is a case for the virtual specifier.
the thumb rule is this (this is from MSDN):
When calling a function using pointers or references, the following rules apply:
1.A call to a virtual function is resolved according to the underlying type of object for which it is called.
2.A call to a nonvirtual function is resolved according to the type of the pointer or reference.

but this rule might not be always simple to apply.
What is really good is to know why the things are happing like described in those 2 rules. Let's take each of them:
1. when you apply the virtual specifier to a function, at compile time, the compiler will do some things:
it will add an invisible vtable member ( a pointer to a table) to your class;
the vtable is initialized in constructor right after the base classes constructors are called (look here for construction order: http://msdn2.microsoft.com/kstd9k24.aspx this is a reason why when calling a virtual function in the constructor of a base class when creating an object of derived class, the virtual function is not called because the vtable is not initialized yet!)

also, its good to remember that there is only one vtable member in the derived class no matter how the big class hierarchy is and how many virtual functions are;

the term 'underlaying type' is used because you can always store inside a base object an a derived class object.

B b;
A *pa = &pb;

when you call pa->f() ( and f() is virtual declared in class A ) the vtable of the object points to the B::f() version, because the 'underlaying' type is B (i found the name confusing)

when we have an object A* we dont know if the object is an A or a B.
void function(A *pa)
{
pa->f();
}




2. if its not virtual then the function called is the one for the object class (the function is not in the vtable)

Final classes

i camed across a nice C++ question which shows the final class principle (as I read here: http://www.codeguru.com/Cpp/Cpp/cpp_mfc/stl/article.php/c4143/ it seems that the final class specifier exist in Java)

1. A class that is not derived from a class nor is intended to have any class derived from it is an example of what type of class?
A. A concrete class
B. An abstract class
C. A base class
D. A virtual class
E. A final class

A final class is a class from which you dont derive (if you try to, the objects of the derived classes cant be constructed since the compiler will complain about this).
So how can you design such class ?

In C++ there is no keyword (final) to declare a class as non-inheritable as in Java.
But then C++ has its own features which you may exploit to get the same behaviour.
Basically it uses concepts of private constructor and friend class.

For example, lets try to create a class called CFinal.
class CFinal
{
// member data ...
}

We want to be able to use this class, of course, to create objects from it but what we dont want is to be able to use this class as a base for other classes. Or, in other words, if anybody creates a class derived from CFinal, it will not be able to create objects of this derived class.

The first idea will be to make the CFinal constructors private but doing so will prevent us to create objects of it. We need to way to be able to make construction unavailable for the derived classes only.

The solution:
We use the fact that in C++, if a class has a friend class, the friendship is not inheritate in any way; if the friend class has a derived class, this does not mean that the derived class is a friend also for the initial class

class Temp
{
private: ~Temp() { };
friend class CFinal;
};

class CFinal : virtual public Temp
{. . .};

Again, if we have this:
class CDerived : CFinal
{. . .}
CDerived is NOT a friend of the Temp class.

So that now if some one tries to inherit from this CFinal class, compilation gives error as this class cannot call constructor of its super class i.e.
Yet, you can create CFinal objects, because as a friend of the Temp class, your class has access to the private constructor.

The whole idea i got it from this article:
http://www.codeguru.com/Cpp/Cpp/cpp_mfc/stl/article.php/c4143/
"Working with the Final Class in C++" by Zeeshan Amjad