Jump to content

About Windows 10


Aloha

Recommended Posts

My understanding of it (which could be wrong) has been that Windows, in order to work properly, requires the drive of the active OS to be labeled C:. So I just live with the shifting drive labels as I boot into one or the other version of Windows.

No, there is no actual requirement that the active OS should be on C:, as a matter of fact since NT 4.00 times (actually since NT 3.1) NT OS's are designed to be installed on non-C: (in the sense not necessarily on active (first) primary partition and not necessarily on a primary partition).

 

The automatic drive letter assignment when installing can be changed/overridden easily, while changing the drive letter of an installed OS, while doable is a complex and not necessarily successful procedure, complexity due not only to the Windows OS install but also by the installed MS or third party software and the zillion entries in the Registry linked to the drive letter/path. 

 

jaclaz

Link to comment
Share on other sites


The last Windows system I had that booted from D: was an NT 4.0 system way back in the last millennium.  Having both SCSI and ATA drives in it caused that.  It booted to a RAID 5 array.

 

Nowadays it's just an uphill battle to use anything but C:, and it's easier to just accept that C: should be the boot volume.

 

-Noel

Edited by NoelC
Link to comment
Share on other sites

The biggest pain I ever dealt with when trying to get a version of Windows to boot from another drive letter, was software or drivers. Either they were hardcoded to install on C: and you couldn't choose another installation location, or some part of the software was hardcoded to look in the C drive.

Link to comment
Share on other sites

but why force C? why not rather the %systemdrive% or whatever it was? it works muh better especially if they decide to abolish the C: drive as default, especially since W10 started killing floppy drives...

Link to comment
Share on other sites

No floppy drives you say? Something to test!

Regarding C drive, it seems Windows can handle the letters well enough* nowadays. Most of the headaches regarding what letter the OS was using was with older versions of Windows.

*except for the habit of Setup putting boot files on other physical disks or USB keys. :(

Link to comment
Share on other sites

but why force C? why not rather the %systemdrive% or whatever it was? it works muh better especially if they decide to abolish the C: drive as default, especially since W10 started killing floppy drives...

%systemDrive% is just an environment variable.

 

The issue is a few layers below, basically the NT OS were initially developed on different hardware (Alpha), and when "ported" to i386 some "over-structures" were needed, as well, most probably, some were added to guarantee pseudo-DOS (and Windows 3.x) compatibility.

 

To these over the years some other over-structures were added and since most of them were not documented properly a lot of third parties used (and still use) some "problematic" ways to address devices/partitions/volumes.

 

Of these the "least reliable" (but "most used") is actually the DosDevice drive letter.

 

Even MS themselves committed the same errors, in NT 4.00 changing drive letter was easy, in Windows 2000 the same methods already did not work anymore, because MS introduced in the Registry a link to an essential file in the early booting phase using the drive letter:

https://support.microsoft.com/en-us/kb/249321

 

JFYI:

http://www.msfn.org/board/topic/90495-change-boot-drive-letter-for-system-partition/

 

the design "flaws" include the (otherwise plain enough) .lnk files (that make use of drive letters and need attention in case of a drive letter change) and the general lack of a single, definite approach to identifying a device or a partition/voluime, read these:

http://reboot.pro/topic/20240-how-to-get-partitions-path-in-command-prompt/

http://reboot.pro/topic/10169-resolvedmount-hidden-partition-command-line-possible/

to understand by example how every subsystem or tool may call the same object in different ways.

 

The mechanism with which Volume ID's are assigned/created is scarcely documented and due to the way it is implemented it is prone to possible errors, the ARC PATH remains a good way to address a partition/volume, but would need to be updated to include the disk signature (since disk order is not anymore as "fixed" or as "predictable" as it was in early NT versions on or old hardware).

The drive letter assignment being (senselessly) in the Registry is one of the reasons why even a minor issue with the System hive may make a NT system unbootable and the way devices are addressed as NT objects (try running Winobj and you will see how there is another "layer" of device/partitions/volumes ID's) is still something not entirely/fully documented AFAIK.

Still JFYI:

https://msdn.microsoft.com/en-us/library/windows/hardware/ff567603(v=vs.85).aspx

https://morgansimonsen.wordpress.com/2009/01/26/displaying-the-volume-guid-of-a-volume/

http://stackoverflow.com/questions/39771/is-a-guid-unique-100-of-the-time

 

 

jaclaz

 

P.S.: @All, while it is perfectly possible that Windows 8/8.1/10 have introduced some added limitations (I strogly doubt that this hapened for Windows 8/8.1, it is more probable that something was introduced - maybe - in Windows 10), I can assure you that up to Windows 7 there are NO ISSUES whatsoever in running on a non-C: drive letter, with the exception - of course  - for the need of some added care with (badly written) installers like Tripredacus mentioned. 

Edited by jaclaz
Link to comment
Share on other sites

Yes, it's probably best to use C:.

 

The problem is that not every programmer follows the rules, or even knows them all.

 

People tend to prototype stuff to work on their particular development system.  A single system is complex.  The design rules are even more complex.

 

And people are lazy.  Programmers too (these are not technically people, but machines that turn caffeine into code, and they do suffer from aversion to work).

 

Gee, C:\Program Files is always there, right?  Think how much easier it is to code...

 

char *InstallRoot = "C:\Program Files\";

 

...in source code than do the lookup for the KNOWNFOLDERID or CSIDL calls to derive where it's actually at on any given system.

 

Your best bet, unless you LIKE dealing with ongoing problems, is to go with the flow.  The simplest to maintain, most stable systems run everything from C:.  Making a big, high performance C: volume can be advantageous.

 

-Noel

Edited by NoelC
Link to comment
Share on other sites

The situation I described is for people coding software.  My point is that there's more code writing involved to create software that follows the rules and derives the proper locations rather than just hard-coding a path.

 

Any good programmer would do it the right way.  Not every programmer is a good programmer...

 

-Noel

Link to comment
Share on other sites

yeah but how to derive the right path without anything as a base? I mean asing the user is a way but there should be a default since there are also noobs in the world.

and why shouldnt env vars be used in software, it's an approach that's easy and dynamic at the same time...

Edited by My1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...