jaclaz Posted July 23, 2015 Share Posted July 23, 2015 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 1 Link to comment Share on other sites More sharing options...
NoelC Posted July 24, 2015 Share Posted July 24, 2015 (edited) 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 July 24, 2015 by NoelC 1 Link to comment Share on other sites More sharing options...
jaclaz Posted July 24, 2015 Share Posted July 24, 2015 @JorgeAJFYI/for the record:https://www.srware.net/en/software_srware_iron_chrome_vs_iron.php https://www.srware.net/en/software_srware_iron_download.phpPortable-Version for USB-Sticks (no Installation; no Admin-rights needed; Profils in the same folder) http://www.srware.net/downloads/IronPortable.zip jaclaz Link to comment Share on other sites More sharing options...
Tripredacus Posted July 24, 2015 Share Posted July 24, 2015 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. 1 Link to comment Share on other sites More sharing options...
My1 Posted July 24, 2015 Share Posted July 24, 2015 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... 1 Link to comment Share on other sites More sharing options...
Tripredacus Posted July 24, 2015 Share Posted July 24, 2015 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 More sharing options...
Aloha Posted July 24, 2015 Author Share Posted July 24, 2015 OK, then the advice is so obvious. I'd better leave those drive letters alone; Windows should always be on C.Thank you all for replying. Link to comment Share on other sites More sharing options...
jaclaz Posted July 24, 2015 Share Posted July 24, 2015 (edited) 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).aspxhttps://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 July 24, 2015 by jaclaz 1 Link to comment Share on other sites More sharing options...
NoelC Posted July 24, 2015 Share Posted July 24, 2015 (edited) 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 July 24, 2015 by NoelC 1 Link to comment Share on other sites More sharing options...
My1 Posted July 24, 2015 Share Posted July 24, 2015 but the "Program FIles" Folder is there as it is only in English versions of Windows ot's probably different in other languages... 1 Link to comment Share on other sites More sharing options...
NoelC Posted July 24, 2015 Share Posted July 24, 2015 Another very good example, thank you. It helps make my point. -Noel Link to comment Share on other sites More sharing options...
My1 Posted July 24, 2015 Share Posted July 24, 2015 but why not simply take the environment vars for this, I mean I've never seen a place where they werent... Link to comment Share on other sites More sharing options...
NoelC Posted July 24, 2015 Share Posted July 24, 2015 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 More sharing options...
My1 Posted July 24, 2015 Share Posted July 24, 2015 (edited) 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 July 24, 2015 by My1 Link to comment Share on other sites More sharing options...
NoelC Posted July 25, 2015 Share Posted July 25, 2015 You make API calls that resolve KNOWNFOLDERID values. An example discussion on this:http://stackoverflow.com/questions/6827496/how-to-properly-use-userprofile-inside-code Environment variables are resolvable too, if that lights your fire. That which I have listed above is preferred. -Noel Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now