Another title might be “A Website’s For Life, Not Just For Christmas”. It’s also technically a Lesson From ’12, but hey, it’s still January, so near enough.

I made the mistake of not regularly updating one of the applications installed on this server for a few months. Zen Photo, which runs the gallery where I host my photographs, had a pair of lethal security holes thanks to some insecure versions of 3rd-party code (TinyMCE and ajaxFilemanager) which resulted in a rather ingeniously stealthy hack being deployed without me noticing.

Plus, I’m fairly sure I wouldn’t have detected it, if it hadn’t been for the security breach at my hosting provider, Dreamhost, a few days ago.
(more…)

2011 saw an explosion of ‘hacktivism’ and black-hat chicanery – the antics of LulzSec and AntiSec, the breaching of Sony’s PlayStation Network, HBGary and Stratfor; previously confidential data getting sprayed onto Pastebin on a weekly basis.

Despite none of my precious private data being involved, all this carnage steadily convinced me it was time to take my password management much more seriously. Although I had a handful of decent passwords in play, some were shared amongst several sites, some were years old .. and who knew what my logins were for the swathe of random forums and mailing lists I’d accrued over the years? Decidedly amateur.

Enter KeePass and Wuala.
(more…)

Here’s a tiny “post-mortem” on porting Freesynd to the latest Native Client SDK. This was about a days worth of tinkering and covers one of the most troublesome issues when moving a traditional application to a locked-down browser environment – mandatorily asynchronous file access, usually involving threading hilarity. All those blocking fopen()s won’t work here, matey.

This work was done on Windows, so it also covers the fiddles requires to get printf-debugging working and the joy of cygwin when working with naclports packages. If you want to just port a natty little SDL app without going near cygwin, a download of the patched SDL libraries pre-built for use in NaCl 0.5 is available from my space on GitHub - source available via naclports.

(more…)

Flash, Java, HTML5, WebGL, Mono, Unity… for the game developers out there not programming in C/C++, it seems there are ever increasingly powerful ways to write-once and deploy-everywhere. I’ve been playing Project Zomboid recently – a charming 2D zombie survival RPG, written in Java and thus playable in a web browser on any reasonably capable platform. It’s an approach used to great effect by the wonderfully popular Minecraft, offering players a near zero-wait-time, no-installation path to playing. This kind of low barrier to engagement is increasingly more essential as users’ expectations rise and attention-spans fall; plus, as an indie developer, you get your game infront of as many players as possible without having to worry about porting to a handful of different OSes yourself.

So what do us suckers still using lower-level languages get to play with? Google offer Native Client (NaCl), a project that aims to offer secure execution of ‘universal’ executables atop a browser process. The browser becomes the “OS” (quite literally, in the case of ChromeOS), providing key system services, abstracting away platform-specifics yet allowing near-native runtime performance. Compile once, run on many, you don’t have to learn JavaScript. That’s the theory, at least. Does it work?

Well, yes it does. In fact it’s pretty damn slick.

Browser game portability meets C/C++ in an <embed> tag.

Above is Freesynd, the open-source rebuild of cult-classic isometric shooter Syndicate, ported to NaCl last weekend and running inside Chrome 15. CPU usage is pretty minimal, even when running the map rendering at 1024 x 800. The game code can easily communicate with the browser (all that green file loading debug spew) and vice-versa (mouse movement, buttons that send cheat codes to the update thread).

I’m certainly not the first to tread this path – someone has already worked DOSBox into NaClBox, offering a way of running classic DOS games with zero hassle or setup. Even the NaCl SDK ships with a patch for getting Quake I running, including an impressive stress-test of having 9 separate instances of the game running in a single browser frame.

This is all really quite marvellous, something of a revelation for someone more used to having to port engine code to each new platform by hand. I can pull the above page up on Windows 7, or on my Mac, or in Ubuntu and it will execute, identically, on each, in 32 or 64bit as appropriate. Targeting for ARM architectures is on the roadmap, as well as the even more ambitious PNaCl (P for Portable) extension, moving the technology to use LLVM IR as its transmission medium.

We could end up with games and applications, written in high-performance languages, optimised into native machine code on-demand and delivered securely into the browser, free to also take advantage of all the functionality offered therein, like SVG and HTML5 UIs. dreamy.

So, the downsides? Well, this is only in Chrome so far – infact, the stabilized ABI that arrived in the latest SDK is only available in 14.0 and beyond, so the 18% or so of internet users rocking Chrome won’t be using it just yet. Compiling takes longer than usual, as one is producing multiple NEXE files for each supported configuration, plus I’m seeing file sizes that are about twice the size of their Win32 counterparts – nothing that can’t be solved with some compression, however .. a lot of that bulk appears to be padding or alignment.

There are a few programming considerations to watch for too – older code won’t necessarily ‘just work’ – specifically in the realm of file handling, because, of course, one does not have access to any host-local file system, not that the required files would be on there in the first place anyway. Asynchronous streaming and HTML5 FS Storage are the order of the day. A future post will cover what I ran up against when porting Freesynd, for anyone also toying with the latest SDK.

Really promising results, loads of possibilities – I’m hooked. To ubiquity, and beyond!

A recent distraction has been Clang/LLVM, the compiler infrastructure and C/ObjC/C++ front-end that powers many of the fancy new features of Apple’s XCode 4, as well as being the first real potential successor to the almighty GCC toolchain.

One of Clang’s many redeeming features (for me) is that it can be compiled effortlessly on Windows, in about 20 minutes, into a single monolithic executable. A well-written, customizable, hackable, production-class C++ compiler checked out and debuggable under half an hour? Sign me up.

To help try it out on existing projects, I’ve put together ClangVSx – an add-in for Visual Studio 2010 that emulates the VC build pipeline, swapping in Clang to compile C/C++ code on the fly, translating project settings as it goes. It also offers context-menu options in the code window for sending code to the Clang static analyser, as well as viewing disassembly or preprocessor output (I always liked being able to do that in CodeWarrior)

The vanilla check-out of Clang requires some patches to play nicely with the MSVC linker and not freak out when you show it <windows.h>. I’ll post up my own set of patches to the GitHub page, should they not find their way into the master codeline. Support for various Microsoft-specific extensions and keywords is patchy and occasionally things will be silently ignored, so tread carefully – I was worried to find an old DX9 graphics demo produced a black screen after being fed through ClangVSx, before finding that Clang was ignoring all the inline assembly, resulting in no geometry being generated. Doops.

MSVC 10 vs Clang 3 in smallpt, 256 samples/pixel. Clang is much faster - suspiciously so, at 22 seconds quicker in Release / -O3, but has a strange intersection artefact at the top edge. More investigation required.

Still, there is fun to be had, especially if you like hacking up compilers without having to revert to makefiles.