There are already binary distributions out there, but I like to compile things myself, so I whipped up a Visual Studio 2010 project to compile the Lua static library (lua.lib) the command line interpreter (lua.exe) and the script compiler (luac.exe).

First things first. If you just want a zip file with those three binary files (the library is Visual Studio 2010 compatible), look no further:

• Lua 5.1.4 binaries compiled with VS 2010 (lua, luac, lua.lib, and necessary headers)

If you want to build Lua 5.1.4 yourself (like me) just grab the most recent copy of the 5.1.4 source code from the Lua website. Next, grab these Visual Studio 2010 project files and solution file:

• Lua 5.1.4 Visual Studio 2010 projects (to build the binaries yourself)

To use the project files, just unzip them into the root directory of your Lua source files (where the README, INSTALL, and COPYRIGHT files are). Then, load up lua-vs2010.sln in Visual Studio 2010. You should see three projects. The first, lualib will build the static library under lib/lua.lib. The second and third, lua and luac will build the Lua interpreter and compiler under bin/lua.exe and bin/luac.exe.

Enjoy!

If you need to install fonts accessible to all users on the system, you have to do some more complicated voodoo. I hate voodoo, so I’m not going to cover that.

If all you need is to install a font for your own user, it’s just this simple:

Put your myfont.ttf file in your home directory, under directory called /.fonts/. So in other words, your font lives at:

/home/youruser/.fonts/myfont.ttf

Create the directory if it doesn’t already exist. Finally, restart any application you want to use that font in, and you should see it show up. You’re good to go.

However, there is a nasty bug in the most recent version of VirtualBox (3.1.2) when combined with Fedora 12. After installing the Guest Additions kernel modules as per the user docs, the system boots to a black screen with a cryptic error message that looks like a SELinux labeling problem (it’s not).

type=1305 audit(12587840002.571:32444): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 subj=system_u:system_r:readahead_t:s0 res=1

The problem is actually with the Guest Additions video driver, the one that gives you the nice resizable desktop window. Once the driver is built and installed, for some reason the X server can’t find any screens and refuses to start.

Until the bug gets fixed in the video driver, here’s how you can fix the system so that it will boot correctly, although you’ll lose the dynamic resizing ability. You’ll have to stick with fixed, predefined resolutions for now.

1. Mount a Fedora 12 ISO, such as the full or network install discs, and boot to it. Boot into Rescue Mode from the GRUB bootloader screen.
2. Breeze through the language and network options, but be sure to have it mount your hard disk image (it will mount under /mnt/sysimage).
3. Drop into a shell and change into your hard disk’s X11 config directory, so that would be:
   cd /mnt/sysimage/etc/X11
4. Edit your xorg.conf file… but wait! In Fedora 12, they switched to HAL for X configuration, so there is no xorg.conf file! Never fear, you just need to create one and it will override the HAL:
   vi xorg.conf
5. Now, use the following settings for the new xorg.conf file:

   Section "Device"
       Identifier "Configured Video Device"
       Driver "vboxvideo"
   EndSection
   
   Section "Monitor"
       Identifier "Configured Monitor"
   EndSection
   
   Section "Screen"
       Identifier "Configured Screen"
       Monitor "Configured Monitor"
       Device "Configured Video Device"
       SubSection "Display"
           Depth 24
           Modes "1440x900" "1680x1050"
       EndSubSection
   EndSection
   
   Section "InputDevice"
       Identifier "vboxmouse"
       Driver "vboxmouse"
       Option "CorePointer"
       Option "Device" "/dev/input/mice"
   EndSection
   
   Section "ServerLayout"
      Identifier   "Default Layout"
      Screen      "Configured Screen"   0 0
      InputDevice   "vboxmouse"
   EndSection
   

6. You’ll see I’ve defined two resolutions, 1440×900 and 1680×1050. What this allows me to do is work windowed at 1440×900 and if I want to go full screen (remember, dynamic resizing won’t work) I can hit the full screen shortcut in VirtualBox (Host+F) and change the resolution within Fedora to match my screen res.
7. Save from vi (:wq) and reboot the system. Remember to unmount the install disc! The system should boot correctly now, albeit without dynamic resizing.

