jaclaz

Just in case, some details/explanation of IFEO: https://www.dedoimedo.com/computers/windows-ifeo-debugger-gwx-more.html jaclaz

LBA48 has nothing to do with that. Before LBA 48 (which came with ATA-6 in 2002) the method in use was LBA 28 that did not allow to address more than 128Gib/137 GB. (2^28-1)*512=137,438,952,960 Anything that can address more than that has LBA48 alright. jaclaz

I don't understand. There aren't (AFAIK) any problems, the (serious) bug is in XP (and presumably earlier) Disk Manager. We can put it this way: 1) when the XP disk manager was created/programmed the ONLY convention for disk aligment in use (according to the usual MS arrogant paradigm of "all is mine") was to head/cylinder, for *some reason* the tool was coded with the assumption that it would only deal with disks partitioned and formatted along that convention (and by MS tools) 2) when the Vista disk manager was created/programmed they introduced the new MB convention, but since 99.99% of the systems already in use had the old one, presumably they tested the new disk manager with both the existing common situation of millions of disks and with the new convention they had just introduced Historically, third party tools for DOS or Windows tended (understandably) to work similar to the way the Microsoft tools worked, so I wouldn't be surprised that this (or that) third party tool prior to Vista may have some issues with the new 1 MB alignment. Please note how whilst the "old" cylinder/head alignment was originated (in DOS) by some peculiarities in the actual way the (early) mechanical hard disks worked (that by the time XP came out weren't needed at all, as hard disk had changed their architecture already since years), the 1 MB is a completely arbitrary one, what may or may not make a difference is alignment to a multiple of sector size (so 4096 bytes for newer disks), any multiple would have done as well, and even if they had went ahead, and have only NTFS (which is inherently aligned, while FAT is not unless especially created so, impossible to do with MS own tools only) the cluster size (to make sure to have an integer number of clusters in a volume and no slack space) could have been 64KB (the max cluster size MS uses in its filesystems) or - at the most and leaving some provisions for larger clusters in the future - 128KB. . jaclaz

No. AGAIN clusters have NOTHING to do with disks (and a lot to do with volumes and filesystems). See here: https://kb.romexsoftware.com/en-us/3-general/51-512n-512e-and-4kn-drives https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/support-policy-4k-sector-hard-drives You want to look at values of Bytes per sector: Bytes per Physical sector: and nothing else. It is confusing (and very unfortunate) that the built-in command in Windows to get these values is actually a tool dedicated to gather info on the volume/filesystem (and actually reserved to NTFS only). There seems to be a "more proper" way to look at this info, that works on the disk (not on the NTFS volume) using Powershell, but only on WIndows 8 and later: https://superuser.com/questions/1040865/how-can-i-get-the-physical-sector-size-of-a-drive-that-doesnt-have-any-recogniz Get-Disk | Format-List In Linux, fdisk -l should do. A 512n disk will be seen by any OS as having 512 bytes/sector. (internally it uses 512 bytes sectors) A 512e disk will be seen by any OS as having 512 bytes/sector.(internally it uses 4096 bytes sectors that are "fractioned" into 512 bytes ones transparently) A 4kN disk will be seen by any OS as having 4096 bytes sector. (internally it uses 4096 bytes sectors) jaclaz

Yes , to be more accurate what "may" happen is the following: 1) in XP the "standard alignment is on cylinder/head, so primary partitions will always start on a CHS s=1 h=0 or 1 and end on a CHS s=63 h=max (usually 254, in a nx255x63 geometry) 2) this applies also to logical volumes inside extended, the net result is that each volume will have an offset of 63 from the relative Extended MBR 3) in Vista and later (over a certain - small - size of the device) an alignment of 1 MB (2048x512=1048576) is instead used, and it also applies to the offset to the relative Extended MBR of logical volumes inside extended 4) If you create the Extended partition and logical volumes in XP or however with 63 sector alignment you won't have any issue with both XP and later windows Disk Manager 5) but if you create the Extended partition and logical volumes under a later OS or however with 1 MB alignment, the XP Disk Manager may decide, when performing even an unrelated operation to disk (as an example changing the bootable status of a primary partition), to check/re-calculate the offset of the logical volume from the relative Extended MBR, and silently delete the logical volume entry in the EMBR: https://web.archive.org/web/20160308045741/http://www.dcr.net/~w-clayton/Vista/DisappearingPartitions/DisappearingPartitions.htm See also: http://reboot.pro/index.php?showtopic=9897 The logical volumes are still there (of course) but they are not anymore addressed in the EMBR chain, it is possible to recover them by finding their extents and re-writing proper entries for them, but it needs some time and dedication.. jaclaz

There are also these: https://github.com/DanysysTeam/SFTA https://github.com/DanysysTeam/PS-SFTA the secret hash seems to be not that much secret if it can be generated by a Powershell or Powerbasic script. jaclaz

