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

What I was trying to tell you is that "cloning" actually means "low-level sector-by-sector copy" which is slower. (but no, no issues with that, only you don't need that). A number of tools won't do an actual "clone" (which is fine since you need NOT a "clone") even if they insist on using "clone" or "cloning" in the name or in the help/docs. What you will be doing will be a filesystem level copy (which is not a "clone") which will likely be faster and actually transfer to the "new" drive exactly what you need to transfer (actual files with their metadata intact). and will NOT transfer what you don't *need*, i.e. unallocated and unpartitioned space, regardless if 00ed or containing deleted files. jaclaz

Sure. The disk sector size exposed is in both cases 512 bytes. The filesystem(s) on them is exactly the same, and the dd (or similar) tool will see the same. BTW to be very picky - and just for the record - it is not possible to actually "clone" a disk under any Windows NT systems, unless you use particular procedures because you cannot have two disks with the same signature connected to a same system, In any case it doesn't make really much sense to actually "clone" a disk used for backup (as a matter of fact real "clones" only make sense for data recovery, for forensics or for particular deployment scenarios), and most tools will actually only copy at filesystem level (which is BTW usually faster, unless the source disk is literally full up to the brim). Compare with: The only issue may be how you connect the disk for the cloning, if you go Sata with Sata you won't have any issue, if you use a USB adapter be careful. A few (old) ones may not support the 4 Tb size of the disk. A few (new) ones may translate on the USB bus the 512e or 512n back to 4K jaclaz

IMHO there is a big difference between Windows ME and Vista. As a matter of fact Windows ME is - as you say - very similar to 98 SE (with actually a few betterings "under the hood"). The issue was that it removed (or made difficult) to an audience coming from 9x a large part of their experience (MS-DOS in real mode) while introducing quite a few incompatibilities (particularly with DOS based programs, but not only), and the betterings were not easily detectable to the end user. As a matter of fact, the "best" system is most probably a 98SE2ME: http://www.mdgx.com/9s2m/ http://www.mdgx.com/98-5.htm#KRM9S Of course XP (particularly the XP Home pre-installed on laptops) killed it (while providing - on the very limited hardware on which it was installed - a poor experience to the user anyway). Vista is a different case, it actually sucked, and it sucked big initially. A number of (senseless) changes were introduced on the otherwise perfectly working NT derived XP, and it was delivered in a severely immature stage, while no or very little documentation was provided. Besides (the same) issues with low-powered entry-level systems where it came pre-installed, the real deal breaker was that it was widely publicized as the "new better" OS (understandably from MS point of view) without highlighting how the hardware requirements were extremely higher than what XP ran on. The net result was that everyone that had XP running tried it (either on the same old hardware where they had XP running just fine or as a pre-installed OS on low-low power notebooks/netbooks) and the result was of an extremely slow OS (additionally with a lot of issues with permissions, network and drivers). It was doomed, everyone that could remained on XP, at least at the times of "gold" and - later - "SP1" (which only partially fixed the issues) came out. 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. The latter was also IMHO greatly facilitated by the progresses of the hardware in the meantime, an entry level system in 2009 was far more powerful than an entry level system in 2006 or 2007, and this is one of the reasons why 7 (which I like to call Vista SP3) actually had so much success. BOTH Vista and 7 are resources hogs (when compared to XP or even better 2K) what made the difference was the sheer power/speed beneath. jaclaz

Actually it has nothing to do with the filesystem, so the answer is "a suffusion of yellow", though it is entirely possible that the fastfat.sys (and much less likely the ntfs.sys) has some limitation size or address wise (as said earlier I doubt that any issue may exist in both, because of the "relative address nature of the volume access). I understand how it may seem complex, but there is no difference whatever between a volume addressed via MBR or via GPT both only represent a way to provide an extent address to the voume and the filesystem related drivers, so the features (read/write) for a given filesystem you have in your OS will not change. As a side note there may be issues with non-512 bytes/sector devices, however, as the driver is (was) targeted to "AF" disk drives. The filesystem in themselves (at least FAT12 and NTFS) have no issues with 4 Kb/sectors (tested) so, since FAT12 is the earliest incarnation of FAT filesystem, FAT16 and FAT32 should have no issues as well. Yes and no. Yes it can, but not "as is", there is the need of an installer and then making a .cab for it. I have seen such a program, written in Autoit,: http://reboot.pro/topic/18547-vhd-xp-setup-install-xp-in-vhd/page-6 About the suggestion on how I should spend my money, consider how till now I had no actual *need* to buy any disk larger than 500 Gb, so it will be a loong time before I will even think about buying a multi Tb disk, and even more time going beyond 4 Tb. But - and this should be checked thoroughfully - I believed that only 3 Tb and 4 Tb disks are common in "AF" format, whilst bigger ones are mostly "native 4k" (and thus the MBR limits is shifted to 17.6 Tb [1]). jaclaz [1] The exact number is not "negotiable", the 32 bit field in the MBR allows for 2^32-1 sectors=4,294,967,295 so: 4,294,967,295*512=2,199,023,255,040 bytes 4,294,967,295*4096=17,592,186,040,320

This. OT, but not much, today's news here in Italy, a call center in Milan sent a letter to 64 employees (out of roughly 500) telling them that starting from the 3rd November they have to take service in the new call center in Calabria (that is in the extreme South of Italy, some 1000 Km distance), alternatively the employees need to resign. These are low-wage operators, typically getting 600 €/month or so (most contracts are part-time), so there is no way they can afford the move. Just for the record in Italy there is since a few years a Law that when you call via telephone a call center a recording must state whether the call will be transferred to an italian call center or to anywhere else. Of course everything is routed via VOIP, etc, and there is no added cost to the caller if the call center is wherever abroad, but most people would simply hang when hearing the message, fearingto have to pay an extra. The net result being that traffic to call centers and help desks abroad (typically for Italy they were in Albania or Tunisia, i.e. countries with lower wages where there is a certain amount of young people fluently speaking Italian) extra-UE went instantly to near zero and quite a few of the companies operating in those countries folded operations. Starting from this year, some additional restrictions were added, among them the caller should be able to ask, even when called, to talk with (be forwarded immediately to) a representative residing in Italy or in a UE country. jaclaz

Why not from MS? You mean this one, right? http://www.tenouk.com/windowsddk/windowsdriverdevelopmentkit.html http://download.microsoft.com/download/9/0/f/90f019ac-8243-48d3-91cf-81fc4093ecfd/1830_usa_ddk.iso jaclaz

https://www.bishopfox.com/blog/2017/10/a-bug-has-no-name-multiple-heap-buffer-overflows-in-the-windows-dns-client/ ... just sayin' ... jaclaz

No, this is not the case: https://kb.paragon-software.com/article/838 jaclaz

Meanwhile in the Netherlands ... https://autoriteitpersoonsgegevens.nl/en/news/dutch-dpa-microsoft-breaches-data-protection-law-windows-10 jaclaz

Bold Moon. Mooning , and proud of it. jaclaz

Well, these drivers provide to "normal" XP BOTH GPT support AND access to bigger than 2.2 Tb (512 bytes sectored) disk drives, that is the whole point, and, compare with this: http://download.paragon-software.com/doc/GPTLoader_RG_081111.pdf at least they allow (of course in GPT style) a "monolithic" partition/volume of 3 Tb. It may be the case that the "GPT" part of the driver is the only thing 64-bit needed and then NTFS.SYS takes care of the "monolithic" partition/volume (that anyway begins at a normal offset of 63 or 2048 sectors, like any other "first partition"), but if this is the case it would be a really "ugly" workaround. jaclaz

I have it (for a limited time it was a "free" download), but I have no system with it installed, nor any "spare" large sized disk, so cannot make any real test, but I can provide you with some info. There are two drivers in the package: 1) hotcore3.sys 2) gpt_loader.sys At a quick look the two main/meaningful Registry entries are: HKLM, "SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}", "UpperFilters", 0x00010008, gpt_loader HKLM, "SYSTEM\CurrentControlSet\Control\Class\{71a27cdd-812a-11d0-bec7-08002be2092f}", "UpperFilters", 0x00010008, hotcore3 So gpt_loader "hooks" to "Disk Drive": https://msdn.microsoft.com/en-us/library/windows/hardware/ff553426(v=vs.85).aspx and hotcore3 to "storage volume" both are set as "Upper Filters", which should mean that they are "Filter Drivers", and given the GUIDs, they seemingly "hook" over - as you guessed - to the PartMgr.sys ({4d36e967-e325-11ce-bfc1-08002be10318}) but the other one (the {71a27cdd-812a-11d0-bec7-08002be2092f}) seems related to VolSnap.sys jaclaz