A huge thanks goes out to Jits in the VirtualBox forums for this fix!

Frequently you have some class which is composed inside another class, but occasionally needs to access the class it’s composed inside of. Basically, the classes are composed inside each other, though the abstraction really only makes sense in one direction. Confused yet?

In this example, we’ll use a Refrigerator class which stores inside it an instance of a Cheese class. Why cheese, you ask? Because cheese is delicious. Also, our refrigerator is from the future and can slice and serve cheese just like the built in ice maker and water dispenser. It’s a pretty sweet fridge.

Now, we were all taught to keep our #includes in our header files, not the implementation files, so like good little programmers we construct our classes like so:

refrigerator.h

#include "cheese.h"

class Refrigerator {
private:
    Cheese *pCheese;
    int temp = 35;

public:
    void ServeCheese();
    int GetTemp();
};

refrigerator.cpp

#include "refrigerator.h"

void Refrigerator::ServeCheese() {
    printf("Now dispensing %s cheese!\n", pCheese->GetFlavor());
}

int Refrigerator::GetTemp() {
    return temp;
}

cheese.h

class Cheese {
private:
    Refrigerator *pFridge;
public:
    char *GetFlavor();
    void CheckTemp();
    void BeginMolding();
};

cheese.cpp

#include "cheese.h"

void Cheese::CheckTemp() {
    if (pFridge->GetTemp() > 45) {
        BeginMolding();
    }
}

char *Cheese::GetFlavor() {
    return "cheddar";
}

I’ve left out the constructors in this example for brevity, but let’s assume that they get the pointers set up correctly so that our instance of the Refrigerator class has a correct pointer to an instance of the Cheese class and vice versa.

Now, at this point you may be screaming that this needs to be refactored and reorganized. Yes, it probably does. But there are many instances where you simply can’t, and in fact the abstraction really only makes sense one way. The fridge has cheese in it, but the cheese certainly doesn’t have a fridge in it. We just need that pesky reference around so we can check the temperature of the fridge every so often.

(Yes, I am aware that the fridge could push it’s temperature down to all the items in it, ala the Observer Pattern. Yes I am aware that would be a better solution. But this is a contrived example anyway, so stick with me here.)

Now, the code given above doesn’t compile, because the Cheese class has no idea what the heck this Refrigerator class is, so we either need to include it or forward declare it. If we try to do this:

cheese.h

#include "refrigerator.h"

our compiler (more specifically, the preprocessor) is going to get very angry at us, depending on which order it decides to compile refrigerator and cheese. The solution, is a forward delcaration:

cheese.h

class Refrigerator;

class Cheese {
    // ...etc...
};

Basically what this does is tell the compiler, “Hey! There’s this class called Refrigerator that I might talk about, so here’s an empty declaration of it!”

The problem, though, is that this is rather limiting. Within the Cheese class, we can declare pointers to Refrigerator class, no problem. Pointers are of fixed size, so the compiler doesn’t much what care what it’s a pointer to, since it knows how much memory it needs to hold a pointer to it. When we try to access members of the class, though, like properties or methods, it falls apart because as far as the compiler knows, the class is empty. After all, we told it the Refrigerator class didn’t have anything in it.

So if we can’t #include it and forward declaring it doesn’t give us what we want, what can we do?

Well, we can do both. Kind of.

The solution is to forward declare in your header file, and #include in your implementation file. This will avoid the preprocessor headaches of of the chicken and egg #include, while allowing us to access the members of forward declared class in the implementation. In other words, here’s the fix:

cheese.h

class Refrigerator;

class Cheese {
    ...
};

cheese.cpp

#include "cheese.h"
#include "refrigerator.h"

Again, it goes without saying, the better solution is to refactor or rearchitect your code if you can. These kind of hacks can get really out of hand and are usually a good code smell that something needs to be fixed at a deeper level. However, if you’re working on a large codebase that you can’t change, this can help out a lot.

It’s well documented on how you go about spawning entities, but I couldn’t find a good place explaining how to remove spawned entities through code.

Don’t try meddling with the global entity list (gEntList) or calling its RemoveEntity() method. It doesn’t do what you want.

Instead, used one of the super-handy UTIL_* functions. Given a pointer to the entity you want to remove, simply use:

