jaclaz

Since this is the ONLY relevant piece of info (and it is a detail missing in the original post) I will state it. Most (if not all) USB enclosures designed for larger than 2 Tb hard disks use an internal translation of sector size, exposing to the OS physical sectors of 4 Kbytes. This simply means that the infamous 2.2 Tb limit (given by (2^32-1)*512= 2,199,023,255,040) gets instantly shifted to 8 times (4096/512) that value, i.e. (2^32-1)*4096= 17,592,186,040,320). Since the sector size exposed is 4 Kb (and not the "normal" 512 bytes) the disk won't be normally bootable. Nothing really new. A couple 2012 threads: http://www.msfn.org/board/topic/157117-running-3tb-drive-on-xp-over-usb-issue/ http://www.msfn.org/board/topic/158361-confirmed-3tb-hdd-usb-drive-on-winxp-32bit/ only a nice confirmation with a 8 Tb disk drive. jaclaz

I don't get it. If you use DISM to remove a package you don't need the install_wim_tweak.exe, in any case - it is perfectly possible, that - for whatever reasons - it keeps *somehow* hooked the .wim (or mountpoint) in such a way that DISM has later issues with accessing it, but what is the rationale about running it (if not to list or unhide or remove some packages)? On the other hand, if issued without any command parameters, it may well NOT "lock" the .wim/mountpoint (because essentially it does nothing). jaclaz

@Yellow Horror #1 Sure it does support larger than 2 Tb volumes, only it cannot access them on a single hard disk, simply the MBR scheme doesn't allow that. #2 Sure there is the GPT loader, but the point (at least mine) was that there is no need to have GPT to access up to nearly 4.4 Tb on a single hard disk, divided in at least two volumes, this approach has been tested and it works on Windows 7 32 bit successfully. Actually there is no need whatever to have any hard disk (internal) larger than 2 Tb on a machine that runs XP, and thanks to the sector size translation present in most external USB enclosures, translated to 4 Kb disks work just fine (for backup, offline storage, etc.). #3 Sure there isn't any need of that, as a matter of fact that is another of my points, the good MS guys made up all these complications with GPT exactly in a time when noone in his/her right mind would not use a SSD as boot (and thus a smaller than 2.2 Tb device). Still, sometimes one does things just for the fun of it , and to learn new, strange things. @98SE Very likely your USB 3 Tb disk is "controller translated" to 4Kb sectors, so it will simply work (but it won't be bootable), which is exactly what this thread has been started with. The point of the experiment, since there is no doubt that 4Kb sectors (native or translated) work just fine and then such disks can be as as large as 17.6 Tb, is to have an INTERNAL SATA disk, 512e or 512n be accessible in XP as 2 partitions, the first smaller than 2.2 Tb, the second the rest of the disk. That (and nothing else) is the experiment *needed*, that Tripredacus performed (and succeeded with Windows 7 32 bit, but that - for some reasons - couldn't be replicated on XP). jaclaz P.S.: @RLoew, completely OT , but JFYI, PC-MOS/386 was recently released as Open Source: https://github.com/roelandjansen/pcmos386v501

Wait a minute, from the screenshot you are running it without any command line option? I.e. what happens with: install_wim_tweak.exe /p <MountPath> /l This will list all the packages available in the selected image and write them to a text file in the same directory. jaclaz

Not in this case, I believe. The context is to use a Raw or a VHD disk image to boot a XP (or other NT system), to do this you rely on grub4dos to do the initial mapping and chainloading and to specific (Winvblock or Firadisk) drivers, or - in the case of "native" VHD booting (windows 7 and probably later) on MS original bootloader. (and those will surely throw a fit when attempting to access the file). Additionally the base idea is to do some kind of ramdisk booting (which implies copying the image to Ram) and that takes time, so, as always, the smaller the image, the faster will be the booting. In any case, booting a larger than 4 Gb image is "pure folly" , personally I find already find senselessly bloated some of the images the tools by wimb create (at around 1.2-2.0 Gb), and for a "decent" XP system you can usually stay within the 512 Mb size (which BTW would also allow MS ramdisk booting). jaclaz

