jaclaz

Yes, it is possible. https://msfn.org/board/topic/149612-winntsetup-v531/ jaclaz

And this in itself means nearly nothing. Most recent disks have 4096 bytes sectors. Then most of them are set as 512e, i.e. while they do have 4096 bytes sectors, they expose to the partitioning/formatting tool 512 bytes sectors. So called "Native 4K" are relatively few. Then comes into play (in case of external disks) the enclosure or the "bridge" in it (be it USB or other). Some of these make no translation, some translate the disk from 512 bytes sector (512e or not) to 4096 bytes, some (hopefully only a few) may even be intended to translate Native 4k to 512 bytes sector.. It is complicated. You could (should) analyze the bootsector of those volumes to understand how they were formatted, checking the fields "Bytes per sector" and "Sectors per cluster" you will be able to make sure what the sector size (at the time the volume was originally formatted) was and the actual (again at the time it was formatted) cluster size. jaclaz

See here: https://msfn.org/board/topic/183250-how-to-disable-the-built-in-xms-driver-in-windows-mes-iosys/ https://github.com/pufengdu/IO8EMMOK jaclaz

There is no such thing as Physical cluster, that is the Physical sector size. It is possible that the original disk exposed 512 bytes sectors. Then the volume was formatted, with the whatever cluster size that was applied to the filesystem, was a multiple of the (physical) sector, this is the actual way the cluster size is expressed in the bootsector, the field is called "Sectors per cluster" and (as an example) the common 4096 bytes sized cluster is expressed as 8 (because 8*512=4096). If you simply copied the volume, and nothing adjusted that value the filesystem will become invalid, as that same 8 will be interpreted as 8*4096=64 KB. When you used that tool to "convert" the cluster size it evidently changed and fixed that value (+ possibly a few others as needed to make a valid filesystem). I don't know of any tool that will clone a volume and adjust these values, actually it won't be a clone at all and there remains some risks with converting these volumes. Besides, at least in the case of NTFS, this kind of conversion would equate (if possible at all) to a re-write of the filesystem, a "normal" $MFT entry on a NTFS filesystem on a 512 bytes disk is 1024 bytes while a $MFT entry on a NTFS filesystem on a 4095 bytes disk will be 4096 bytes. In a nutshell, you cannot (and shouldn't) clone a volume from a 512 bytes disk to a 4096 bytes disk. No idea whether the (built-in EFS) NTFS encryption has any limit on cluster size, but it is not like, even if true, the hypothetical virus would surely use the standard NTFS encryption, and not any other algorithm/encryption scheme. jaclaz

At least for 7 you can have the bootloader on floppy disk, if you want, still it would be BOOTMGR+BCD. Windows NT6+ can only be booted by BOOTMGR (or bootmgr.efi in case of EFI BIOS), which corresponds to NTLDR, the issue, as you highlighted, is managing the configuration file which is the BCD, which corresponds to the good ol', plain, boot.ini.. The BCD file is a binary (actually it is a Registry hive) and MS only provides (inconvenient/complex) command line tools to manage it. You actually need BOOTMGR and BCD, so you might want to look at (third party) tools that allow an easier editing/changing of the BCD. I can suggest you: Bootice http://reboot.pro/index.php?showtopic=21956 Bellavista http://www.zezula.net/en/fstools/bellavista.html Visual BCD Editor https://www.boyans.net/ Lilo won't help you at all. Grub (now GRUB2) is (IMHO) overly complex, in case you want to make a "bridge" between your current NTLDR+BOOT.INI and the BOOTMGR+BCD of your new installs I suggest you to use grub4dos instead which is much simpler to install (or not install as it can be chainloaded from NTLDR+boot.ini). jaclaz

The link you posted is somehow invalid, this is the right one: https://msfn.org/board/topic/183934-seagate-external-hard-drive-is-xp-incompatible/ Nothing has changed since then. If your disk is exposed as being 4K sectors by the USB adapter, then it should (might) work with MBR style, if it is exposed as being 512 bytes sector you will be limited to 2.2 TB in MBR. TB sized partitions FAT32 are "pure folly", anyway the cluster size for volumes larger than 32 GB should be 32 KB: https://support.microsoft.com/en-us/topic/default-cluster-size-for-ntfs-fat-and-exfat-9772e6f1-e31a-00d7-e18f-73169155af95 Again, see a few posts starting from here: https://msfn.org/board/topic/118623-clone-easily-windows-98-and-xp-in-the-same-computer/page/8/#comment-866527 (link already given in the other thread) On NTFS it makes no sense to use larger than 4KB clusters, that are good up to 16 TB. If you created a partition 1.17 TB, that is the size of the partition, but this tells nothing about the size of the volume inside it, disk manager and partitioning tools look at the size of the partition, explorer and other file managers access the filesystem, that since you "pasted" it may have a different size or even come from a filesystem on a disk where the 512 bytes sector was in use.. Sector 256 may be ok (if the disk is exposed as 4kb sectors) as it is the default alignment to 1 MB used in Vista and later. There is a known risk when using XP disk manager on a disk where volumes inside extended partition are created with a later system (with the 1 MB alignment), this should not apply to volumes inside extended partition created under XP with disk manager, but they will NOT be aligned to the MB, if they are, you risk losing all of them at the first time you use disk manager to change *anything* on the disk. Cluster size is a characteristic of the filesystem, you can only set it when formatting a volume, if you copy a whole partition the original cluster size will obviously be maintained. It has to be seen what happens when you resize (expand) a volume, a "normal" tool should stop at the max cluster size allowed for the size of the volume, without changing cluster size as changing it would essentially mean to rewrite the whole FAT tables or the $MFT. jaclaz

Dibya, it is not at all a problem with your English, I am not a native speaker as well (which creates a nice, symmetrical situation), the issue is with the info that you post that are vague, confusing and possibly falsely creating expectations. I am happy that you now understand Xp's graphic architecture, but if you are not going to produce and release anything, it is of little use to anyone else. What has to do someone else's project (seemingly aimed to 9x and virtual machines) with NT/XP with your project? jaclaz

I did a lot of internal (and also external) studies of your sentence and (unfortunately) cannot make heads or tails of it. Care to explain in plainer English what you mean? The essence seems to me "There are no news on the project. No progresses I can report, nothing available, not even an early alpha, not any roadmap, let alone an expected release date ", but I may well be wrong. JFYI, after January 2018 a new rule was added, rule #4.e (for the record around November 2019), which may apply to recent posts: https://msfn.org/board/guidelines/ jaclaz

Oh noes, not again. https://msfn.org/board/topic/184730-antimalware-firewall-and-other-security-programs-for-windows-xp-working-in-2023-and-hopefully-beyond/page/18/#comment-1247635 That particular CVE is definitely not the reason why a number of governments issued warnings and prohibitions about the use of that antivirus. That one, at the most, can be used to de-anonymize the user in very specific cases (i.e. after a phishing attempt succeeded). The actual reasons why must (should) be much, much worse (and have not been disclosed), the "original" ban about its use on US government hardware is 2017 (two years before the mentioned CVE), other bans and warnings are 2018 (one year before) and 2022 (three years later): https://en.wikipedia.org/wiki/Kaspersky_bans_and_allegations_of_Russian_government_ties jaclaz

Personally I recommend NOT using GPT on XP at all. Either learn to live with internal hard disks smaller than 2.2 TB or find an external USB that exposes 4kb sized sectors and compatible with MBR up to 17 TB or so. Now, finding these external USB enclosures might be unfortunately really tricky as producers/sellers are unlikely to highlight how their controller works. On this thread where the matter is discussed on superuser there are a couple hints, but nothing "exact" on the make/models: https://superuser.com/questions/1271871/4k-emulation-sata-usb-controllers There is yet another option, use (if you can find one) a native 4K drive (that does not do "512e" emulation), I believe they exist only in largish sizes (8 TB and more) but really cannot say. Remember that 4kb drives won't normally be bootable with MBR. jaclaz

Didn't say they were not German, only that the actual adapter was manufactured in Taiwan. I posted (in reply to D.Draker reporting his good experience with German DeLock products) a link to one of them on the brand site (DeLock) with photos where there is written on the board "Made in Taiwan": https://www.delock.de/produkt/62510/merkmale.html?setLanguage=en https://bilder.tragant.de/produkte/orig/645b9a89639201.53221600.jpg The datasheet: https://www.delock.de/produkt/62510/pdf.html?sprache=en reports: Computer universe is only a reseller, on that thread there are more info about them and the (BTW usual) way most European (and German) brands normally operate, products are largely manufactured in Asia: https://msfn.org/board/topic/184668-refreshing-data-on-the-disk/page/4/#comment-1244101 jaclaz

@Cocodile There are no such things as jaclaz's certifications, let alone blessings. @j7n In theory yes, in practice, unfortunately, in the best case you will collect a number of vague, inaccurate reports creating the typical GIGO (Garbage In Garbage Out) situation. jaclaz

I have no idea of any correlation (or lack of it) between e-cores and Vista issues. A statement was made to the effect that all Alder Lake processors had e-cores. Another statement was made to the effect that only F and KF had them. Both are seemingly not fully accurate. I only provided a source[1] from which it comes out that up to i3 none have them, in i5 only K and KF have them, i7 and i9 have them regardless the model. jaclaz [1] Wikipedia, not necessarily to be taken as the ultimate truth

The Paragon GPT loader does not work on external (USB) drives, only internal ones. Usually (but not always) external hard disks larger than 2.2 TB expose 4KB sectors (and in this case there is no need to have GPT style partitioning). A "generic" external enclosure may well expose the "normal" 512 bytes sector or be incompatible with 2.2+ TB sized hard disks. As seen in this thread, using some files from Server 2003 may work, but there is a risk of data corruption/instability. See also here: https://msfn.org/board/topic/177379-3tb-drive-and-winxp/ https://msfn.org/board/topic/176480-2-tib-limit-size-in-mbr-hard-drives/ jaclaz

German brand actually made in Taiwan: https://msfn.org/board/topic/184668-refreshing-data-on-the-disk/?do=findComment&comment=1244101 @legacyfan A number of the no-name or generic adapters may have some limitations related to size of the hard disk, please note that oldish 2.5" hard disks, while they may be of smaller (and compatible) size often require more current that what a normal USB can provide, you should check the Amperes needed by the disk, a "standard" USB up to 2.0 gives 0.5A@5V, there are so-called Y-cables to connect to two USB ports (thus providing 1A@5V) that are (were) often needed: Bent pins can usually be straightened, but if you can actually insert the connector they shouldn't be bent/crooked much. The possibility of a malfunctioning (though not DOA as it initially they worked) adapters of course exists, as well it is possible that the issue is with the hard disks themselves. jaclaz

I didn't compare anything. I plainly stated that I doubt that Dixel had enough data points, unless he actually deals (and has dealt for years) with many, many (hundreds, thousands) hard disks, while actually keeping a log of periodical reads, failure modes, etc. and that as such the conclusions he draws are - no matter if right or wrong - anecdotal data based on a relatively small experience, and anyway very likely spread over a too small sample for each make/model of hard disks. Then - separately - I briefly summed up the results of the Backblaze report. jaclaz

With all due respect to your personal experience, unless you are (and have been for a long time) an IT technician working on a very large organization (that actually monitors S.M.A.R.T. parameters on a large number of disks), I doubt that you can have enough data points to "cover" 17 different parameters and highlight as more common 8 of them (if you prefer your "many disks" may be too few to draw conclusions). Backblaze, monitoring some 70,000 disk drives found only 5 (maybe 6) parameters correlated with impending drive failure: https://www.backblaze.com/blog/what-smart-stats-indicate-hard-drive-failures/ and possibly: not fully overlapping with your list and with some caveats about the need of additionally interpreting the actual values depending on the timeframe they occurred/increased count. A known (cited in the article) BIG unknown is whether power up cycles (S.M.A.R.T. 12) has any correlation as the drives they monitored belong to server farms so they have very, very few power cycles, unlike the disk drives in use by many organizations and most final users that are usually powered on/off on a daily basis, it is reasonable to add it to the list, making it a total of 7 parameters to look for. jaclaz

https://en.wikipedia.org/wiki/Alder_Lake#List_of_12th_generation_Alder_Lake_processors The i5 seemingly miss them, even the F models, only K and KF have them. jaclaz

You are very welcome to disagree, no need to be sorry. The point I am trying to make is that even if it (the S.M.A.R.T.) was a reliable predictor (and it isn't, at least in large numbers) it is a "vague" one, just like "Seagate", each model/series of a given brand like Seagate may present different failure modes, and while some of them may actually cause a change in S.M.A.R.T. parameters that can lead to a valid warning by the monitoring software many others won't. This and the lack of proper data (about the way some of the S.M.A.R.T. parameters are implemented by the manufacturer) lead to a situation that can be described as "when it works it works, when it doesn't, it doesn't" so that the reference I often make to flippism being equivalent (intentionally provocative) is not at all unjustified. The issue I have with your statement revolves about the "any" in "ahead of any failure", as what happens in practice is ahead of some failures where - additionally - the ahead could mean hours, days, weeks or even months ahead. Better than nothing, but still nothing to be trusted upon. jaclaz

No, the actual "testing programs" can tell if a disk drive has already become bad, and since they need to write on all surface they do stress the disk (particularly in a laptop/where you cannot provide good/additional cooling), you should NOT use them routinely.. The programs that can read S.M.A.R.T. values usually offer a (highly unreliable/unproved) "grading" of these values, providing warnings if certain thresholds are reached, but it is the underlying technology which is not capable of providing (meaningful) predictions: https://msfn.org/board/topic/128807-the-solution-for-seagate-720011-hdds/?do=findComment&comment=1073898 https://msfn.org/board/topic/153191-does-copying-several-giga-bytes-on-a-daily-base-screw-the-hard-drive/?do=findComment&comment=975216 Keeping an eye on the handful of actually (but partially) useful S.M.A.R.T: parameters as found by Backblaze in their reports (namely 5, 187,188,197,198 and - possibly - 189.) won't make any harm, see also: https://msfn.org/board/topic/177196-is-my-drive-still-healthy-seagate-sshd-1tb/?do=findComment&comment=1146918 but it won't anyway predict reliably a possible failure. jaclaz

For what it matters, still in India, the equivalent of the DMV site (government site where you can obtain or renew your driving license) has been found to be vulnerable to several possible exploits, including Sysadmin credentials, potentially exposing 185 million people personal data: https://blog.robinjust.in/gov-in/2023/02/Exposing-Indian-Citizens-Sensitive-PII-and-more/ Essentially if you give personal data to anyone, assume that there will be a leak before or later. jaclaz

Interestingly, in the US and in the UK, it won't be a thing in EU countries any soon, there are serious doubts about its compliance with GDPR and other EU privacy related Laws: https://www.independent.ie/business/technology/no-instagram-threads-app-in-the-eu-irish-dpc-says-metas-new-twitter-rival-wont-be-launched-here/a1927220337.html It is not at all clear if there will be "blocks" of some sort on the app for EU citizens (or EU countries) or something similar. jaclaz

I treat official warnings from any of the government agencies depending on their contents, and BTW this is not a warning, but a recommendation, and (as said) its content is (vague) wishful thinking or generic advice. The note is BTW not particularly tailored to Kaspersky or to any other particular software, it talks of "information technologies supplied by firms connected to the Russian Federation". Without an official list of "firms connected to the Russian Federation" it is meaningless, yes, we know (from other sources) that Kaspersky may be one of these firms, but for all we know, any number of other software or hardware related firms could have similar connections. And the actual recommendation is about conducting an analysis of the risk (Risk Assessment), which is essentially a simple (or complex) document (not entirely unlike some of the ISO9001[1] ones), where someone uses senseless formulas or reasonings on partial, incorrect, non-existing or invented data to derive a (wrong or right, usually pre-determined) conclusion (subject to revision/reviews/changes) , it is only (bad, useless) bureaucracy, the pool where consultants with dubious qualifications and (officially qualified but often clueless) auditors like to swim. Unlike Laws or technical norms (where formulas are given and data needed is specified, and processes are detailed) a generic risk analysis document: https://drata.com/glossary/risk-assessment can be made according to no less than 6 different principles: https://drata.com/blog/risk-assessment-methodologies and then the actual data and algorithms you can use in the document can be almost anything. jaclaz [1] the actual norm for IT security is ISO 27001 (and 27005) that not unlike many other ISO ones is pretty much "vague" and open to different methodologies/approaches: https://advisera.com/27001academy/what-is-iso-27001/

You evidently misunderstood me, I wasn't talking of your post, which is just pointing to some info, it is that recommendation from that Italian agency that could have well been written by Chat GPT, this way the good guys that protect our infrastructure could have had more free time to do the whatever they are doing. jaclaz

JFYI (I can read that Italian article without translation) it is only a generic, empty/obvious and meaningless "wishful thinking" kind of post, it recommends to proceed to a new risk analysis and to consider evaluating different strategies, while stating how it is fundamental, in order to not weaken the protection of the organizations, that during this process the continuity of security service must not be interrupted. Writing this kind of meaningless crap could be a good use for Chat-GPT, BTW. jaclaz