Is it because the operating system is written in the C programming language?
I think that the A and B languages were not so successful?
I am thirteen and trying to do computer programming in C#.
Wikipedia gives a good explanation about the logic of drive lettering:
Except for CP/M and early versions of MS-DOS, the operating systems assigns drive letters according to the following algorithm:
Assign the drive letter A: to the first floppy disk drive (drive 0), and B: to the second floppy disk drive (drive 1), if present.
Assign a drive letter, beginning with C: to the first active primary partition recognised upon the first physical hard disk.
Assign subsequent drive letters to the first primary partition upon each successive physical hard disk drive, if present within the system.
Assign subsequent drive letters to every recognised logical partition, beginning with the first hard drive and proceeding through successive physical hard disk drives, if present within the system.
Assign subsequent drive letters to any RAM Disk.
Assign subsequent drive letters to any additional floppy or optical disc drives.
It's a left over from the original PC designs.
Originally PCs only had up to 2 floppy disk drives labelled A and B.
Some time later hard disks got added and became drive C.
The hard disk letter is C because historically, drives A and B were for floppy disks. It has nothing to do with the language in which the operating system is written.
Ah, floppy disks, remember those?
You could spend a whole afternoon coding your latest killer app, then find that you couldn't save it because it was too big to fit on a 5.25" single density disk.
That was when floppies really were floppy. Thin and flimsy, usually in either 5.25" or 8" sizes, though the first internal drives that appeared in PCs were 5.25". As previously mentioned, the early versions of MS Dos used to automatically assign drive A: to the first floppy drive and B: to the second. Hard drives didn't even fit into PCs back then. You could buy a 5mb Winchester Hard Disk that weighed about 30Kg and came in a big external cabinet nearly the size of a modern mini tower pc.
If your PC had twin floppies you could type a command something like "copy a: b:" to copy the contents of drive A: to drive B:
But then that was all back in a time when Bill Gates was worth about $10,000!
Its because A and B used to be floppy drives back in the days when floppy drives were the norm and there were no hard-disks. The letter C was given to any hard disk that the user installed. The drives A and B have since then been reserved for floppy drives. This has nothing to do with programming languages.
The origins of drive letters
*But why the letter "C"? Why not "A" or "B"? Why not "Z?"*
Unsurprisingly, the answer lies in Microsoft's old DOS roots. Long before Windows existed, most PC-compatible computer systems had only one disk drive in it - a floppy disk drive. At the time, users would insert their DOS floppy disk into the computer just before they turned it on, and the computer would start, or "boot up" via the software on the floppy.
As the first and often only disk drive installed in the computer, the floppy disk was assigned the first letter of the alphabet.
While floppy drives were attached to drive 0 and 1 (A and B), nowadays, memory card and SD cards are like any other drive (hard-drives, CD-ROM readers, ...), and simply take any drive letter after C.
A and B are kept for backward compatibility reason.
To better illustrate how (finally, Q1 2014) floppy drives are fading away, consider the new Eclipse icons:
Lars Vogel just referenced this Stack Overflow question in his article "Eclipse org.eclipse.ui switches to png files and waves good bye to the floppy disk".
It illustrates that the next Eclipse Luna 4.4 will no longer show floppy disk, but rather icons which look "now a bit like a SD card".
They are designed by https://twitter.com/enleeten from http://www.l33tlabs.com/, using png file in order to:
support transparency and therefore also look good on a dark theme (background).
I find the difference subtle though:
After:
Before (old icons):
This was recorded in bug 422175:
Someone mentioned on twitter how the traditional save "floppy" idiom is somewhat anachronistic these days. So while working on the eclipse icons, we've created a new version of the save icon.
The new icon keeps the profile of the floppy icon but replaces the diskette sliding door with some electrical contacts, effectively turning the icon into a memory card. This ensures that the icon is recognized by most users as "save" while still being representative of modern storage media.
I've attached an image for comparison.
The first row is the current icon,
the second row was a more extreme change (making it look like an SD card) and
the third row is the icon we're proposing in this bug.
On computers running Windows or MS-DOS, the hard drive is labelled with the drive letter C, because it is the first available drive letter for hard drives. The computer reserves the A: and B: drive letters for the floppy disk drive and removable media, such as tape drives, even if none of these devices are installed in the computer. As you install other drives and create new partitions, they will be assigned to other drive letters after C, such as D, E, F, G, etc.
Source
Think DOS was working from floppy drive, and windows built on DOS continued the same drive letter convention ...
On computers running Windows or MS-DOS, the hard drive is labeled with the C: drive letter. The reason is because it is the first available drive letter for hard drives. The computer reserves A: and B: drive letters for the floppy disk drive and removable media, such as tape drives, even if these devices are not installed in the computer. As you install other drives and create new partitions, they are assigned to other drive letters after C, such as D, E, F, G, etc.
I'd say that it's because the A: and B: drives were traditionally floppy drives and early computers required you to boot using a bootable floppy disk.
I strongly doubt if the lettering has anything to do with programming languages.
I think it's a kind of legacy from old versions of Microsoft Operating Systems where letters A and B were assigned to floppy drives.
Related
On a computer there are Disk 0, Disk 1,... (as we see in Computer management). These (physical) disks may have partitions or not, mounted or not and so on. I want to know if a Disk with a specific number exists on that computer (no matter what is on that disk).
This function has to work fine on any computer with Windows >= XP and it has to be as fast as possible (less than 1 second).
A simple enumeration 'A'..'Z' with GetDriveType and DeviceIoControl(...IOCTL_STORAGE_GET_DEVICE_NUMBER..)/DiskSize/DiskFree doesn't help if the disk doesn't have mounted volumes.
I'm using Delphi 7.
Use CreateFile() to open "\\.\PhysicalDriveX" as the filename, where X is the desired number, and see if it succeeds or fails. Even if it fails, you can still check if the error is due to the device not being present versus not being accessible (which implies that it exists).
You can use WMI
The query like
select * FROM Win32_DiskDrive
get you the base information
I am testing the speed of the drives on the Windows Azure VM's Drives. It seems to me like the speed difference between the temporary drive d and the attached drives is huge!
The test I have is running iometer program on
Maximum Disk Size 20 Gigs
16 Outstanding I/O's
4k100% read, 0% random
60seconds Run time
Results:
Temporary Drive D: Total I/Os per second 60978.94
Drive E (1 30 gig drive): 910.51
Drive F (4 30 gig drives striped together): 899.6
Is this normal?
The reason I am really noticing the difference is in SQL. I basically tried to migrate from my old physical server with sql2000 2 gigs of ram and scsi drives, and that thing is faster than windows azure large image. Faster in that I can run queries about twice as fast.
I turned off diskcaching on os drive in os.
Can someone explain to me what is going on? am I comparing apples to oranges? thanks!
Yes this is normal. The temp disk is a physical disk on the node (only disk I/O here), and the E/F/... disks are persisted disks. This means they are actually page blobs in blob storage and you'll need to take into account network I/O as well.
To improve I/O and throughput you might consider to disable the cache for those disks (this incurs more transaction costs). Read more about this on the Windows Azure Storage Blog: Exploring Windows Azure Drives, Disks, and Images
I want to parallelize some disk I/O, but this will hurt performance badly if my files are on the same disk.
Note that there may be various filter drivers in between the drivers and the actual disk -- e.g. two files might be on different virtual disks (VHDs), but on the same physical disk.
How do I detect if two HANDLEs refer to files (or partitions, or whatever) on the same physical disk?
If this is not possible -- what is the next-best/closest alternative?
This is rather convoluted, but the first step is getting the volume name from the handle. You can do that on Vista or above using the GetFinalPathNameByHandle function. If you need to support earlier Windows versions, you can use this example.
Now that you have the file name, you can parse out the drive letter or volume name, and use the method explained in the accepted answer to this question.
As compilation is mostly reading small files, I wonder if buying a fast usb key to work on can speed up compilation time compared to a standard SATA drive, and with a lower price than an SSD drive (16Gb keys are < 30$).
Am I right ?
PS: I working with .Net, VS and the whole MS' tools, but I think this is true for all languages...
[Edit] According Toms's hardware, a recent hdd drive read access time is near 14ms average where the slowest USB key is 1.5ms
That's why I'm wondering if my hypothesis is right
One year later, SSD drives cost has melt.
This is now the simplest solution, as you can host the operating system and all the dev tools on a fast SSD drive, which costs less than $ 120 (100 €)
The specifications on Wikipedias SATA page suggest otherwise. The SATA revision 3.0 is 50% faster than USB 3.0 according to the spec.
Does anyone know when calling 'seek' and 'read' , how is the hard-drive physicly affected?
If i'll be more specific, I know that the harddrive has some kind of a magnetic needle that is used to read the data from the magnetic plates. So my question is , when is the needle actualy moved to the reading location?
Is it moved when we are calling the "seek" windowsApi method (no matter if an actual read performed) , or does "seek" just remember a virtual pointer , and the physical movement of the needle is performed only when the "read" method is called?
Edit: Assume that the data requested from the Hard-Drive doesn't exist in any of the caches (hard-drive cache , Os Cache , Ram and whatever else it could be)
Wanted to break out this question from your post
When is the needle actualy moved to the reading location?
I think the simple answer is "whenever data is requested that is not already present in any number of caches". The problem with predicting hard drive movement is you have to consider all of the different places that cache data read from the hard drive. If the data is present in those caches and accessible in the context requesting the data, the cache will be used instead of actually reading the hard drive. Here are just some of the places that can and do cache hard drive data
Hard Drive's internal cache
OS level caches
Program level caches
API level cache
In the case where none of the data is present then it will likely be read from the hard drive during a read call. A seek call is unlikely to cause the hard drive to move because you're not changing the physical hard drive pointer but a virtual pointer to the file within your program.
The hard drive head (needle) starts moving and the disk starts spinning up (unless already spinning) at the read operation. There is no head move or spinup at the seek operation.
Please note that the head may move nonsequentially above the disk even if you are reading a file sequentially, i.e. the the read of the 2nd, 3rd etc. 512-byte block may cause the head to move far away as well even if there aren't intervening seeks. This is partially because the file is fragmented on the filesystem, or because the firmware has a sector number remapping (i.e. logical sector 5 is not between logical sectors 4 and 6) to compensate bad-block errors.
The assumption in the question "Assume that the data requested from the Hard-Drive doesn't exist in any of the caches (hard-drive cache , Os Cache , Ram and whatever else it could be)" is difficult to assume and relatively rare. Even in this case, there is only a loose association between user mode file I/O operations and physical storage device operations.
There are many user mode File I/O functions in various windows libraries. Some of the oldest are the C library low level I/O functions. There are also the C library stream I/O functions, the C++ iostreams classes, and the manged I/O classes. There are other I/O interfaces as well that are part of other packages.
In general, all the user mode I/O Libraries are built on top of the Win32 file I/O functions including CreateFile(), SetFilePointer(), ReadFile(), and WriteFile().
Unless a file is opened in unbuffered mode the operating system can cache the files contents. This is done system wide, and not on a per-file basis. So, even if your program had not read or written a file, I/O to a file may be cached and not result in any physical storage device I/Os.
There are many factors that determine how file I/Os map to actual I/O operations on a physical device. This includes, library level bufering, OS cashing, device driver caching, hardware level cashing, device block size, file size, hardware block/sector remapping, and other factors.
The short story here is that you cannot assume that individual file level read or seek operations correspond to physical device operations, such as disk head seeking.
This gets even trickier when writes are considered. Often writes are accompanied by a flush - which the application developer assumes will push the data all the way to the physical media. Developers often assume that when a flush call returns success, that the data is guaranteed to be persistent on the storage device. This is far from true as devices and drivers often ignore flush calls.
There is more complexity with solid state drives which are not mechanical and therefore do not have 'seek' operations. Here, other physical characteristics manifest themselves such as the necessity to erase blocks before they are written to.