It has been some weeks ago when I needed to find a way to make to be executed with full rights. There are several reason why you got to do so e.g. get write-access to C:

It was my aim to show that nice UAC Dialog from Windows itself when the rights are needed.

And this is how it works:

Create a manifest for you executable which is simple xml:

<?xml version="1.0" encoding="utf-8" ?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0"
processorArchitecture="X86"
name="yourApp"
type="win32" />
<description>Your App Description</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"><security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" />
</requestedPrivileges>
</security>
</trustInfo></assembly>

this is the important line:

<requestedExecutionLevel level="requireAdministrator" />

Now you can rename it to (YourApp).manifest. The .NET Framework when executing the file will see the Manifest and handle its contents.

Or you can, which I regard as better, embed the .manifest file into you executable.

mt -manifest YourApp.exe.manifest -outputresource:YourApp.exe

The mt.exe come with Visual Studio SDK which can be downloaded at Microsoft’s.

To simplify this I created a Post-Build event which looks like this:

“C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\mt.exe” -manifest “$(ProjectDir)$(TargetName).exe.manifest” –outputresource:”$(TargetDir)$(TargetFileName)”;#1

An important note:
If your assembly is strong named, you will be unable to embed the manifest into it as it would invalidate the strong naming.

Some source:

Every assembly, whether static or dynamic, contains a collection of data that describes how the elements in the assembly relate to each other. The assembly manifest contains this assembly metadata. An assembly manifest contains all the metadata needed to specify the assembly’s version requirements and security identity, and all metadata needed to define the scope of the assembly and resolve references to resources and classes. The assembly manifest can be stored in either a PE file (an .exe or .dll) with Microsoft intermediate language (MSIL) code or in a standalone PE file that contains only assembly manifest information. (http://msdn.microsoft.com/en-us/library/bb756929.aspx)

If you need to get a crashdump running Windows Vista you’ll look for DRWTSN32.EXE for ever and a day. Unfortunately, it’s in vain, Dr Watson died…

Nevertheless that app has been very important for collateral quality control.

Vista has increased the intricacy of everything a lot. In general Vista is not saving minidumps, but keeps account of every crash or error report. If an app is WER registrated a crashdump is stored as well - if it’s not no crashdump is at dumpfolder. Neither here nor there.

This is how it works on Vista (as fair as I could figure out):

• WER just makes a crashdump for WER signed apps respectively if the WER server requests a report
• To get a minidump the following regesty value has to be set:
  HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ (DWORD) create a key named “ForceQueue” and set it to 1.
• Dumps are getting stored in user directory C:\Users\TheUserName\AppData\Local\Temp and C:\ProgramData\Microsoft\Windows\WER\ReportQueue. File extension is *.mdmp.
• You can have an overview at Control Panel-> maintenance -> Problems & Solutions -> Check Problems

You also can find several instructions on the web howto install Dr Watson on Vista. There also seems to a tool called DrVista that might help you - which I didn’t try…

Many users and forum programs in attempt to make automatic e-mail address harversting harder conseal them via obfuscation - @ is replaced with “at” and . is replaces with “dot”, so

bill.gates@microsoft.com

now becomes

bil dot gates at microsoft dot com

I’m not an expert in regular expressions and I’m really curious - does such obfuscation really make automatic harvesting harder? Is it really much harder to automatically identify such obfuscated addresses?

For example, if every email address on a large community site is reversed in the markup and rendered properly with CSS, or token-replaced (@ becomes ‘at’), or any other predictable method, the harvesters will just write a thin adapter for your site.

Think of it this way: if it only takes you one line of code to “scramble” them sitewide, it will only take the harvester one line of code to “unscramble” them for your site. Roughly speaking.

What concept is the right? Do more complex obfuscation or consider about new ways?

Obfuscation techniques fall in the same category than captchas. They are not reliable and tend to hurt regular users more than bots.

Javascript obfuscation seems to be praised, but is no silver bullet: it is not that hard today to automate a browser for email sniffing. If it can be displayed in a browser, it can be harvested. You could even imagine a bot that’s taking screenshots of a browser window and using OCR to extract addresses to beat your million-dollar-obfuscation-technique.

Depending on where and why you want to obfuscate emails, those techniques could be useful:

• Restrict email visibility: you may hide emails on your website/forum to anonymous users, to new users (with little to no activity or posts to date) or even hide them completely and replace email contact between members with a built-in private messaging feature.
• Use a dedicated spam-filtered email: you will get spammed, but it will be limited to this particular address. This is a good trade-off when you need to expose the email address to any user.
• Use a contact form: while bots are pretty good at filling forms, it turns out that they are too good at filling forms. Hidden field techniques can filter most of the spam coming through your contact form.

One common way of hiding email from bots and spammers is to create an image containing the email address. Facebook does this, for instance. Now, using images for email is inherently bad for accessibility, because text readers will not be able to read it. But even otherwise, there are several free character recognition programs that do a pretty good of decoding such email-images.

At least you have always to keep in brain that if it’s difficult for the spammers it’s as well your users to identify the email address. A nice article from wikipedia on Email obfuscation or address munging you’d pay regard to.

The real question is whether the extra effort will be put in by harvesters and if the (major? minor?) barrier to the harvesters is worth the possible problems for your users.

—

Finally this article is as so many about fighting spam - In my opinion, spam has become such a problem and so many databases have been turned over that we’re beyond hiding our addresses. Instead, consider of more efficient ways of classifying and blocking spam.

From time to time I have battles with Visual Basic Script, which I usually avoid using.

I wanted console output because the process I’m starting should be unattended, rather than clicking through a bunch of MsgBoxes.

Typically, one prints in VBscript using a Wscript.echo("Hello, world!") line or some variant thereof. If you do not invoke with a cscript hello-world.vbs, you get a GUI/pop-up MsgBox, which I wish to avoid. I just wanted something to go right to the command line for output, without putting cscript at the beginning.
Wscript.StdOut.WriteLine dies, of course, if not also invoked with a cscript.

For different reasons I didn’t want to permanently set my default scripting host to cscript, either.

Probably the best solution to solve that problem is a simple stub in the script that will be called when it starts, which detects how the script was started, and re-starts it explicitly using cscript.exe if needed. It makes use of the wscript.fullname property (which is the path to the running host executable, either c:\windows\system32\cscript.exe or wscript.exe). If the script is running as wscript.exe, it will simply re-launch the script using cscript.exe and exit.
This way, if the local machine has wscript as the default host, it will immediately launch, detect that it was launched via wscript, and re-launch itself using wshell.run as a cscript. The local host doesn’t need to be reconfigured for this to work.

'this is at the start of your script
CheckStartMode
 
' This is somewhere else in your script
Sub CheckStartMode
     ' Returns the running executable as upper case from the last \ symbol
     strStartExe = UCase( Mid( wscript.fullname, instrRev(wscript.fullname, "\") + 1 ) )
 
     If Not strStartExe = "CSCRIPT.EXE" Then
          ' This wasn't launched with cscript.exe, so relaunch using cscript.exe explicitly!
          ' wscript.scriptfullname is the full path to the actual script
 
          set           oSh = CreateObject("wscript.shell")
          oSh.Run "cscript.exe """ & wscript.scriptfullname & """"
          wscript.quit
 
     End If
End Sub

The only disadvantage of that solution is that it closes the console window it opens as soon as the script is finished. I went through all of the options for intWindowStyle in the Run method of the WshShell object and none of them kept the spawned console open for more than a flash. Maybe there’s a hack for it, too.

The Google C++ Testing Framework known also as Google Test, based on xUnit has been used by many of the Google C++ developers to help in unit testing their C++ applications. It is portable and works on Linux, Windows, Mac etc with GCC and MSVC compilers and even embedded systems. You can even use it to kill your Linux applications so that they die as you expect them to. Or have it continue testing after non-fatal errors. Now they have made it available as an open source library.

Google doesn’t claim that their test framework is better than others but they have made it easy to extend it by adding new test macros. You can read more in the primer and faq.

Link: Google C++ Testing Framework

Algorithms can often be implemented recursively or nonrecursively; the decision rests with the programmer, who might shy away from a recursive solution because the algorithm might not terminate or that performance might be poor. In reality, recursion can allow for very elegant code as well as facilitating an interesting and economical type of code reuse.

Iterative algorithms, especially those with a loop, can usually be easily rewritten to use recursive function calls instead of loops. In some cases it’s a bad idea because the iterative version is usually simpler, faster, and uses less memory.

The classical scenario for recursion was search algorithms, factorial calculations, and so on. A well-know algorithmn that uses recursion is Binary Search.

This recursive version checks to see if we’re at the key (in which case it can return), otherwise it calls itself so solve a smaller problem, ie, either the upper or lower half of the array.

int BinarySearch(int iSortedArray[], int iFirst, int iLast, int iKey) 
{
   if (iFirst <= iLast) {
       int iMid = (iFirst + iLast) / 2;  
       if (iKey == iSortedArray[iMid]) 
           return iMid;  
       else if (iKey < iSortedArray[iMid]) 
           return BinarySearch(iSortedArray, iFirst, iMid-1, iKey);
       else
           return BinarySearch(iSortedArray, iMid+1, iLast, iKey);
   }
   return -(iFirst+ 1);    // failed to find key
}

Besides elegant code design recursion can be the reason for some problems.
Recursion isn’t safe in C/C++ because there is no reasonable way to deal with running out of call stack space. Even if you dynamically allocate stack frames from the heap, you still can run out of heap and how do you handle the error then?

You might convert the failed call stack allocation into an exception that unwinds the stack until an out-of-stack exception handler is found, but the problem is that any function in any library called from a recursive routine might be the call that blows the stack.

Fortunately any algorithm that can be written recursively can be rewritten iteratively by keeping a heap-based stack object (and if it can be written completely tail-recursively, you don’t even need a stack). The code might be uglier when written iteratively, but it’s always possible.

You’d defenetly use recusion when you can guarantee two things:

• Each recursive step breaks down the problem into a smaller problem of the same type.
• Each recursive step reduces the problem significantly.

The first is a general rule of recursion. If each step doesn’t break the problem down into a smaller problem of the same type, it’s harder to write a recursive function and guarantee that it will terminate. The second is kinda personal guideline. I generally won’t write a recursive function unless it divides the problem in half with each step. This way I can verify with relative ease that the algorithm will be efficient.

Originally I planted to write this post about anonymous recursion with lambda in c#, but then I decited to describe recursion basics a bit more in detail.

A simple recursive function in c# would be for example:

private static double pow(double var, double n)
{
    if(n == 0)
        return 1;
    else
        return var * pow(var, n - 1);
}

Anonymous recursion is a recursion technique that uses anonymous functions.
I got the idea to define a special delegate type for self-applicable functions:

delegate T Pow<T>(Pow<T> self);

The delegate above can be defined like this:

Pow<double> myPow = f => f(f);
 
myPow(myPow);

When myPow is being applied to itselfwill apply myPow to itself, which will … infinite recursion. While not particularly useful in this setting, the example demonstrates that you can in fact have recursive application in a lambda expression. Now all we have to do is to make it do something useful as it goes, such as call functions recursively.

Recursion is beautiful and lambdas are the ultimate abstraction. But that’s too much for now…I’ll write about that sometime.