UTIL_Remove(pEntity);

Poof. Entity gone. Remember, entities are created and destroyed on the server side only. The server will automatically broadcast any changes to the entity list to its connected clients for you.

A friend of mine sold me 2 older 19″ flat panels for just $50, but I needed a second videocard to drive the extra displays. Although I absolutely detest shopping there and I avoid it at all costs, I picked up a GeForce 9800 GT from Best Buy. Don’t worry, it was on sale so I was getting screwed slightly less than usual.

Interestingly enough, the 9800 is practically identical to the 8800. The two biggest differences are the move to the smaller manufacturing process (55nm from 65nm) and an updated BIOS on the card. This particular model is made by PNY and is tagged with an “EE” at the end to denote that it’s an “Energy Efficient” edition. Basically it means that it doesn’t require the standard 6-pin PCI-E graphics card power connection from your PSU. It draws all of it’s power (only 66 watts under full load!) from the PCI-E bus. Thankfully my 550 watt power supply is beefy enough to drive both cards without breaking a sweat.

Installation was simple enough. Getting Windows XP to recognize the second card was another story, though.

See, what you’re supposed to be able to do is just drop the card into the second slot and when you reboot, Windows will happily say “Wow, cool, nice new videocard! Lemme install those drivers for ya so you can get started experiencing multi-monitor bliss!” In fact, my copy of Windows just said “New videocard? Huh? Nobody tells me nutin’.”

And thus the issue debugging begins. I really hate this part.

First up was checking that the card was seated correctly. In the process of reseating the card, I noticed a small daughter card between my videocard slots that allowed you to specify if you were using single or dual videocards. “Sweet,” I thought, “this is the problem right here. I swapped the daughter card around to “dual videocards”  and booted up the rig.

No dice.

Next I thought perhaps the nVidia drivers only detected new cards when they were installed. I wiped off the current nVidia drivers and downloaded the latest copy. After reinstalling the video drivers, Windows still had no idea the second videocard was even there.

As I was double checking my motherboard manual to make sure dual videocards without SLI was indeed supported, I noticed that when one card is installed it runs at 16x speed. When two cards are installed, however, it splits the PCI-E bus and runs both cards in x8. “Perfect,” I thought, “I’ll just check the bus speed to see if the motherboard even sees the card.”

After locating the window in the nVidia control panel that shows you the PCI-E bus stats, I verfied that indeed, my single card (the 8800 GT) was running in x8. The motherboard was detecting the second card.

By this point, you’re probably wondering why I was using the 9800 GT (the newer card) as my secondary graphics card and the older 8800 GT as the primary card.

The only negative comment I found when looking through reviews of the PNY 9800 GT EE was that for some reason the fan seemed locked to 45% speed. Normally the fan spins up as necessary to cool off  the card under higher load, but this card didn’t seem to do that. You can adjust the fan speed manually through the nTune software, but I didn’t particularly feel like adjusting this every time I played a game, or have my computer sound like a Harrier jet 24/7. (It already sounds like a idling tractor.) Since the cards are practically identical performance-wise, I figured I’d leave the 8800 pulling gaming duty while the 9800 only had to push out the pixels to the 2 new monitors.

Since the 9800 wasn’t being detected by Windows, I then figured that maybe I’d try swapping the cards. After installing the 9800 in the primary slot and the 8800 in the secondary slot, I was greeted to a driver installation of my 9800, but my 8800 was nowhere to be found. At this point, I was seriously worried that somehow my motherboard’s second PCI-E slot was unusable.

I gave it one last hurrah and swapped the cards back. As soon as I booted up, I was greeted by nVidia’s multi-monitor setup wizard and Windows dutifully installing the 9800 drivers again. All four monitors were working.

Moral of the story: If your secondary card isn’t getting detected, install it in the primary slot and give Windows a chance to see it and install the drivers. Then swap it back to the secondary slot.

Lastly, this post couldn’t possibly be complete without pictures!

Four monitors means I can get my LCD tan 4x quicker!

Playing Team Fortress 2 across three screens is only one of many uses!

If you’re feeling particularly brave, check out these screenshots to see what I’m seeing when I play Team Fortress 2. Thanks to the SoftTH utility, I can get triple head gaming without the Matrox hardware adapter!

