{"id":7633,"date":"2012-05-14T07:00:00","date_gmt":"2012-05-14T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2012\/05\/14\/what-is-the-historical-reason-for-muldiv1-0x80000000-0x80000000-returning-2\/"},"modified":"2012-05-14T07:00:00","modified_gmt":"2012-05-14T07:00:00","slug":"what-is-the-historical-reason-for-muldiv1-0x80000000-0x80000000-returning-2","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20120514-00\/?p=7633","title":{"rendered":"What is the historical reason for MulDiv(1, -0x80000000, -0x80000000) returning 2?"},"content":{"rendered":"

\nCommenter rs asks,\n“Why does Windows (historically) return 2 for\nMulDiv(1, -0x80000000, -0x80000000)<\/code> while Wine returns zero?<\/a>”\n<\/p>\n

\nThe MulDiv<\/code> function multiplies the first two parameters\nand divides by the third. Therefore, the mathematically correct\nanswer for\nMulDiv(1, -0x80000000,\n-0x80000000)<\/code> is 1,\nbecause\na<\/i> ×\nb<\/i> ÷\nb<\/i> = a<\/i> for all nonzero b<\/i>.\n<\/p>\n

\nSo both Windows and Wine get it wrong.\nI don’t know why Wine gets it wrong, but I dug through the\narchives to figure out what happened to Windows.\n<\/p>\n

\nFirst, some background.\nWhat’s the point of the MulDiv<\/code> function anyway?\n<\/p>\n

\nBack in the days of 16-bit Windows,\nfloating point was very expensive.\nMost people did not have math coprocessors,\nso floating point was performed via software emulation.\nAnd the software emulation was slow.\nFirst, you issued a floating point operation on the assumption\nthat you had a float point coprocessor.\nIf you didn’t, then a coprocessor not available<\/i>\nexception was raised.\nThis exception handler had a lot of work to do.\n<\/p>\n

\nIt decoded the instruction that caused\nthe exception and then emulated the operation.\nFor example, if the bytes at the point of the exception were\nd9 45 08<\/code>, the exception handler would have to\nfigure out that the instruction was fld dword ptr ds:[di][8]<\/code>.\nIt then had to simulate the operation of that instruction.\nIn this case, it would\nretrieve the caller’s di<\/code> register,\nadd 8 to that value,\nload four bytes from that address\n(relative to the caller’s ds<\/code> register),\nexpand them from 32-bit floating point to 80-bit floating point,\nand push them onto a pretend floating point stack.\nThen it advanced the instruction pointer three bytes and\nresumed execution.\n<\/p>\n

\nThis took an instruction that with a coprocessor would take\naround 40 cycles (already slow) and ballooned its total execution\ntime to a few hundred, probably thousand cycles.\n(I didn’t bother counting. Those who are offended by this\nhorrific laziness on my part can apply for a refund.)\n<\/p>\n

\nIt was in this sort of floating point-hostile environment that\nWindows was originally developed.\nAs a result,\nWindows has historically avoided using floating point and preferred\nto use integers.\nAnd one of the things you often have to do with integers is\nscale them by some ratio.\nFor example, a horizontal dialog unit is ¼ of the average\ncharacter width, and a vertical dialog unit is 1\/8 of the average\ncharacter height.\nIf you have a value of, say, 15 horizontal dlu, the corresponding\nnumber of pixels is\n15 × average character width ÷ 4.\nThis multiply-then-divide operation is quite common, and that’s\nthe model that the MulDiv<\/code> function is designed to\nhelp out with.\n<\/p>\n

\nIn particular, MulDiv<\/code> took care of three\nthings that a simple\na<\/i> ×\nb<\/i> ÷\nc<\/i> didn’t.\n(And remember, we’re in 16-bit Windows, so a<\/i>,\nb<\/i> and c<\/i> are all 16-bit signed values.)\n<\/p>\n