Maybe the DOS/Windows 9x/Me way to access volumes is different, cannot say. The Paragon driver (which does support GPT and thus more than 2.2 Tb addresses) is after all two drivers, but the fastfat.sys remains AFAICR the "default one" (and as well the NTFS.SYS, etc.). If you prefer (AFAIK/AFAICR) there are no original files patched or substituted in that solution, so I would exclude that the partition management and related files need any patch, I still beleive (but I may well be wrong) that all volume access is done using relative addresing only and on the other hand - unlike the FAT32 - the NTFS has 64 bit addresses since day 0, long before XP came out, so I would guess that the 64 bit math, if neeeded, is already correct. (but of course until some proper experiment confirms of denies it there is no way to know for sure). jaclaz

Well since we are still in the BMW motorcycle field, let's not forget how still today the boxer engine (and shaft drive) used on the series R models is essentially derived from the one designed in the 1930 and 1940's, which should be a good enough example that when you have something well designed and working correctly, you only refine it. Now MS had a perfect product: Windows NT designed (mainly) by Dave Cutler : https://en.wikipedia.org/wiki/Dave_Cutler that worked just fine since day one and was improved over the years until they managed to ruin it almost completely with Windows 10. jaclaz

I don't know , but knowing Paraglider , if he released a new version, it is "better". The "hooking engine" has been changed, reportedly: http://theoven.org/index.php?topic=1660.0 in order to make a 64 bit version (that wasn't possible before): http://reboot.pro/topic/9487-x64-versions-of-some-frequently-used-utilities/?p=85543 maybe it is just an update to have both 32 and 64 bit versions. In any case the original script from Paraglider: http://wb.paraglidernc.com/Scripts/Runscanner2.htm http://wb.paraglidernc.com/Scripts/Runscanner2.script interrogates this .ini: http://wb.paraglidernc.com/Files/Versions.ini currently: [runscanner2] file=runscanner2.0.0.0.7z and then proceed to download the file named in it aka: http://wb.paraglidernc.com/Files/runscanner2.0.0.0.7z jaclaz

Meanwhile, it's official, Windows 10 Mobile is dead: http://www.zdnet.com/article/windows-10-mobile-microsoft-just-put-the-final-nail-in-the-coffin/ Presumably he wrote and sent this confirmation from his faithful Samsung Galaxy S8: http://news.softpedia.com/news/microsoft-s-joe-belfiore-explains-why-samsung-galaxy-s8-is-a-great-android-phone-517258.shtml For those tuning in only now, remember that one of the reasons why the stupid Windows 10 was made so stupidly awkward was decleared to be the need for a "continuum experience", with the same app running in the same way on phones, tablets, desktops, X-boxes, everywhere: http://www.notebookreview.com/feature/windows-10-continuum-why-you-shouldnt-use-a-smartphone-as-a-pc/ Now imagine that - say - BMW removes the steering wheel and pedals from their cars in order to make the customers enjoy the same handlebar experience of their current motorbikes and future snowmobiles, and in two years time they decide to not build snowmobiles and cease production of motorbikes ... jaclaz