AuthorizationExecuteWithPrivileges() will fail with errAuthorizationInternal if there is no TEMPDIR

On Mac OS X function AuthorizationExecuteWithPrivileges() will fail with error errAuthorizationInternal (-60008, "something else went wrong.") if environment variable TMPDIR points on invalid (not existent) path. The reason of such weired behavior is call to tmpfile() inside the AuthorizationExecuteWithPrivileges() function. The moral is - use more explanatory error codes :)

Some more info on that issue can be found in Apple Mailing Lists.

Classes generated from XAML (in WPF) are public by default

In Windows Presentation Foundation, classes generated from XAML markup have public visibility by default. Why not internal (like interfaces)? I don't want my application GUI private classes to be visible from the outside of its assembly. More over, it is not possible to alter that default in language-neutral way. One need to use x:ClassModifier attribute in XAML root element to change class visibility specifying language-dependent value (internal for C#, Friend for VB).

Links on the topic:
- Nice post about that problem
- MSDN article on x:ClassModifier
- Microsoft Connect ticket on that problem

The right way to check whether the C string is empty

It is:

char *s;
// .. do something with s ...
if (!*s) printf("empty!\n");

or

if (0 == *s) printf("empty!\n");

I prefer the second one, because find it easier to read, but it doesn't matter really.

The most popular bad ways to do this:

• if (0 == strlen(s)) printf("empty\n");

• if (0 == strcmp(s, "")) printf("OMG, empty!\n");

And it is not a joke, today I saw 2 independent reviews with such kind of stuff.

p.s. There is a popular joke about how foreign developers check bool value to be a true:

if (4 == strlen(bool2str(value))) printf("its true!\n");

Structure and class methods have external linkage

Lets look on small example:
File f01.cpp:

#include <stdio.h>
struct TEST
{
    TEST() { printf("TEST from f01: created\n"); }
    unsigned m;
};
void f01()
{
    TEST t;
    printf("TEST from f01: sz=%u\n", (unsigned)sizeof(t));
}

File f02.cpp:

#include <stdio.h>
struct TEST
{
    TEST() { printf("TEST from f02: created\n"); }
    unsigned m1;
    unsigned m2;
};
void f02()
{
    TEST t;
    printf("TEST from f02: sz=%u\n", (unsigned)sizeof(t));
}

File main.cpp:

#include <stdio.h>
void f01(); // prototype
void f02(); // prototype
int main(int argc, char *argv[])
{
    (void)argc; (void)argv;
    f01();
    f02();
    return 0;
}

Program output:

TEST from f01: created
TEST from f01: sz=4
TEST from f01: created
TEST from f02: sz=8

Top level window receives WM_GETMINMAXINFO before WM_NCCREATE

Keep in mind, that on Windows top level window receives WM_GETMINMAXINFO message prior to WM_NCCREATE. Such behavior can be fatal for application that executes window initialization code in WM_NCCREATE message handler, since when receiving WM_GETMINMAXINFO window is not initialized yet.
Oh, that cruel, stupid world...

Another good reason not to run program by its name in Windows

When searching for executable by its name Windows always looks in:

• Current working directory
• Windows system directory (use GetSystemDirectory() to obtain it)
• Windows directory (use GetWindowsDirectory() to obtain it)
• Directories listed in PATH environment variable

This list (I will refer to it as search directories) can be expanded with more directories when performing specific tasks.
If name does not contains file extension (for example notepad or attrib), Windows will use glob "name.*" to find file with extension that is listed in PATHEXT environment variable.

It's okay if you need just to run notepad or mspaint from command line. But what if you need to execute some program many times? Well, running it by its name is definitely not your choice. I'll try to explain why.

Dangerous logging

Today I will try to scare you:)
The most common realization of logging is something like that (simplified):

#include <stdio.h>

#ifdef _MSC_VER // workaround for MS VC
#define snprintf(b, bsz, f, ...)                \
        _snprintf_s(b, bsz, _TRUNCATE, f, __VA_ARGS__)
#endif
#define LOG_LEVEL 2
#define LOG(lvl, ...) do {                       \
    if (LOG_LEVEL < lvl) break;                  \
    char b[1024];                                \
    snprintf(b, sizeof(b) - 1, __VA_ARGS__);     \
    b[sizeof(b) - 1] = 0;                        \
    printf("%i! %s\n", (int)(lvl), b);           \
} while(0 == __LINE__)

Whether this windows binary is 32- or 64-bit?

The fastest way to answer on this question without using special software tools is:

1. Open windows binary file in any text/hex editor (notepad is enough)
2. Find first occurrence of "PE" string (it will be probably placed at offset 0xD0, 0xF0 or something like that after phrase "This program cannot be run in DOS mode")
3. Skip 2 non-printable symbols (both '\0')
4. Look on the symbol you are at:
   
   • 'L' - i386 binary (x86)
   • 'd' - amd64 binary (x64/x86-64)
   • '\0' (zero) - ia64 binary

p.s. You can use that method for any PE binary (like .exe, .dll and others)