@98SE As long as an image file is within the 4GB (-1 byte) FAT32 file size limit it can of course reside on a FAT32 volume. There is no actual need to "reverse engineer" a GPT implementation, the way it works is known, it has official public specifications in the UEFI documentation (consisting in more than 2000 - that is two thousand - pages) it is writing a replacement (or - as seemingly Paragon did - "parallel" driver) for Partmgr.sys that is the problem. Scroll down the given page on multibooters, the whole point is that MS call "System" what you (and all the rest of the world) call "boot" and "Boot" what you (and all the rest of the world) would call "system". JFYI, those duplicated systems are "copies", not "clones" (as always trying to use same naming conventions). jaclaz

Oh, I see , you have then a "normal" install of XP after a single DOS/Windows 9x/Me install. That will re-write the bootsector of the active partition, overwriting the bootsector invoking IO.SYS (or Winboot.sys) with a bootsector invoking NTLDR, then will add to the BOOT.INI an entry pointing to a copy of the previous bootsector, called bootsect.dos. NTLDR has "embedded" this filename, so the C:\ reference is enough, because it actually resolves to C:\bootsect.dos http://thestarman.pcministry.com/asm/mbr/bootini.htm So, yes it works, but only as long as you have a bootsect.dos file in the root of the active primary partition. Yes, it is very dinosaurish, but as long as it floats your boat it is fine , using bootpart since the good ol' NT days, I always used a folder to store the bootsector, forgot what the default was . In any case the traditional (and right) way is to have a (small) primary partition for the boot files (FAT16 if using DOS 6.22, FAT32 otherwise) and then separate partitions for each windows, this is advised since day one by Gilles Vollant, the Author of Bootpart (which at the time, circa 1994/95, was more or less the only way to customize/fix a dual/triple boot system), Hey, wait, this separation between "boot" and "system" (which the good MS guys have reversed): http://www.multibooters.co.uk/system.html is the same thing that modern OS's use with UEFI. As a side note: 1) Vista can be installed to FAT32 just fine (Dietmar at the time posted a way). 2) Windows 7 cannot (actually it can, but it will have a few limitations) JFYI: http://reboot.pro/topic/19643-winsxs-hardlinked-files/ And now, for no apparent reason, as long as you are on FAT32, you can go here: http://www.multiboot.ru/files.htm and find about dostoxp.com and dostowin.com (still grub4dos' grub.exe is a much more flexible solution) jaclaz P.S.: about stage 2 it won't work, of course (HAL kicking in, switching to protected mode) anything DOS is "lost", and that is exactly the reason why drivers like Firadisk and Winvblock (that can "hook" parameters passed by grub4dos) were developed.

If you want a "wrong" one (just in case), here it is: https://msdn.microsoft.com/en-us/library/windows/hardware/dn653580(v=vs.85).aspx bold/italic is mine. I believe there is a difference between Vista and Vista SP1 however : Vista can access GPT disks but cannot be installed to them. Vista SP1 allows installing to them (on EFI, thus hardware bitwidth locked), . https://technet.microsoft.com/en-us/library/cc749132(v=ws.10).aspx Written in plain English, this more or less translates to "we added bootmgr.efi to Vista" jaclaz

No, that is not what I said. The "normal" way of booting XP is having a booting chain that through MBR and PBR code loads NTLDR (that then accesses BOOT.INI). Grub4dos can chainload NTLDR directly. Once loaded, NTLDR continues doing what it is designed to do (i.e. load BOOT.INI) I doubt that the BOOT.INI example you posted is actually working, because if the C;\ corresponds to Windows 98, then its PBR is the one loading IO.SYS, and you have no way to load NTLDR (without using some other third party tool to load it. So once in grub4dos you can decide to run command lines: find --set-root /ntldr chainloader /ntldr boot or have a menu.lst with an appropriate entry, like: title find and load NTLDR of Windows NT/2K/XP\n find and load NTLDR of Windows NT/2K/XP fallback +1 find --set-root --ignore-floppies --ignore-cd /ntldr map () (hd0) map (hd0) () map --rehook find --set-root --ignore-floppies --ignore-cd /ntldr chainloader /ntldr savedefault --wait=2 You may want to review: 1) http://www.winimage.com/bootpart.htm 2) http://diddy.boot-land.net/grub4dos/Grub4dos.htm Then it will be fun to see if you will be able to find a decent (recent) version of grub4dos. Well, you have a lot of homework to do to get in sync with the last 10 years of developments. It is OBVIOUS that some modifications are needed in order to have the HAL detect the USB bus and load and start the relevant drivers, if you consider that a switch between real mode and protected mode happens when a NT system is loading. There is no need to modify the NTDETECT.COM in most cases (in some cases is needed), only a few registry keys need to be modified, though - and it only depends on specific hardware - a number of "helper" drivers might be needed. In any case, while you should be aware of ALL the different methods available (and possibly also get familiar with them) nowadays I would go for a RAW image (or Fixed VHD) using either Firadisk or Winvblock, like (circa 2010): http://reboot.pro/topic/13731-full-universal-xpvhd-run-from-usb-finally-work-for-me-maybe-for-you-too/ and/or (circa 2013): http://reboot.pro/topic/18657-vhd-xp-compact-make-mini-xp/ jaclaz

