Computing desk
< February 26	<< Jan \| February \| Mar >>	February 28 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

February 27[edit]

Disk partitioning options - MBR and (new system) - dual boot problems?[edit]

I remember a couple of years ago, a system designed to replace the MBR system was introduced (by Microsoft, I think), and there was controversy about whether this would create problems when trying to set up a dual boot PC with Linux and Windows. I'm unsure what the new system was called, and I am also unsure of the continuation of the story. Was the system introduced, did it create problems when trying to install Linux on a PC with Windows pre-installed, and have these problems been solved? Do I run a risk of running into trouble when buying a PC today, (say, this one [1]) and setting it up for dual boot? I hope this makes sense, my memory about the issue is a bit sketchy. Thanks. --82.164.37.199 (talk) 00:12, 27 February 2016 (UTC)[reply]

You're probably thinking of UEFI and secure boot (also discussed at Unified Extensible Firmware Interface#Secure boot and Unified Extensible Firmware Interface#Secure boot criticism). So to answer your questions: yes, it was introduced, but I don't know of any instances of it preventing installation of alternative operating systems. There are new concerns about changes Microsoft has made in Windows 10, though (see [2] and [3]). clpo13_(talk) 00:15, 27 February 2016 (UTC)[reply]

Yes, I was thinking about UEFI. I recalled it as UEFA, but the only sensible thing I found when googling various combinations of "MBR" and dual boot problems was GPT, which didn't answer the question. Thanks! --82.164.37.199 (talk) 09:01, 27 February 2016 (UTC)[reply]

Note that the reason is because GPT is replacing MBR. UEFI can boot either MBR partitions or GPT partitions although GPT is generally considered better for various reasons when you are partitioning. Mosts OSes have no problems booting GPT partitions under UEFI, it's only when Secure Boot comes in to play that you may get problems but that it a UEFI issue not a GPT issue. UEFI is replacing BIOS which doesn't really understand GPT partitions.

You can boot GPT partitions under BIOS by including enough of the MBR bootloader stuff. But it's not a config supported by Windows [4]. So you either need to use UEFI with GPT or MBR, or BIOS with MBR only which means you can't use >2 TiB hard disks which present themselves as have 512 byte sectors for booting. Secondary hard disks can of course be GPT, so this likely isn't an issue if for example you have an SSD currently (as they get bigger things may change). There is a hackish solution to allow you to boot GPT partitions on BIOS systems under Windows (you basically present a UEFI to the system) but it's a bit complicated to set up (I've done it before). There were seperate concerns about the closed nature of most UEFI firmware, which while not that different from the way things were with BIOS, some were hoping would change (particularly since UEFI is a lot more complicated than BIOS).

BTW about UEFI, for all the issues relating to Secure Boot, bugs, etc, if you don't have them (e.g. if you built your own computer) it's nice to be able to just copy the OS including UEFI boot stuff to a FAT16/32 formatted USB key and for it to normally just work rather then the situation with BIOS where you have to ensure the bootloader is present and then you can sometimes get weird issues depending on how the BIOS accesses the USB key such that it won't work on certain systems. Likewise the ability to use the mouse under the UEFI is occasionally useful as is the normally more detailed menu options and frequent support for screenshots etc.

As for GPT well beyond >2TiB with 512 byte sectors (and I guess MBR probably could have been modified to spport this), and perhaps not an issue for many, I find it nice that if you do want more than 4 partitions you don't have to mess around with logical ones.

Nil Einne (talk) 12:47, 27 February 2016 (UTC)[reply]

Thanks! I conclude that it's unlikely that setting up the computer I linked to (in Norwegian, sorry) as a dual boot system will be as unproblematic as I'm used to from non-UEFI systems. --82.164.37.199 (talk) 21:01, 27 February 2016 (UTC)[reply]

What does a computer do, when told to divide by zero?[edit]

What would a computer do, when ordered to divide by zero? --Llaanngg (talk) 22:29, 27 February 2016 (UTC)[reply]

See Division by zero#Computer arithmetic. The exact behaviour will depend on the computer and programming language being used. You might get a run-time error, or the expression may return NaN or Infinity. Tevildo (talk) 22:40, 27 February 2016 (UTC)[reply]

Once upon a time, there used to be a much more entertaining answer. When I was a boy, my dad brought me into his workplace one day and showed me an electro-mechanical calculator, which I thought was about the coolest thing ever. For the big finish, he divided something by zero. It went into a mechanical infinite loop, which is much more rewarding to observe than a solid-state one, clacking away and never stopping. --Trovatore (talk) 22:45, 27 February 2016 (UTC) [reply]

I remember the same thing. Bubba73 ^{You talkin' to me?} 22:51, 28 February 2016 (UTC)[reply]

Wow. Wonder what it looks like when you do that on a Babbage machine? Blythwood (talk) 23:23, 27 February 2016 (UTC)[reply]

How does it look like in a Babbage machine?Llaanngg (talk) 00:11, 28 February 2016 (UTC)[reply]

The Difference Engine couldn't do division. On the Analytical Engine, it would depend on how the division algorithm was implemented - Babbage wrote "several processes are gone through in order to ascertain whether it will be necessary to step the dividend up or down, and how many steppings there ought to be of either kind." Presumably these processes would have raised an error by some means if the divisor was zero. Tevildo (talk) 00:45, 28 February 2016 (UTC)[reply]

Apparently, the engine would have signalled division by zero by raising the "Run-Up Lever"~~, the Victorian equivalent of NMI~~. Tevildo (talk) 01:04, 28 February 2016 (UTC)[reply]

Reading up on the subject a bit more, the RUL is the equivalent of the carry flag. Not that this is strictly relevant, but a correction is in order. Tevildo (talk) 21:54, 28 February 2016 (UTC)[reply]

I suspect something like error catching occurs. That is, it looks specifically for the case of dividing by zero, and flags an error, without ever doing the math. StuRat (talk) 23:28, 27 February 2016 (UTC)[reply]

One interesting thing, which is mentioned in the book "Computers in/and Number Theory" or something like that, with runs on a CDC 6400 at the University of California, I think, they had runs that would run for a long time and produce one number as an answer. What they did was after the answer was obtained, they would divide by zero to get the machine to stop and dump the contents of memory to paper, and there they could see the result. I don't know why they did this rather than just telling it to print the answer. Bubba73 ^{You talkin' to me?} 22:51, 28 February 2016 (UTC)[reply]

It can get complicated. In C++, using the GNU compiler under Cywin/Win7 on a regular PC, a floating point division by zero produces the special IEEE floating point value "inf" - and no crash or error message. But (weirdly) an integer divide by zero generates "Floating point exception (core dumped)" - and the program crashes.

Aside from the very odd error message - this is somewhat useful behavior. In most cases, integer divide by zero errors are very definite programming mistakes and shouldn't ever happen. (eg If you wanted to take the average of a set of numbers and there are no numbers in the set - then you might easily divide by zero by mistake).

But floating point divide by zero can happen as a normal part of processing due to roundoff error or other kinds of things that floating point is liable to generate. In that case, error recovery (possibly much later in the calculation) is often desirable.

There are often ways to override the default action - eg by providing a try/catch error handler of your own, or by changing the mode that the floating point unit operates in.

Additionally, different programming languages, different compilers, different operating systems and different CPU/FPU hardware can produce a wild variety of possible outcomes. SteveBaker (talk) 19:18, 29 February 2016 (UTC)[reply]