plr_pipeline as Pyro with SoftTH

plr_pipeline as Soldier with SoftTH

Google did not disappoint. I found this awesome web-based regex test tool built on Adobe Flex called RegExr. If you’ve got Flash installed, it runs right in your browser.

Not only does it show you what it’s matching live as you type, what your match groups contain, what each chunk of your regex means, etc., but it’s also got a phenomenal quick-reference sidebar for all those handy meta-characters. You can even save your favorite regexs and browse other people’s favorite submissions.

We need more tools like this. I was able to quickly and easily prototype a regex in no time at all, and the app took about 10 seconds to figure out how to use.

Thanks, gskinner.com! You guys are awesome!

Today at work a coworker received a large volume of joke emails telling them how bad their coding style was, with links to example code telling them to “learn how to program”. This was in response to what he thought was a simple 6-line change, but was actually a 22,000-line “oops”.

He opened up a file that’s roughly 25,000 lines (let’s not get into why it’s that long…) to make a simple change. After adding about 6 lines, he saved, quit, and committed the change to the repository. His editor of choice is vim (as is mine).

For those of you unfamiliar with vim, it’s a text-based editor that has a fairly steep learning curve. It takes years to truly master, but the power it offers you is incredible. In vim you start in command mode, which let you enter vim commands much like you would on a command line. You can switch to insert mode to actually insert text into your document, or other modes for formatting and whatnot.

Well in this case, the programmer accidentally brushed the escape key while he was typing, which brought him out of insert mode and into command mode. What he thought was being typed into a comment in his code was actually being typed into the vim command line. He must have brushed some other keys as well, because here’s the unfortunate key sequence that he ended up entering:

:% <<<<<<<<

For those of you not well-versed in vim commands, here’s an explanation. The colon starts a command, and the % symbol is like a wildcard for the command, applying it to the entire file instead of the current selection. Each < character shifts the current selection one tab stop to the left. Similarly, the > character shifts the current selection one tab stop to the right. It’s phenomenally handy for quickly adjusting the level that a block of code is indented.

However, what that above command will do is basically crush every level of indention against the left margin, and then apply that to the entire file. What you end up with is having every line of your beautifully indented code smashed down to column 0. No indention. None.

As vim was updating this change to the swap file (remember, there were 25,000 lines) he saved and quit. The file had been updated, but his screen had not, so he had no idea he’d accidentally just nuked the indention of the entire file.

It was his commit to the repository that threw up the red flag. This was supposed to be a small bug fix. However, the commit email, sent out to the entire mailing list, contained a 22,000 line diff. Woops.

After looking at the changes and chuckling over the fact that the file was completely unreadable now, many people on the coding team sent him joke emails about “what crappy coding style” he had, with links to “learn how to program”.

Now, naturally this took only about 2 seconds to fix, since the code was under source control. But the point still stands. Not only learn your editor, but watch it with a careful eye when you’re working with it, lest all those features that are there to increase productivity turn against you.

Before I explain why I think this is another example of Microsoft spending their time doing something incredibly useless instead of innovating, let me explain that all these blasted _s functions are one of the reasons I detest the Windows API so much.

I had the unfortunate “pleasure” of digging rather deep into the Windows API for a project I was working on this past spring quarter. For those of you who haven’t ventured into the Windows API, let me say this: It’s so incredibly confusing that it doesn’t even look like C anymore.

Almost everything uses custom types, even when there’s no logical reason to do so. The Linux API does this to some extent, but not nearly as bad as Microsoft.

Secondly, there seems to be no rhyme or reason as to what these types are named. Some are named as ALL_CAPITALS_TYPE, others _use_this_strange_underscore_prefix, and some use the standard type_t. If you start to use almost any standard library C function, you’ll inevitably be told by the compiler that you’re doing it wrong, and should use strcpy_s(), or _strcpy_s(), or _s_t_r_c_p_y_s_(). Seriously, their API has got more underscores than Bill Gates has dollar bills.

What this gives you is this strange, alien language that vaguely resembles C, but is so ugly and hideous that you’re afraid to touch it. Apple has Objective-C. Microsoft has Franken-C.