Well, dinosaurs are not so easily extincted, they tend to continue stubborny living, you know ;). jaclaz

Just for the record (and FYI, though cannot say if of any use in this case) a similar thing happened a few years ago with the Format command that (obviously) behaved differently on different languages: http://reboot.pro/topic/3229-international-format-y/ although the actual issue was solved (half-@§§edly in batch), paraglider was kind enough to make a small program: http://reboot.pro/topic/3229-international-format-y/?p=28526 getyes that "reads string number 17208 from shell32.dll ": www.paraglidernc.com/files/getyes.zip If it still works in Windows 10, that might be the "correct" way. jaclaz

Again (last time) anyone else (but you) have been capable of booting Windows XP from "normal" USB sticks since the original work by Dietmar came out, in 2006. You simply cannot negate more than ten years of evidence and of all the world experience, and insist of spreading this kind of misinformation. Here is where it all started via Wayback Machine (911CD is dead): https://web.archive.org/web/20160523171220/http://www.911cd.net/forums//index.php?showtopic=14181 There are however several different ways, later developed. You cannot invent your own limitations (if a suited tool is grub4dos' grub.exe, why would you not use it?), Why you keep asking questions on things you evidently haven't studied or tested and have not experience with BUT refuse to accept the answers? It is tiring. The "normal" method of booting a XP is: BIOS->MBR->PBR of active partition invoking NTLDR->NTLDR->Choices in BOOT.INI->XP (if you chose the XP entry in BOOT.INI) The "normal" method of booting a DOS/9x is: BIOS->MBR->PBR of active partition invoking IO.SYS->IO.SYS (aka DOS) The "normal" method of booting a DOS/9x when in dual boot with XP is: BIOS->MBR->PBR of active partition invoking NTLDR->NTLDR->Choices in BOOT.INI->DOS/9x (if you chose the DOS/9x entry in BOOT.INI which actually chainloads a copy of the PBR invoking IO.SYS) What you can do is: 1) Boot to 98SE DOS. 2) Run GRUB.EXE. 3) Chainload NTLDR. 4) Choose an entry in BOOT.INI 5) If you chose the XP entry, you boot into XP. 6) NO reboot was performed. jaclaz

