Hi John & others: (3 separate things.) 1: Image formats Regarding qcow, unfortunately there is no change if I use this format. - Windows 3.1 initially hung at "Starting MS-DOS..."; upon restart it crashed when it decided it couldn't find COMMAND.COM (a frequent failure mode I forgot to mention). - NT initially crashed with one of its famous disk read errors. Of course. - After the initial NT crash, repeated QEMU reloads began showing the boot menu rather consistently, so I pointed my test harness to the qcow image. Of course, it crashed on the first try in the test harness :), then launched successfully 42 times before crashing again. This sort of behavior is pretty consistent with what happened with raw images. I just did 77 runs with commit 306ec6c and the qcow image worked just as well as the raw image did. One thing. I converted my raw disk images to qcow so I could test and reply somewhat more quickly. (Just stumbled on the new activity in the thread after manually checking a couple hours ago, glad I did!. I'm actually subscribed now :) ) It could be strongly argued that I should create _new_ disk images. But my three counter-arguments are that a) the storage format shouldn't influence the guest. b) I exhaustively tested the bisection point I found, and the "before" state is absolutely rock solid. I'd say I've tested 450+ consecutive good runs without any hitches at this point - the 350 runs I documented, and a hundred or so more that I did before that. c) it could be very well argued that QEMU-level errors have left corruption in the disk image. My argument here is to reiterate (b). If anyone wants to strongly argue for creating new images, I can try that. *resigned grumble* Also... is qcow working stably for you, with no issues? If it is I'm very fascinated to hear that. And - you're using `-M isapc`, right? I find that if I don't, NT will hit a STOP error pretty much instantaneously (within the first few fractions of a second after it's obvious the kernel has initialized). --- 2: Bitness The few error messages I saw in your build failure hinted at 64-bit incompatibility. Well... I was able, at length, to get QEMU to build for 32-bit. It mostly boiled down to careful analysis of config-host.mak, removing -m64 and substituting -m32, and poking {C,LD}FLAGS until it compiled. As I noted in the other thread, the built QEMU had a 100% broken TCG and required some form of hardware acceleration to even start correctly. In my case this was KVM. Oh, also, on the subject of compilation - this isn't bitness-related, but QEMU's Makefiles accept the standard `V=2` for verbose build that shows the compilation commands. I'd imagine the result would probably be best attached as a file. I have no idea if this information will be useful to the QEMU developers. --- 3: Bisection I initially thought to cram this info somewhere in the I/O report but decided against it due to that post's final length. But it could be relevant here. Here's the approach I used to rapidly bounce back and forth and in search of the before-and-after "edges". I used this for the I/O issues discussed here and also for another issue (https://bugs.launchpad.net/qemu/+bug/1745316), and if you feel like it, you could use this to track down why the older QEMU versions are not building on OS X. This could be worth it - the fixes could be minimal and a hacky "good enough" backport could be viable, or this may just end up confirming that the breakage was major. I'll just document the exact workflow I used. First, I created a new base directory somewhere, to hold all the subdirs with branches I'd be testing. Next, I switched to the dir with the qemu git checkout, and: $ git rev-list 306ec6c3cece7004429c79c1ac93d49919f1f1cc..master | tac | nl -n ln > /path/to/basedir/branchlist.txt $ Now for the wince part: $ wc -l branchlist.txt 28734 Wooooo! (...not.) [Note: I'm using a fractionally old local clone. That number, and all the numbers below, are likely going to be slightly bigger.] Now, define this function (my interactive sessions use bash, this may work with zsh/others): $ z() { n="$1"; b="$(grep "^$n[^0-9]" /path/to/basedir/branchlist.txt | cut -d$'\t' -f2)"; sb="${b:0:7}"; d="/path/to/basedir/$n-$sb/"; mkdir "$d"; git archive "$b" | tar xC "$d"; } Now, you can just do something like $ z 14367 and then, in a separate terminal, you can cd over to the newly-created /path/to/basedir/14367-1bfa316/, and configure and build it. The function just lets you refer to the commits by number as you work, which makes it much easier (indeed, possible at all) to select which commit to build, and also keep track of where you're up to. NOTE: The `tac` in the line that generated branchlist.txt means that commit 1 will be older than commit 28734. Smaller numbers go back in time, which makes sense to me. For opposite behavior remove the `tac`. The number in the `z` line above is 28734/2, ie, this jumps straight into the middle of the list. (Of (obvious) note is that the generated list does not represent _all_ the commits.) If that commit fails to build, you might jump back by half, eg 7184. If that one works, you might jump forward by half, or 21550. It's kind of meditative... but it does get irritating toward the end when you're jumping forward by 30... then back by 7... then forward by 3... (like an annoying padlock!) (I can strongly recommend keeping notes of which builds worked and which didn't. I totally didn't jump in the wrong direction a few times...) If you're so inclined, you could probably wrap all of this into a bit of automation. `make`'s return code is admittedly much much easier to script off of than hooking up a test harness to do a bunch of automated runs and deciding for itself whether it produced a fail or pass. Or (in the case of the other bug I found), testing mouse movements. For these reasons it was much easier for me to use this workflow manually. Even with a starting list of nearly 30k commits, this works exponentially at best, and better-than-exponentially if you decide to arbitrarily jump back or forward by more than half. So while this isn't a 10-minute job, it _shouldn't_ take all day, either.