mikehearn is currently certified at Journeyer level.

Name: Mike Hearn
Member since: 2003-07-24 13:47:58
Last Login: 2006-12-13 23:34:34

FOAF RDF Share This

Homepage: http://theoretic.com/Mike


I work on Wine, and am the project leader of autopackage, which is putting together a spiffy framework for writing installers. I hope I can edit this page later, because right now I'm just killing a few minutes waiting for a compile, and should be getting back to work :)


Articles Posted by mikehearn

  • email2 22 Aug 2003 at 13:10 UTC

Recent blog entries by mikehearn

Syndication: RSS 2.0

Ah, life is good.

On Friday, me and some friends went to see John Digweed play at one of the local student club nights, and we partied early into the morning. Cat was well up for it as usual. It took him a while to get into his stride, which was strange given that he's been on Radio 1 and is pretty famous. By the end we were all having a great time - the laser show was fantastic, but it's a strange thing that both times I've seen professional big-name DJs play (Goldie was the first) they've been ... well ... not great. At least Digweed didn't clear the floor like Goldie did :)

Labyrinth is a very strange film. Watching it made me glad that I spent most of the 80s blissfully unaware of Hollywood culture. Its strangeness doubles when you watch it at 2:30 in the morning (yawn)

autopackage 0.5 is finally done. Once again I'm amazed at how much we've packed in. Even though I say so myself, we've put together one of the slickest installers I've ever seen - we've paid attention to the user experience right from the start and the results are impressive. It's certainly not perfect, and it's still some way from my long term goal of drag/drop "invisible" installs, but we're getting closer every day. In terms of UI it definitely beats the snot out of InstallShield (not hard) but also gives a more pleasant experience than even rather slick programs like Synaptic or redhat-install-packages.

One of the reasons that installing stuff on Linux can be such a pain in the ass is that programs have so many dependencies. Often, these dependencies aren't strictly required but because using dlopen/dlsym is so awkward it's simpler just to whack in an autoconf check and leave it at that. Good for Gentoo users, not so great for everybody else.

One solution is a program that I have been meaning to develop for a while and today actually did. relaytool lets you replace a link like -lgtkspell with a generated source file, libgtkspell.stub.c which uses assembly and GNU C magic to transparently relay the calls to either the real function or an error handler in case you accidentally call a missing function. This lets you also link against a library but not have hard dependencies on its latest features: for instance you can write a program that depends on GTK 2.0 but can still use features from 2.2 and 2.4 easily.

relaytool has some other interesting applications as well. For instance you can solve the problem with ELF symbol scoping with it, though it's certainly not the solution.

Finally, CrossOver 3 is coming out in only a couple of days. I came in part way through this effort, but still feel proud at what we've been able to do (while all along supporting the free software community).

Having to set my proxy server in about a zillion different places annoys me far more than it probably should. Currently I have to set the environment variables, GNOME, Gaim, the Red Hat Network updater, and Wine.

This stuff should be trivial to get right, but it's not. Hmm.

autopackage has really picked up nicely lately. It's feeling very solid, polished, and generally kickass. Apollon and Inkscape have both been keen to work with us and support beta packages, so hopefully we'll have some good install-fu going on there soon.

Life has just been up and down like a yo-yo lately. Right now I'm feeling very tired, and am once again wondering if there isn't something very fundamental and important that I'm somehow missing about living.

It'll come ...

I should blog here more often really. Does anybody actually read or care about what we write here though? I don't know.


I work part-time for CodeWeavers now. This is such an incredibly cool company, I don't know where to begin :) They pay me to hack Wine. I'm happy because I get some money to help me through university, they're happy because I don't spend all my time doing autopackage and because they get to choose what I hack on. We've got some exciting projects coming up, too bad I can't talk about them.

