So looking through the codebases for gtkglarea and gtkglext the contrast in approaches is pretty stark:

gtkglext gtkglarea
large codebase small code
separates platform specific code ifdefs everywhere
dead maintained for the moment

For my purposes, I think I’m best to port back to gtkglarea. It is maintained for now (not to slight the current maintainers, just we’ve been through this dance before).

update:

I’ve done the port.  Since kludge3d used gtkglarea in the past it wasn’t really that hard. So for now I’d say unless you need gtkglext’s extra features, use gtkglarea.

DSC_0345

Once upon a time, kludge3d (and g3d before it) implemented OpenGL rendering via gtkglarea. gtkglarea (developed by J. Löf and originally hosted at http://www.student.oulu.fi/~jlof/gtkglarea/ – now a dead site) it provided a gtkdrawingarea like widget. Then some time goes by and gtkglarea seems to have gone unmaintained.

In the meantime, gtkglext had come into existence. So by the kludge3d 2003-07-18 release, gtkglext was the display option of choice. gtkglext offered the possibility of placing an OpenGL view onto any GTK+ widget. (Though I’ve never been convinced that you need to do that very often).

So then in 2008, I get my first Vista based laptop. At work, I’ve been internally maintaining a version of kludge3d for many years. I was disappointed that kludge3d only worked properly with desktop compositing turned off. It is not the end of the world sure, but it looks bad, and anyway, it should be fixable right? A quick look at the gtkglext source made it clear I didn’t really have the understanding of how gdk actually does anything on win32. With deadlines looming and the fact that my users were all on XP, I shelved further investigation.

Fastforward to now. Vista or Windows7 is in our corporate future. So while trawling the gtkglext mailing lists I see a post from Mike Farrell. He suggested enabling PFD_SUPPORT_COMPOSITION based on the information at OpenGL.org. Unfortunately the suggested patch didn’t work for me, but did get me digging into the gtkglext source code again. I worked out some of the path from GTK to the screen. gtkglext looks like it is violating the assumptions that DWM has about GDI and the OpenGL context.

Enter a new gtkglarea. (http://www.mono-project.com/GtkGLArea). It looks like it is being maintained again. And hey, it builds properly on windows with mingw out of the box. And better yet, all of the examples run properly with desktop compositing enabled. Woohoo.

So now the question is:

  • fix gtkglext
  • port kludge3d back to gtkglarea?
2003-07-18
qemu is enough to run tinycore without acceleration, but more is better right?

Get the source: kqemu-1.4.0pre1.tar.gz

$ tar zxf ../Downloads/kqemu-1.4.0pre1.tar.gz
$ cd kqemu-1.4.0.pre1

Edit Makefile.winnt, change

CROSS_PREFIX=i386-mingw32-

to

CROSS_PREFIX=

then apply the patch from here:

$ patch -p0 ../../Downloads/kqemu-mingw.diff
patching file `common/Makefile'
patching file `common/genmon.c'
patching file `common/i386/monitor-win32.ld'
patching file `common/i386/monitor_asm.S'
patching file `common/i386/nexus_asm.S'
patching file `common/kqemu_int.h'
Hunk #1 succeeded at 1057 (offset -6 lines).
patching file `common/x86_64/monitor-win32.ld'
patching file `common/x86_64/monitor_asm.S'
$ make -f Makefile.winnt
$ cp kqemu.sys kqemu.inf /c/apps/qemu-0.10.5

Now you need to do some surgery on kqemu.sys. Using the guide from here.

  • [DefaultInstall.NT] –> [DefaultInstall]
  • [DefaultInstall.NT.Services] –> [DefaultInstall.Services]
  • [Uninstall.NT] –> [Uninstall]
  • [Uninstall.NT.Services] –> [Uninstall.Services]

Then right click on kqemu.inf -> install

Hand over UAC permission, then start an Administrator command shell, cd to the installation directory and:

c:\apps\qemu-0.10.5>net start kqemu

The KQEMU virtualisation module for QEMU service was started successfully.

Now when you start qemu, it goes faster! yay.

$ qemu -cdrom /c/Users/dpinson/Downloads/tinycore_2.2.iso -hda tinycore.img -m256 -boot d
I’ve played with qemu on and off for as long as I can remember (and I remember struggling with Bochs on DEC OSF/1). These days life is Vista orientated for work reasons and by and by I’ve ended up with win32 as my main development environment, even when I work on GTK+ code (the beauty of cross platform libraries I guess).

Nowadays we are blessed with lots of good virtualisation software (VirtualPC, VMWare, VirtualBox). While I have a regular rotation of VirtualBox setups, I thought I could see how well qemu was going, but it seems that the win32 binaries are a bit on the stale side (0.9.0 vs 0.10.6). So lets try to build it under mingw/msys….

Preliminaries

Download and install zlib.

$ tar zxf ../Downloads/zlib-1.2.3.tar.gz
$ cd zlib-1.2.3
$ make -f win32/Makefile.gcc
$ cp zlib.h zconf.h /usr/include
$ cp libz.a /usr/lib

Download and install SDL

$ tar zxf ../Downloads/SDL-1.2.13.tar.gz
$ cd SDL-1.2.13
$ ./configure --prefix=/usr
$ make

Which only gets to:

windres ./src/main/win32/version.rc build/version.o
/bin/sh ./libtool --mode=link gcc -o build/libSDL.la build/SDL.lo build/SDL_error.lo build/SDL_fatal.lo build/SDL_audio.lo build/SDL_audiocvt.lo build/SDL_audiodev.lo build/SDL_mixer.lo build/SDL_mixer_MMX.lo build/SDL_mixer_MMX_VC.lo build/SDL_mixer_m68k.lo build/SDL_wave.lo build/SDL_cdrom.lo build/SDL_cpuinfo.lo build/SDL_active.lo build/SDL_events.lo build/SDL_expose.lo build/SDL_keyboard.lo build/SDL_mouse.lo build/SDL_quit.lo build/SDL_resize.lo build/SDL_rwops.lo build/SDL_getenv.lo build/SDL_iconv.lo build/SDL_malloc.lo build/SDL_qsort.lo build/SDL_stdlib.lo build/SDL_string.lo build/SDL_thread.lo build/SDL_timer.lo build/SDL_RLEaccel.lo build/SDL_blit.lo build/SDL_blit_0.lo build/SDL_blit_1.lo build/SDL_blit_A.lo build/SDL_blit_N.lo build/SDL_bmp.lo build/SDL_cursor.lo build/SDL_gamma.lo build/SDL_pixels.lo build/SDL_stretch.lo build/SDL_surface.lo build/SDL_video.lo build/SDL_yuv.lo build/SDL_yuv_mmx.lo build/SDL_yuv_sw.lo build/SDL_joystick.lo build/SDL_nullevents.lo build/SDL_nullmouse.lo build/SDL_nullvideo.lo build/SDL_diskaudio.lo build/SDL_dummyaudio.lo build/SDL_sysevents.lo build/SDL_sysmouse.lo build/SDL_syswm.lo build/SDL_wingl.lo build/SDL_dibevents.lo build/SDL_dibvideo.lo build/SDL_dibaudio.lo build/SDL_mmjoystick.lo build/SDL_syscdrom.lo build/SDL_sysmutex.lo build/SDL_syssem.lo build/SDL_systhread.lo build/SDL_syscond.lo build/SDL_systimer.lo build/SDL_sysloadso.lo build/version.o  -lm -luser32 -lgdi32 -lwinmm -no-undefined -rpath /usr/lib -release 1.2 -version-info 11:2:11
libtool: link: cannot build libtool library `build/libSDL.la' from non-libtool objects on this host: build/version.o
make: *** [build/libSDL.la] Error 1

Then we need to use the magic pointed to here:

$ ./libtool --tag=RC --mode=compile windres src/main/win32/version.rc -o build/version.o
then edit Makefile and change “$(objects)/version.o” to “$(objects)/version.lo”

and finally we can do:

$ make
$ make install

Now for qemu

$ tar zxf ../Downloads/qemu-0.10.5.tar.gz
$ cd qemu-0.10.5
$ ./configure --prefix=/c/apps/qemu-0.10.5 --disable-kvm
Error: zlib check failed
Make sure to have the zlib libs and headers installed.

I couldn’t resolve this in a nice way… I just edited the configure file to add OS_FLAGS to the MINGW32 section:

MINGW32*)
OS_CFLAGS="-I/usr/include -L/usr/lib"
mingw32="yes"
if [ "$cpu" = "i386" ] ; then
    kqemu="yes"
fi

Then

$ ./configure --prefix=/c/apps/qemu-0.10.5 --disable-kvm
$ make
...
c:/apps/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: cannot find -lz
collect2: ld returned 1 exit status
make: *** [qemu-img.exe] Error 1

It seems that zlib still isn’t found. So to be expedient, add it to the Makefile:

change

LDFLAGS += $(OS_LDFLAGS) $(ARCH_LDFLAGS)

to

LDFLAGS += $(OS_LDFLAGS) $(ARCH_LDFLAGS) -L/usr/lib

and we are away…

$ make
$ make install

Almost there…

$ ./qemu-img.exe create -f qcow2 tinycore.img 1G
Formatting ‘tinycore.img’, fmt=qcow2, size=1048576 kB

$ qemu -cdrom /c/Users/dpinson/Downloads/tinycore_2.2.iso -hda tinycore.img -m 256 -boot d
Could not open ‘\\.\kqemu’ – QEMU acceleration layer not activated: 2

Next time we will build kqemu.