So let me back up and explain this blog post I mentioned earlier. I’m a bit behind on this one (I’ll admit I’m not often found venturing into the MSDN blogs) but back in May the SDL announced that they were adding memcpy() to their banned functions list, to join strcpy(), strcat(), strncpy(), strncat(), gets(), and others.

They announced it’s replacement, memcpy_s() (soon to be replaced by _memcpy_s() and _m_e_m_c_p_y_s_() I’m sure), which takes one additional argument: the size of the destination buffer.

This is aimed make usages of memcpy() more secure, by only copying up to the size of the destination buffer bytes, even if that’s less than the length of the bytes you want to copy. You go from using this:

memcpy(dst, src, len);

to using this:

memcpy_s(dst, sizeof(dst), src, len);

This sounds reasonable, except most Windows programmers will just do this:

memcpy_s(dst, len, src, len);

which makes your “secure” version useless.

The problem here is not that memcpy() doesn’t check the size of the destination buffer, but rather that some programmers are using it without thinking. A 50 caliber sniper rifle is a very powerful tool in the hands of a marksman, but in a cage full of chimpanzees, the results could be disastrous.

If nothing else, memcpy_s() makes you think about the size of the target buffer.

I suppose, unless you’re one of the mindless programmers using memcpy() unsafely before, in which case you’ll learn the new and improved mindless version memcpy_s(dst, len, src, len) and continue on your merry way.

My point here is that banning functions that are the common source of security vulnerabilities doesn’t fix the problem, because the problem isn’t with the functions. These functions are well documented and we know exactly how they work and what their dangers are. The problem is with the programmers.

You’ve got to teach your programmers how to use these functions securely, or at least evaluate when they should ask for someone to review their code. If training isn’t an option, there’s a better option than banning these functions.

Ban programmers who use them wrong. Yes, banish them to the land of C# and other fluffy dynamic languages with garbage collectors and infinite buffers. They’ll do far less harm there.

The key to doing memory management correctly (which includes using memcpy(), strcpy(), etc. in safe ways) is to completely engage your brain when you’re doing it. You cannot zone out when writing memory managing code. Although given the quality of code coming out of Redmond, I would not be surprised if most of the programmers have their brains permanently switched off.

As classic-Microsoft as this blog post was, the best line was last one.

I wonder when Larry, Steve and Linus will start banning strcpy() in their products?

Words cannot express the hilarity that ensued when I read this line. Maybe, just maybe, the reason they haven’t found the need to ban them is because they’re using them correctly. Perhaps if Microsoft tried that every once in a while, they would churn out more secure products themselves without having to resort to Franken-C.

I ran across this issue when playing around with nginx. I was trying to set up phpMyAdmin for SQL administration, but ran into a rather peculiar issue. To explain the problem, let me give you some context.

I’m running nginx only on port 443, using SSL for everything. As I’m going through the setup for phpMyAdmin, imagine my surprise when it alerts me that I’m not using an SSL connection. In fact, it’s impossible for me not to use SSL, because there’s no regular HTTP server running on port 80. I continued with the setup anyway, checking the ForceSSL option which requires all phpMyAdmin requests to be done over SSL. When I finished installing it and tried to log in, I got a Firefox error that it was stuck in a redirect loop.

Much Google searching later, I still couldn’t find the problem. This was when I remembered that PHP is configured differently on nginx that is typically done with Apache. With Apache, many people use the mod_php module that compiles PHP support directly into the server. With nginx, you generally process PHP requests using FastCGI.

I wondered if perhaps the fact that the connection was taking place over SSL wasn’t being passed through to the FastCGI process. If that was the case, the phpMyAdmin setup script wouldn’t know it was being invoked over HTTPS, and when you tried to log in it would try to forward you to the HTTPS url, which is the same page you had just requested. That would push you into an infite redirect loop.

In fact, that’s exactly what was happening. You can fix this with a simple addition to your nginx.conf file:

server {
    listen 443;
    ... more config here, include SSL ...
    location ~ \.php$ {
        ... FastCGI config here ...
        fastcgi_param HTTPS on;
    }
}

That fastcgi_param HTTPS on; line does the trick. Now the PHP script knows it’s being invoked over SSL and doesn’t try to infinitely redirect you. Awesome.