Unfortunately, prelink and exec-shield still break the snot out of us. I've developed 2 working prototypes for fixes now, but unfortunately the best of the two is blocked on a kernel bug. It's been reported to lkml but I'm not expecting a fix anytime soon and I don't have the time nor skills to do it myself. Probably we will just go with the original mechanism I developed on the way to and from WineConf 2004. It's 300+ lines of code and will give Wine a 3 stage init process, but it seems all our other options have been exhausted :(


We released 0.4, finally. The network retrieval code still needs some work, in particular with error handling which we don't really do at all currently. The next release (0.5) was supposed to just be focussing on documentation and demo packages, but to be honest we're going to have to do some serious hacking as well. We've discovered yet another binary portability problem as well. There's an automatic solution but it's not trivial. Looks 0.5 is going to be some time off as well.

On the upside, everybody has said it's really impressed them so far, and an old friend of mine who is also doing compsci is getting into Linux. He is thinking of working on autopackage for his 3rd year project, as apparently that's allowed. So maybe more manpower is coming soon!

I've also started putting some more thought into what comes after autopackage. There's always been something of a grand plan, but it might be time to start executing "stage 2". Daniel Stones work on the freedesktop.org platform is important, but I've got a lot of ideas on how it could be done differently.

Me and ChipX86 have also started laying the foundations for the next-gen packaging UI we're toying with.

One thing that me and Chip have repeatedly thought is that it's a very exciting time to be involved with Linux. There's so much cool stuff going on. We're on the last leg of the race to catch up with the competition, and once we've caught up - then... then is when we will start to see real innovation. There's so much stuff you can do when you have the source to everything, the possibilities are endless :)

8 Jan 2004 (updated 8 Jan 2004 at 18:36 UTC) »

Ah, my first diary entry of the new year. I haven't posted much lately, it seemed I never had much to say.

Christmas was pretty average but new years eve was fun - all my old friends got together and we all had a big house party. There must have been 25-30 people there (ok, so not that big).

I've been pretty busy with Wine and autopackage related stuff lately. In particular, I got tired of people asking how to install Internet Explorer on #winehq, so I wrote a script to do it for you. It was posted to Wine Weekly News, frankscorner.org and linux-gamers.net CounterStrike howto, so it's been getting a steady ~250 downloads a day since then. As you can imagine, my inbox has been groaning.

For those who want it btw, you can get it here

One thing that really annoys me is how like half the script is to work around stupid packaging bugs. Some of them are really, really stupid - ie wine won't even start at all on an out-of-the-box install. Have these people done any QA whatsoever? Clearly not.

That's one category of problems (obvious and stupid brokenness). The other category is when packagers try and "improve" upon the install sequence we use in the source tarballs. For instance, they decide that because the wineserver has the word "server" in its name, it'd be a good idea to put it into the init scripts. Unfortunately this stops changes to the config file taking effect, as they are loaded in wineserver startup. Etc. This sort of thing goes on and on.

The problem is clearly that packagers for distros are typically not Wine developers, they are users. Therefore they make mistakes, even though we have a dedicated packaging guide (it seems people don't always read this).

There are two possible solutions.

The first is pretty obvious - winehq should ship one officially blessed package that works anywhere. If people want to use distro-specific packages built by who-knows-whom then great but if it breaks you keep the pieces. Unfortunately, short of rolling something with Loki Setup a la codeweavers, we currently can't do that well. This is exactly the sort of thing autopackage is built for of course, but I might make a Loki Setup installer in the meantime anyway.

The second is that every distro package should be done by a developer. We have this for Red Hat, and it works pretty well. The RH/Fedora packages generally work well. But for most distros, we don't have this. It's clearly not a reliable solution.

So it seems my two entirely separate projects are intertwined in some way ... interesting :)

I'm starting to regret taking on this Wine porting work. The app basically works fine, as far as I can tell (though printing is proving problematic) but it is riddled with small yet annoying buglets. For instance, if you correct a spelling mistake in an editor, the context menu pops up shortly afterwards. Why? Because the application itself pokes the richedit control with a WM_RBUTTONUP message. Inscrutable.