Sure , we only do that since 2006 (and no, USB sticks are not modified, modified ones (having the "Fixed" bit set) have an advantage but it is not at all a requirement. I will try to write this again, this time slowly, noone in his/her right mind would even think of making a FAT32 volume bigger than - say - 128 or maybe 256 Gb in size when/where NTFS is supported, it simply makes no sense whatever (and much smaller filesystems are actually advised) since you can have only one volume past (actually crossing) the 2.2 Tb border and at the most 2.2 Tb in size, the scheme may only be good for 3 Tb and 4 Tb disks, thus the second partition will be either around 800 Gb or 1800 Gb, sizes simply NOT suited for FAT32, It would be - provided that it works - very likely slow as molasses. And no, no foreseeable issue with NTFS, as I have written maybe 10 times already, and that you insist on ignoring, but unless the setup is actually tested there is NO way whatsoever to know if anything in *something else* (apart the NTFS filesystem per se) might create issues. Tripredacus managed to test the setup on Windows 7 32 bit succcessfully so we know that the whole related driver stack is OK with 7 (which is normal, since Windows 7 32 bit already supports GPT and as such volumes beyond or crossing the 2.2 Tb limit), but it is entirely possible that the XP implementation of the corresponding drivers has some limit, but it is improbable, because there is no difference in "where" the volume is, once the volume/filesystem driver are hooked, it is more likely that something in PartMgr.sys (besides the actual bus driver) may create problems. Since the Server 2003 does have (in Service Pack 1 if I remember correctly) GPT support, it goes without saying that its driver stack supports - just like Windows 7 - those addresses, so it may be needed to do - if possible - some file transplant from 2003, though - if I recall correctly - the architecture for storage in Server 2003 is partially different from XP. Sure, via grub.exe of grub4dos, as an example. jaclaz

Maybe you could have noticed that Xperties ia a "Patron" of MS with a membership dating back to August 18, 2001, he already knows perfectly that this is the right place, where he came (back) to. jaclaz

Why shouldn't they? I mean, it is true that Windows 10 sucks, but there are decency limits to its suckyness anywyay . As long as they are on separate partitions, there shuld be no issues whatsoever. But - at first sight - what you want/need looks more like what a "Windows To Go" install is about: https://docs.microsoft.com/en-us/windows/deployment/planning/windows-to-go-overview which can more or less created also in other versions of Windows besides Education and Enterprise: http://www.intowindows.com/4-tools-to-create-windows-to-go-usb-of-windows-10/ I would personally recommend you to try such an install (I personally prefer Rufus, but of course the other tools are OK as well) of course the capabilities (speed) of the USB stick you will try it on might make sensible differences, and a fastish stick is recommended, but *any* stick will give you an idea of how i works and see if it fits your needs. jaclaz

Yep, but what I meant was that there is no actual *need* to have them bootable, one thing is having them bootable (as a nice thing to have ) and another one is *needing* it. In the future and for a loong time, we will have SSD's (normally "512e") as main internal disk, and anyway we can use a USB stick as "boot initiator". What has to be tested (I haven't) is whether the "mini-DOS-ike" OS inside NTLDR is compatible with 4K sector disk drives, that could be a show stopper. And again the solution (if needed) might come from ReactOS, there were a few years ago the usual undocumented or terribly documented or misdocumented reports that the FreeLDR could also boot Server 2003. If there is even a minimum of truth in those, the steps to make it work for XP (and on 4K) should really be minimal. jaclaz

Exactly! And this will cover also *any* 512n or 512e in any of the USB enclosures that do the "translation" to 4k internally (which is what most pre-made external USB disks larger than 2 Tb already do). The only "issue" with the Ntive 4K (internal or external) may be bootability, Still in times when every decent system has anyway a SSD (thus for now and for a long time much smaller than 2.2 Tb and definitely "512e") and the low cost of (bootable) USB sticks it is not at all IMHO a priority of any kind. jaclaz

Here it is better explained: https://arstechnica.com/information-technology/2017/10/severe-flaw-in-wpa2-protocol-leaves-wi-fi-traffic-open-to-eavesdropping/ https://www.alexhudson.com/2017/10/15/wpa2-broken-krack-now/ anyway, if you used a smartcard to generate the key there are no problems... ,,, no, wait: https://www.forbes.com/sites/thomasbrewster/2017/10/16/worse-than-krack-google-and-microsoft-patch-massive-5-year-old-encryption-hole/#dc78b7947c35 You can still get on your nice Subaru and drive home ... https://www.bleepingcomputer.com/news/security/unpatched-exploit-lets-you-clone-key-fobs-and-open-subaru-cars/ wait, WHICH Subaru? jaclaz

