We are a Linux shop here at MakeSweet, but occasionally we need to distribute programs - and that means compiling for Windows. We’ve found that for the cleanest results, MinGW (Minimalist GNU for Windows) is hard to beat. It is useful even if you are compiling on Windows, but it is especially useful if you are cross-compiling from Linux.

Getting set up for cross-compiling for Windows is trivial to set up on Debian/Ubuntu, just do:

sudo apt-get install mingw32

For other Linux systems, you can follow some tips on the MinGW wiki: BuildMingwCross, Build-a-Win32-x-compiler-for-Linux.

Our favorite build system is CMake; there are tips on adapting CMake to MinGW on the CMake wiki at CMakeMingw.

One subtlety with MinGW is that after building, your program may depend on mingw10.dll. This is a freely distributable DLL (on Debian, you can find it in /usr/share/doc/mingw-runtime) but it can be nice to build programs with no extra DLL dependencies. To do that, make sure the “-mthreads” flag is not used during compilation, and remove it if it is. You should be aware of the consequences of removing the flag though, and it may not be a reasonable thing to do. In our experience, if you are not using exceptions, things seem ok without it.

For cross-compiling with MinGW on Linux, CMake helps a lot. See CMakeCrossCompiling for tips. At the time of writing, only the CVS version of CMake supports cross-compiling. You just need to set up a “toolchain” file describing your environment, for me I called it ~/mingwin.cmake and it looked like this:

SET(CMAKE_SYSTEM_NAME Windows)
SET(CMAKE_C_COMPILER /usr/bin/i586-mingw32msvc-gcc)
SET(CMAKE_CXX_COMPILER /usr/bin/i586-mingw32msvc-g++)
SET(CMAKE_FIND_ROOT_PATH /usr/i586-mingw32msvc /home/bozo/mingw/install)
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Then, when configuring a project, the first call to CMake would be like this:

cmake -DCMAKE_TOOLCHAIN_FILE=~/mingwin.cmake .

OpenLaszlo 4.0 has decent DHTML generation. If you are using the command-line compiler for making SOLO deployed material, however, it is not completely obvious what to do.

Specifically, if you compile a source file such as example.lzx:

lzc –runtime=dhtml basic.lzx

You get a “basic.js” file. Tracking down what to do with this file is another matter.

In the tomcat servlet thingie for OpenLaszlo, there is a SOLO Deploy Wizard for DHTML, buried in:

openlaszlo/trunk/lps/admin/solo-dhtml-deploy.jsp

This will take basic.lzx and give you everything you need to wrap it up (including javascript libraries, all the little icons needed for window decoration, etc.)

You can then take that model and return back to the command-line compiler, wrapping the .js file produced in all this material.

This is all fine, just a little non-obvious to people like myself who just use the command-line compiler, and don’t want to touch the tomcat stuff.

Here’s an example bundle: solo-dhtml-example.zip

We’ve written a few Flash applications using OpenLaszlo that need to access a webcam (”ambush“, “puppet“), and render a processed version of its input. This seems a little odd to do, since any webcam processing in practice requires use of a lot of Flash specific classes, so the Flash/DHTML portability of OpenLaszlo is lost. However, OpenLaszlo is such a pleasant way to develop Flash apps that we wanted to use it anyway.

There may be smarter ways, but the somewhat ugly way we found was as follows. First, we create global variables for our input and output bitmaps:

Then, we do some set-up in a global oninit method to enable our output bitmap:

Now we create a view for our camera input:

Now, we can access both our input and our output as bitmap objects:

See the adobe flash site for tips on filters you can use. Just make sure to add the full qualification to class names, such as flash.filters.ColorMatrixFilter.

One of my projects at MakeSweet is to create a simple interface to blender, the 3d graphics and movie maker, that lets people make small videos online. The functions of blender are far too vast and the computational requirements of rendering too exacting for a general-purpose interface to make sense. So we created some simple template .blend files, and let people plug in images or text at strategic points. These modifications are implemented using blender’s python interface. You can access the public version of the interface here.

It turns out that for simple scenes at fairly low resolution, rendering times for stills are short enough to do online (however, we can run into trouble if we are hit by a crowd of users). Rendering actual videos takes tens of minutes, so such jobs get shoved in a queue rather than done online. The queue is processed by a remote rendering farm, running a copy of the .blend customization scripts. The farm sends the results back to the web server, and dispatches an email notification to the user.

There are lots of technical problems to work on still, but actually our main limitation at the moment is artwork; our templates are not terribly exciting! Time to find some decent artists…

Hi everyone, my name is Bozo, I am the resident lizard at makesweet.com. I take care of the murky technologies behind the site. This is my personal blog, to keep track of things I find interesting.