Final statements: Sector size is determined by the manufacturer of the hard disk and cannot normally be changed (some hard disks, through a proprietary manufacturer tool may allow to switch from 512e and 4kN or viceversa). Some USB adapters/bridges/enclosures might translate sector sizes (from 512 to 4096 or - maybe - from 4096 to 512), in some cases it may be possible to change the behaviour of the chip inside the bridge through a proprietary manufacturer tool. Cluster size is a characteristic of the file system and is normally determined/chosen at the time of formatting a volume. Its value is determined by two fields in the BPB (Bios Parameter Block), usually called "Bytes per sector" and "Sector per cluster", multiplying them you obtain the cluster size, examples: Bytes per sector=512 Sectors per cluster=8 Cluster size=512x8=4096 bytes Bytes per sector=4096 Sectors per cluster=1 Cluster size=4096x1=4096 In the MBR there is NO data related to clusters[1], ONLY about sectors (as seen by the OS), hence the limit of around 2.2 Tib for 512 bytes sectors becomes, when using 4096 bytes sectors (8x), roughly 17 TiB (8x)[2] @Milkinis A 512 (old, traditional) disk has internal physical sector size of 512 bytes AND exposes 512 bytes externally. A 512e disk has an internal physical sector size of 4096 bytes BUT exposes 512 bytes externally. A 4kN disk has an internal physical sector size of 4096 bytes AND exposes 4096 bytes externally. jaclaz [1] AGAIN clusters are determined in the file system, the MBR knows NOTHING about the file system, thus NOTHING about cluster size [2] and this is not how jaclaz "sees it differently", it is how it is

Well, no, you need a similar one (in the sense of one that makes the same translation or no translation) if you want to use the disk normally, but data recovery is possible no matter if the sector size exposed is different, by using *any* other enclosure or connecting the disk drive directly to a computer. Of course in this case you need another suitable disk to copy to, but this is standard procedure when recovering data. jaclaz

As always, it depends. Proprietary enclosures (those disks "born USB" such as many WD and Seagate external units) may have some form of identifying the disk in it (the real issue may come out if you use the provided encryption feature) but, also, some have "non-standard" disks inside (without an actual SATA connector) and in case of problems you would need to trace and solder to the PCB, example: https://blog.acelab.eu.com/pc-3000-hdd-how-to-solder-a-sata-adapter-to-the-usb-western-digital-drive.html Third party enclosures/bridges are simpler as the disk itself is a standard one, and there is no "disk ID matching) so it should work the same in another enclosures (that behaves the same, i.e. either performs or does not perform a sector size translation, and this may happen only when the disk is over a given size or not work at all), here is a related report: https://goughlui.com/2013/10/02/experiment-usb-to-sata-bridge-chips-and-2tb-drives/ There are in any case (though the el-cheapo ones might have size limitations) SATA to USB converters, normally used in data recovery or for temporary access to a disk to be later mounted internal, that work with *any* disk. Just like enclosures, it is extremely difficult if not impossible to know (as the manufacturers do not include this info) how a given bridge will behave. Some chips can be re-programmed using their manufacturer tool (some of them are available for Asmedia chips, as an example) but as well the manufacturer of the bridge or enclosure won't say which chip is used in their product. If the disk is functional, you can always recover the data at file level, even if there is a sector size mismatch, using suitable tools, whether it would be possible to directly restore it may as well depend on a number of factors, hard to say. jaclaz

@Saxon If it (ever) booted it is not a UEFI/BIOS issue. 0x0000007b is inaccessible boot device, so whatever boot device is chosen at the time is likely involved, the error (generally speaking) comes for a missing or mismatched or not working driver. That specific MSI USB drivers can work on a HP laptop would be a strange (I would call it unique) coincidence. And of course you are not going to tell us what it is? jaclaz

Seemingly the guy on that channel uses a "customized" .iso with NTlite adding the Windows 7 MSI USB drivers for his specific motherboard/system to the boot.wim. (of course without giving any meaningful detail on how exactly this was done). He then proceeds to redistribute the modified .iso. So the news are that - [1] - a .iso with a boot.wim with integrated specific MSI USB drivers has issues in a HP laptop. If the .iso is used on a USB stick, which is probably the boot device at the time the BSOD 0x0000007b happens it could well be due to the (wrong/mismatched/whatever) USB drivers. jaclaz [1] Please insert here an adverb, choose among: a. surprisingly b. unexpectedly c. obviously

Of course cannot say for sure, what we know is that XP has had no issues with external USB disks exposing 4k sectors, which for all it matters are the same as 4kn. The 17 TB limit is a theoretical one, the capacity of the field in the MBR is that one, and you are actually using it already when you reach the 2.2TB "limit", so that in itself poses no issues. The NTFS in itself (like *any* filesystem) should depend not on sector size, but rather on cluster size, and XP is included in the OS's where NTFS volumes up to 256 TB are supported: https://support.microsoft.com/en-us/topic/default-cluster-size-for-ntfs-fat-and-exfat-9772e6f1-e31a-00d7-e18f-73169155af95 this does not mean that a number of MS (or third party) tools might have issues with largish volumes. A good example (unrelated) is the mentioned issue with "new" alignment and Disk Manager incompatibility with logical volumes inside Extended partition (that BTW MS never publicized, let alone fix). My "Sure, what did you expect?" note was more "general" and related to the fact that both XP and 7 (and Vista) are not supported anyway anymore and MS has spent time in the last few years to remove references to them and re-writing articles/Knowledge base/etc. to exclude them from lists of supported OS. jaclaz

Another good thing that R.Loew left to us . jaclaz

Sure, what did you expect? jaclaz

I don't understand, you succeeded with the "normal" Vista .iso? But the one you Frankensteined does not work? Never heard of taking a Windows 7 install .iso and replacing in it the install.wim, it may be possible to make it work, but I presume that a number of other changes will be needed. Anyway, the 0x0000007b is "Inaccessible boot device" which - usually but not always - is related to the lack of a proper SATA driver. 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