An LBA entry in the MBR (or in a EMBR) is made of two fields, each 32 bit in size: 1) "Start Address" or "Sectors Before" i.e. how many sectors are BEFORE the beginning of the partition described in the entry 2) "Size" or "Sectors in partition". i.e. how many sectors (starting from the address in the field above) are contained in the partition. So at the very most you can have is: 1) One entry where the "Start Address"+"Size"<2^32-1 (this can be also multiple partitions as long as the sum of the last "Start Address"+"Size" remains within the 2^32-1 limit. 2) Given that the #1 is actually <2^32-1 ONLY a single primary partition with a maximum extent of 2^32-1 sectors. If you prefer, you can have one (and only one) partition crossing the 2^32-1 "border". Since you need some "hidden sectors" before the first partition (at the very minimum 1, the MBR), the most you can have theoretically is: Entry #1 -> "Start Address" = 1 and "Size"= (2^32-1-1)=4,294,967,294 these will be in hex respectively 0x00000001 and 0xFFFFFFFE and 0x00000001+0xFFFFFFFE=0xFFFFFFFF=4,294,967,295, i.e. (2^32-1) Entry #2 -> "Start Address" =(2^32-1)=4,294,967,295 "and "Size"=4,294,967,295 these will be both in hex 0xFFFFFFFF In practice you need to align the partitions using more "hidden sectors" which are typically 63 (traditional value, aligned to disk geometry) or 2048 (new value since Vista, aligned to 4Kb, actually more than advised, strongly suggested on 512e disks) so you can have at the most: Entry #1 -> "Start Address" = 2048 and "Size"= (2^32-1-2048-7)=4,294,965,240 (i.e. a number divisible by 8), these will be in hex respectively 0x00000800 and 0xFFFFF7F8 and 0x00000800+0xFFFFF7F8=0xFFFFFFF8=4,294,967,288 (<4,294,967,295) Entry #2 -> "Start Address" =4,294,967,288 "and "Size"=4,294,967,295 these will be in hex respectively 0xFFFFFFF8 and 0xFFFFFFFF There is simply no more address space to write bigger numbers. The 128 Gb limit you mention is an altogether different issue. The LBA data in the MBR has always been 32 bit in size, but the actual hard disk standards (ATA) had only 28 bit resolution (early drivers , i,e, 2k until Service Pack 3 if I remember correctly and XP until SP1 followed the standard) with ATA 6 the resolution was increased to 48 bit (i.e. more than the amount that can be stored in the physical space available in the MBR). The 48 bit in itself allows accessing 2^48-1=281,474,976,710,655 sectors, i.e., with "normal" 512 bytes sector 128 Pb. If you prefer, before the ATA transmitted only partially the data available, now it can trasmit more data than what exists. Now any *normal* OS manufacturer would have found a way to extend the MBR scheme finding a way to use some otherwise unused 4*2 bytes *anywhere* in the MBR as "high address" (and BTW also a 40 bit extension, needing only one additional byte per entry would have made accessible 512 Tb that would have been more than enough for several years), but the good MS guys (strongly pushed by the good Intel guys I believe) decided that it was too d@mn simple and went for the stupid GPT scheme (which is the typical exampe of an overcomplicated scheme designed by a commission). Still, there is nothing preventing adding GPT compatibility to an existing OS such as XP, but a number of drivers (and possibly a number of disk related tools need to be rewritten (from scratch since most are not open source). Most probably the next candidate would be a port of ReactOS drivers, when and if that OS will have GPT support, and by that time most probably it would make more sense to use directly ReactOS instead of XP. jaclaz

But wouldn't it be "modern" or "cool"? We also have no app (please remember that we would need two of them, one for iOS and one for Android). We could say that we miss them, but seemingly we don't actually *miss* them, jaclaz

