Why is the hard disk drive C on Windows computers?

From a Quora answer.

Windows 10 is Windows NT version 10. Windows NT copied the patterns of MS-DOS, because DOS was the dominant OS when NT was launched in 1993.

DOS copies its disk assignment methods from Digital Research CP/M, because DOS started out as a copy of CP/M.
https://en.wikipedia.org/wiki/CP/M

What Microsoft bought was originally called QDOS, Quick and Dirty OS, from Seattle Computer Products.
https://en.wikipedia.org/wiki/Seattle_Computer_Products

The way IBM PC-compatibles assign disk drives is copied from the way the IBM PC running PC DOS assigned them. PC DOS is IBM’s brand of MS-DOS. See the answer about Apricot computers for how (some) non-IBM-compatible DOS computers assign drive letters.

The way that CP/M and MS-DOS originally assigned drive letters was simple.
The drive you booted from was the first, so it was called A. It doesn’t matter what kind of drive. But floppy drives were expensive and hard drives were very expensive, so in the late 1970s when this stuff was standardized, most machines only had a floppy drive or 2.

If you only had 1 drive, which was common, then the OS called it both A and B. This is so that you could copy files from one disk to another; otherwise there would be no way.

So, you copied from A: to a the virtual drive B: and the OS prompted you to swap disks as necessary.
Floppy drives got cheaper, and it became common to have 2. So, the one you booted from was A, and the second drive was B.

So far, so simple. If you were rich and added more floppy drives, you got A, B, C, D etc. and if you were lucky enough to have good firmware that let you boot from any of them, the one you booted off was A and the rest were simply enumerated.

It is common to read that "certain drive letters are reserved for floppies". This is wrong. Nothing was reserved for anything.

If you had a floppy and a hard disk, then if you booted off the floppy, the floppy drive was A and the hard disk was B. If you booted off the hard disk — and early hard disks were often not bootable — then the hard disk became A and the floppy became B.

You didn't need the virtual drive thing any more; to copy from one floppy to another, you copy from floppy to hard disk, then swap floppies, then copy back.

However, having drives change letter depending on which you booted from was confusing — again, see the Apricot comment — so later firmware started changing this. So, for instance, in the Amstrad PCW range, the last new CP/M computers made, Amstrad hard-wired the drive letters.
https://en.wikipedia.org/wiki/Amstrad_PCW

The first floppy was A. The second, if you had one, was B. And the rest of the machine's RAM aside from the 64 kB that CP/M used was made into a RAMdisk called drive M: "M" for Memory.

The IBM PC hard-wired some letters too. Floppy 1, A. Floppy 2, B, even if not there. Partition 1 on hard disk 1, C. Partition 1 on hard disk 2, D. Partitions 2+ on HD #1, E/F etc. Partitions 2+ on HD #2, G/H etc.

This was very common as up to and including MS-DOS 3.3, DOS only supported partitions of up to 32 MB. So, for instance, in 1989 I installed an IBM PS/2 Model 80 with a 330MB hard disk as a server running the DOS-based 3Com 3+Share NOS.
https://en.wikipedia.org/wiki/3%2BShare

It had hard disk partitions lettered C, D, E, F, G, H, I, J, K, L and M. (!)

DOS has a setting called LASTDRIVE. This tells it how many drive letters to reserve for assignment. Each takes some memory and you only had 640 kB to use, no matter how much was fitted. https://en.wikipedia.org/wiki/Conventional_memory

The default value for LASTDRIVE is E. Thus, the rival Novell Netware OS used the first drive after that as the "network drive" with the login command and so on: F.
https://en.wikipedia.org/wiki/NetWare

So, drive letters are not "reserved". They were originally assigned sequentially starting with the boot drive, and then by hardware ID number, and later by that and partition number, according to a slightly complex scheme that several people have linked to.

It is a convention that A was the first floppy and C was the first hard disk, and everything else was assigned at boot time.

Why progress estimates are difficult

Someone at $JOB said that they really wished that rsync could give a fairly close estimate of how long a given operation would take to complete. I had to jump in...

Be careful what you wish for.

Especially that "close" in there, which is a disastrous request!

AIUI...

It can't do that, because the way it works is comparing files on source and destination block-by-block to work out if they need to be synched or not.

To give an estimate, it would have to do that twice, and thus, its use would be pointless. Rsync is not a clever copy program. Rsync exists to synch 2 files/groups of files without transmitting all the data they contain over a slow link; to do the estimate you ask would obviate its raison d'être.

If it just looked at file sizes, the estimate would be wildly pessimistic, and thus make the tool far less attractive and that would have led to it not being used and becoming a success.

Secondly, by comparison: people clearly asked for this from the Windows developers, and commercial s/w being what it is, they got it.

That's how on Win10 you get a progress bar for all file operations. Which means deleting a 0-byte file takes as long as deleting a 1-gigabyte file: it has to simulate the action first, in order to show the progress, so everything now has a built-in multi-second-long delay (far longer than the actual operation) so it can display a fancy animated progress bar and draw a little graph, and nothing happens instantly, not even the tiniest operations.

Thus a harmless-sounding UI request completely obviated the hard work that went into optimising NTFS, which for instance stores tiny files inside the file system indices so they take no disk sectors at all, meaning less head movement too.

All wasted because of a UI change.

Better to have no estimate than a wildly inaccurate estimate or an estimate that doubles the length of the task.

Yes, some other tools do give a min/max time estimate.

There are indeed far more technically-complex solutions, like...

(I started to do this in pseudocode but I quickly ran out of width, which tells you something)

