Microsoft might have been able to make a release 12 days sooner ("patch Tuesday" occurs the 2nd and sometimes 4th Tuesday of the month); they felt the . But, they wanted to insure that the patch didn't cause any bugs and that it would see the widest possible roll-out with minimum amount of grief for IT professionals. In short, they felt that because they had developed a fix for the issue and had concrete roll-out plans that Google would, in good faith, postpone the vulnerability disclosure; which they didn't.

As some background - fixing security vulnerabilities in general can be hard; so much so that when Microsoft adopted a 180 degree policy for it's software partners some called it impractical. Microsoft, it should be noted, is willing to be flexible with that number and work with companies should a good faith effort to fix the issue be made.

In Microsoft's own case security fixes can take a longer then otherwise to implement because of the sheer scope of software permutations compatibility needs to be maintained for. Patches are also rolled out on a set schedule to ensure easier uptake by Enterprise IT departments. Out of band patches to address zero day threats CAN and have been released in the past, but at times they have, themselves caused bugs on certain numbers of machines (which, perversely, can slow uptake of out of band patches)

In this case Microsoft already had a fix prepared, were prepared to roll it out as in in-band security update, and had told Google as much . . . to which Google's response was to release the zero day vulnerability at the 90 day mark. Had Google even told Microsoft that they intended to stick to a "90 day hard limit" after they received Microsoft's plans so that Microsoft could hustle and push and out-of-band patch I'd have more sympathy for them. But' that's not what happened.