The GPT Loader (even if I didn't ever test it) is a Commercial product that has been used successfully by a number of people without particular issues, there is no need to test it. These people did use it to read and write (obviously) on hard disks. No problem there. The whole point that you seemingly insist on ignoring (or fail to understand) is that the filesystems are accessed (and read and written) by filesystem drivers. These on NT based Windows are represented commonly by FASTFAT.SYS and NTFS.SYS. They hook on an object that in NT based windows is a "volume". Whatever creates the volume (the "standard" partmgr.sys in case of a partitioned MBR device, or the gpt_loader.sys in the case of a partitioned GPT device) doesn't make ANY difference in the way the volume is accessed, again a number of devices use not the partmgr.sys and directly expose a "volume". So there is no doubt whatever about the working of these filesystem drivers with the GPT loader. As well, everyone has been able of creating partitions smaller than 2.2 Tb AND residing within the 2.2 Tb limit and accessing the resulting volumes through FASTFAT.SYS and/or NTFS.SYS. The question is whether in the general way these drivers (and these drivers in the specific XP 32-bit version) are used, they may suffer from a 32-bit limit of some kind when the volume crosses (or is entirely beyond) the 2.2 Tb limit. In theory they shouldn't, particularly the NTFS.SYS, as all indexing fields in a NTFS filesystem are 64 bit (since day one) BUT LONG BEFORE THAT because volume/filesystem access uses "relative" addressing (from the start of the volume). Since it is NOT possible to make partitions larger than 2^32-1 sectors with the MBR scheme, the proposed scheme is to make two partitions (the first just a little smaller than 2^32-1 sectors) and the second as big as the rest of the disk (limited obviously anyway to 2.2 TB, so only useful for 3 Tb or 4 Tb disks). The experiment carried on by Tripredacus (with Windows 7) confirmed that the dual partition MBR scheme works just fine (or if you prefer Microsoft lied when they imposed the GPT to access more than 2.2 Tb disks) and the NTFS.SYS from Windows 7 is confirmed to behave correctly (which is not a surprise, since in 7 there is also GPT support and thus, indirectly, support for volumes crossing or beyond the 2.2Tb "border"). When (if) someone will be able to replicate that experiment on Windows XP 32 bit, then we will have certainty that also the XP version of the NTFS,SYS driver is fine with volumes crossing the 2.2Tb border, but - as a matter of fact - the issues, if any, will more likely come from other files/tools. Whether FASTFAT.SYS may have issues with such a cross-border volume it is meaningless, as noone (in his/her right mind) will ever make a partition (at least 1 Tb on a 3 Tb disk or 2 Tb on a 4 Tb disk). Hope that now the matter is more clear. jaclaz

AFAIK the Dutch may decide to impose a sanction by themselves or bring the preblem forward to the EU, since there are not that much differences between the actual national privacy related Laws in most countries of the EU, this can easily became an European sanction. The part that clearly violates any and all privacy Law (besides the "initial" and "limited" opt-out approach which is probably debatable) is the "switch back to full": jaclaz

I will try again (third and last time) Once a volume has been mapped (and is given a drive letter or a mountpoint) the SAME drivers, respectively FASTFAT.SYS and NTFS.SYS for FAT and NTFS are used to read and write, NO MATTER if the volume is mapped via MBR, via GPT or without anything (superfloppy device) or plain device extent mapping. The test you suggest is totally meaningless. The only doubt that can be is on extremely large volumes, bigger than 2.2 Tb (that would make anyway no sense if FAT32 and that almost surely will work just fine with NTFS, since the NTFS has since day one 64 bit fields in the BPB) jaclaz

No, I don't have ANY hard disk larger than 500 Gb, and though I have a copy of the GPT Loader I never installed nor used it. I did test NTFS and FAT12 on (emulated) 4 Kb disk drives successfully. What is the diffcult part in: jaclaz

Ok. A set of numbered statements. 1) Vista sucked (and sucked BIG), both when released and with SP1. 2) The actual working version of Vista (from a certain point of view even better than 7) was SP2 which simply came too late and was "killed" by MS itself and by the release of 7. 3) Vista is a resource hog (measured with the ONLY possible point of view, the performance on the entry-level hardware of 2006/2007 where it was pre-installed at launch time and with what Microsoft gave as basic requirements) 4) 7 is a resource hog just like Vista, after all it is Vista SP3+ (but, measured with the point of view of 2009 or later hardware it is harder to notice) 5) Obviously today, in a time where most basic hardware is at least 3 times faster than 10 years ago, maybe even faster, particularly if we include a SSD, the hogging of resources goes totally unnoticed, this is not a merit of the OS, it is the merit of the hardware. @Burd you cannot even think of comparing Windows ME with Windows 2000, because they represent two completely different branches of the OS, the DOS based family vs. the NT family, and - besides this- the actual "good" parts of Me came from 2K, but more than that, at the time the good MS guys (correctly) differentiated users between "home" (to which Me, like 98, was targeted) and "business" or "pro" (to which 2K, just like NT 4.00 was targeted). jaclaz