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

Yes, but there is no need (in the proposed scheme) to use 64 bit math at all. All values are within the 32 bit limit since, once the volume is addressed, all addresses are relative and the 0 offset is from the PBR. jaclaz

Get it from the script: http://win10se.cwcodes.net/projectindex.php http://win10se.cwcodes.net/Projects/Win10PESE/Apps/System Tools/Registry/Runscanner.script But there is also a 2.0 version: http://win10se.cwcodes.net/Projects/Win10PESE/Apps/System Tools/Registry/Runscanner2.script Shameless plug (just in case): http://reboot.pro/topic/10783-release-unwbzip/ jaclaz

Yep, in theory Uniata should allow the same result as Tripredacus demonstrated for Windows 7 32-bit, i.e. that the good MS guys lied to us in their attempt to push UEFI/GPT. But maybe there is some additional (intentional or not) roadblock in XP. It seems like Windows Server 2003 SP1 (both 32 and 64 bit) have "native" GPT support, so - likely - that would be the first OS to support this scheme - like 7 - without needing further mods. The key should be : http://alter.org.ua/soft/win/uni_ata/ large drives above 2Tb support (SCSI READ16, WRITE16) jaclaz

Though it is not at all clear WHAT exactly is obtained by using it, there is a Registry setting that may (or may not) solve your issue (as said all references I found are far from being clear): https://www.askvg.com/fix-microsoft-word-always-shows-compatibility-mode-text-in-titlebar/ https://www.thewindowsbulletin.com/how-to-fix-compatibility-mode-error-in-microsoft-word-1808/ Not even if the Compatmode key should be deleted or set to 0 (probably the latter ). In any case it would only take a few minute to BACKUP the existing value and try changing it, to see what happens: HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Options Compatmode jaclaz

The Windows 10 fans of Edge should rejoice: https://blogs.windows.com/msedgedev/2017/10/05/microsoft-edge-ios-android-developer/ I don't think any comment is needed. As a side note: Anyone still remembers when you could actually identify an User Agent string a glance? jaclaz

Not really-really. The definition is that of a "componentized version of the OS", basically if you include *everything* (every component) at build time, what you get is the "full" OS. jaclaz

I am way cooler. I decommissioned only recently (march or april this year) a couple of machines, running respectively NT 4.00 and Windows 2K that worked just fine for the parts of the Internet that were needed. Both ran 24/7 for the last 14 years or so without issues of any kind (only replaced some power supplies and some disks). In the good ol' times we used to call this "work", it involved no access to social sites, no messaging, no lolcats, no videos, you get the idea . jaclaz

No, you didn't. You installed the OS on the second disk, but maintained the boot disk the first one. and this is the reason why you needed (and still need) both disks to be present, i.e. you installed the WINFLP on BOTH disks. The install routine of WINFLP overwrote the PBR code on the first (Win95) disk with one chainloading NTLDR, the files NTLDR, NTEDETECT.COM and BOOT.INI are on that first disk, and BTW very likely your windows XP (winflp) install is on drive letter D: - or however not C: . The normal XP installation would have done exactly the same thing, BUT it would have also automatically added an entry in the BOOT.INI pointing to a (copy of) Win95 bootsector (whcih is what you just did through the use of bootpart). Good. BUT, now that you have solved that, a good idea might be to have a copy of those files on the (active) partition on second disk (the reference rdisk in BOOT.INI will need to be changed, so that if - for any reason - the first disk gets damaged or removed, you have the possibility of booting the second disk (and WINFLP) "by itself". In other words even if now it works "as it should", it is a good idea to make the second disk "self-standing", you never know when and if it may become of use. jaclaz

I will ask a simpler question: WHICH updates/patches did user 98SE offer here? The updates offered here are by user Wunderbar98 AFAICT. jaclaz

Well, don't remove the WinFlp Disk. Now, seriously, it should be easy to fix, once we understand how it is setup. What do you mean that "you do not have an option to choose the OS"? You made a dual boot that was actually a single boot of just WINFLP? What happened (more or less). You had a single disk, let's call it "first disk". The system booted as follows: BIOS->First Disk->MBR->Active partition (on first disk)->PBR (on first disk active partition)->IO.SYS(on first disk active partition) then you added the other disk (let's call it second disk) and you installed the WINFLP (that may well - unlike "normal" XP provide NOT an option to keep a previousOS bootable), then likely the sytem started booting as follows: BIOS->First Disk->MBR->Active partition (on first disk)->PBR (on first disk active partition)->NTLDR(on first disk active partition)-> BOOT.INI (on first disk active partition) -> NTDETECT.COM (on first disk active partition)-> Windows WINFLP (on a partition on second disk) All the "issue" is then most probably in the contents of BOOT.INI (that has only one OS line in it, the one pointing to the WINFLP installation, and thus you have no booting choices). It can easily be fixed, the easiest tool would be either grub4dos or bootpart, the latter probably better specifically: http://www.winimage.com/bootpart.htm Your next step should be to open the C:\BOOT.INI file (you may need to select in Explorer to show hidden and system files) in NOTEPAD and posting its contents (just to make sure that the previous hypothesis of how your setup is made is correct). Then, it depends on what you actually want to obtain as result: 1) boot BOTH (i.e. have a dual boot choice) the Windows 95 on first disk and the WINFLP on second disk 2) boot ONLY the WINFLOP (BUT be able to boot it also when the first disk is removed) 3) boot ONLY the Windows 95 (AND be able to boot it when the second disk is removed) 4) somethign else (please describe) jaclaz