Win32 has a very useful ability, namely an operating system level understanding of exceptions. It's called SEH, for "structured exception handling", and is what I feel like discussing at the moment. Linux has no such equivalent. Let's examine what happens when a thread faults on Windows and Linux, and see what we can learn from the other side.

Typically exceptions are handled by the language runtime in use, however moving this functionality down into lower level shared code has some significant advantages.

Let's pretend that a thread in my application dereferences a null pointer. This is invalid, as typically the lower regions of memory are protected, and therefore a page fault/access violation/segmentation fault will occur.

In Win32, what happens is as follows. The CPU delivers an interrupt which is handled by kernel mode code. The interrupt vector dispatches control to the KiUserExceptionDispatcher function, which begins the process of SEH invocation. Win32 SEH frames are stored on the stack, with a thread-local linked list pointing to each different frame in turn (the list is actually stored in the TEB). The SEH frames define things like a callback to be executed, which is passed a structure describing the nature of the exception. An exception type is identified by an unsigned int, and looks like (for an access violation) 0xc0000005.

As the stack is unwound, the callbacks are called twice. The first is to figure out how to handle the exception, and the second time is as the stack is unwound, giving implementors the ability to have "finally" type functionality. Eventually, even if the application has itself registered no handlers, control reaches an exception handler put in place by the operating system loader code. This calls the default handler code (UnhandledExceptionFilter) which on Windows calls some debugging hooks before finally displaying the famous "This application has performed an illegal operation" dialog box. Visual C++ exceptions are partly implemented on top of SEH, however SEH is not rich enough to fully support C++s needs, so there are limitations in interoperability. In particular C code cannot trap C++ exceptions.

Linux as an OS imposes no particular exception handling system on programs, in fact, it's not even aware of exceptions. Typically a signal delivered to an app will be handled and exception handling machinery built into the binary by the compiler will be invoked.

That works OK, but has a few problems. Firstly, it's not possible to throw C++ (or Python, or Java, or .NET etc) exceptions across C libraries. Even though you can compile C code with -fexceptions, typical programs are not expecting the stack to be unwound underneath them and so internal state can be corrupted by doing so. Even if people wanted to write exception-aware C code, there is no C API or ABI for doing it. There's no way to robustly translate exceptions from one environment to another - for instance, C++ exceptions thrown in a library used from Python would probably go badly wrong.

One possible solution is to have a third party library (or maybe a new part of glib) provide an explicit API for exception handling in C, similar to SEH. If rich enough, the most common error handling systems could be mapped to it, bringing us a little bit close to having interoperating code modules. It would also lead to the ability to catch up to Windows in some aspects - for instance, a unified crash handler window. Doing this properly would probably require co-operation from the libc and gcc maintainers however.

17 older entries...


mikehearn certified others as follows:

  • mikehearn certified Uraeus as Journeyer
  • mikehearn certified mikehearn as Journeyer
  • mikehearn certified bbrox as Master
  • mikehearn certified sun as Journeyer
  • mikehearn certified Marcus as Master
  • mikehearn certified chipx86 as Journeyer
  • mikehearn certified davidtrowbridge as Master
  • mikehearn certified stillflame as Journeyer
  • mikehearn certified Spooky as Journeyer

Others have certified mikehearn as follows:

  • mikehearn certified mikehearn as Journeyer
  • salmoni certified mikehearn as Journeyer
  • lerdsuwa certified mikehearn as Journeyer
  • Marcus certified mikehearn as Journeyer
  • chipx86 certified mikehearn as Journeyer
  • ebf certified mikehearn as Journeyer
  • Uraeus certified mikehearn as Journeyer
  • fxn certified mikehearn as Journeyer
  • stillflame certified mikehearn as Journeyer
  • Zaitcev certified mikehearn as Journeyer
  • gobry certified mikehearn as Journeyer
  • connolly certified mikehearn as Journeyer
  • mikem certified mikehearn as Journeyer
  • mathrick certified mikehearn as Master
  • ctrlsoft certified mikehearn as Journeyer
  • numist certified mikehearn as Journeyer

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page