* start doing the operation, but also time it
* if the time is more than (given interval)
* display a bogus progress indicator, while you work out an estimate
* then start displaying the real progress indicator
* while continuing the operation, which means your estimate is now
inaccurate
* adjust the estimate to improve its accuracy
* until the operation is complete
* show the progress bar hitting the end
* which means you've now added a delay at the end

So you get a progress meter throughout which only shows for longer operations, but it delays the whole job.

This is what Windows Vista did, and it was a pain.

And as we all know, for any such truism, there is an XKCD for it.
https://xkcd.com/612/

That was annoying. So in Win10 someone said "fix it". Result, it now takes a long time to do anything at all, but there's a nice progress bar to look at.

So, yeah, no. If you want a tool that does its job efficiently and as quickly as possible, no, don't try to put a time estimate in it.

Non-time-based, non-proportional time indicators are fine.

E.g. "processed file XXX" which increments, or "processed XXX $units_of_storage"

But they don't tell you how long it will take, and that annoys people. They ask "if you can tell me how much you've done, can't you tell me what fraction of the whole that is?" Well, no, not without doing a potentially big operation before beginning work which makes the whole job bigger.

And the point of rsync is that it speeds up work over slow links.

Summary:

Estimates are hard. Close estimates are very hard. Making the estimate makes the job take much longer (generally, at a MINIMUM twice as long). Poor estimates are very annoying.

So, don't ask for them.

TL;DR Executive summary (which nobody at Microsoft was brave enough to do):

"No."

This was one of those things that for a long time I just assumed everyone knew... then it has become apparent in the last ~dozen years (since Vista) that apparently lots of people didn't know, and indeed, that this lack of knowledge was percolating up the chain.

The time it hit me personally was upgrading a customer's installation of MS Office XP to SR1. This was so big, for the time -- several hundred megabytes, zipped, in 2002 and thus before many people had broadband -- that optionally you could request it on CD.

He did.

The CD contained a self-extracting Zip that extracted into the current directory. So you couldn't run it directly from the CD. It was necessary to copy it to the hard disk, temporarily wasting ¼ GB or so, then run it.

The uncompressed files would have fitted on the CD. That was a warning sign; several people failed in attention to detail and checks.

(Think this doesn't matter? The tutorial for Docker instructs you to install a compiler, then build a copy of MongoDB (IIRC) from source. It leaves the compiler and the sources in the resulting container. This is the exact same sort of lack of attention to detail. Deploying that container would waste a gigabyte or so per instance, and thus waste space, energy, machine time, and cause over-spend on cloud resources.

All because some people just didn't think. They didn't do their job well enough.

So, I copied the self-extractor, I ran it, and I started the installation.

A progress bar slowly crept up to 100%. It took about 5-10 minutes. The client and I watched.

When it got to 100%... it went straight back to zero and started again.

This is my point: progress bars are actually quite difficult.

It did this seven times.

The installation of a service release took about 45 minutes, three-quarters of an hour, plus the 10 minutes wasted because an idiot put a completely unnecessary download-only self-extracting archive onto optical media.

The client paid his bill, but unhappily, because he'd watched me wasting a lot of expensive time because Microsoft was incompetent at:

[1] Packaging a service pack properly.
[2] Putting it onto read-only media properly.
[3] Displaying a progress bar properly.

Of course it would have been much easier and simpler to just distribute a fresh copy of Office, but that would have made piracy easier than this product is proprietary software and one of Microsoft's main revenue-earners, so it's understandable that they didn't want to do that.

But if the installer had just said:

Installation stage x/7:
Progress: [XXXXXXXXXX..........]

That would have been fine. But it didn't. It went from 0 to 100%, seven times over, probably because first the Word team's patch was installed, then the Excel team's patch, then the Powerpoint team's patch, then the Outlook team's patch, then the Access team's patch, then the file import/export filters team's patch, etc. etc.

Poor management. Poor attention to detail. Lack of thought. Lack of planning. Major lack of integration and overview.

But this was just a service release. Those are unplanned; if the apps had been developed and tested better, in a language immune to buffer overflows and which didn't permit pointer arithmetic and so on, it would have have been necessary.

But the Windows Vista copy dialog box, as parodied in XKCD -- that's taking orders from poorly-trained management who don't understand the issues, because someone didn't think it through or explain it, or because someone got promoted to a level they were incompetent for.

https://en.wikipedia.org/wiki/Peter_principle

These are systemic problems. Good high-level management can prevent them. Open communications, where someone junior can point out issues to someone senior without fear of being disciplined or dismissed, can help.

But many companies lack this. I don't know yet if $DAYJOB has sorted these issues. I can confirm from bitter personal experience that my previous FOSS-centric employer suffered badly from them.

Of course, some kind of approximate estimate, or incremental progress indicator for each step, is better than nothing.

Another answer is to concede that the problem is hard, and display a "throbber" instead: show an animated widget that shows something is happening, but not how far along it is. That's what the Microsoft apps team often does now.

Personally, I hate it. It's better than nothing but it conveys no useful information.

Doing an accurate estimator based on integral speed tests is also significantly tricky and can slow down the whole operation. Me personally, I'd prefer an indicator that says "stage 6 of 15, copying file 475 of 13,615."

I may not know which files are big or small, which stages will be quick or slow... but I can see what it's doing, I can make an approximate estimate in my head, and if it's inaccurate, well, I can blame myself and not the developer.

And nobody has to try to work out what percent of an n stage process with o files of p different sizes they're at. That's hard for someone to work out, and it's possible that someone can't tell them a correct number of files or something... so you can get progress bars that go to 87% and then suddenly end, or that go to 106%, or that go to 42% and then sit there for an hour, and then do the rest in 2 seconds.

I'm sure we've all seen all of those. I certainly have.