jaclaz

From what I have seen, besides the MS fanfare, the best definition so far is by Vinifera here: https://msfn.org/board/topic/183672-windows-11-validation-os-first-impressions/ if even diskpart doesn't run in it, I wonder what the highly specialized technicians on the factory floor would use it for. Maybe it is just an early/preliminary release and the good MS guys will fix it in the future, but personally I am not holding my breath waiting for that. jaclaz

JFYI, a hdd caddy is usually not an external (USB) enclosure, it is a replacement for the (internal) CD/DVD drive, it looks *like* this: https://hddcaddy.com/en/content/6-what-is-hdd-caddy https://hddcaddy.com/en/accesoires/175-sata-hdd-caddy-95mm-universal.html jaclaz

The issues are usually not related to the actual printer drivers, Brother's (as printers) are compatible with many "generic" drivers, if I recall correctly they are fully HP compatible, but the scanner (and the PC-FAX) part and some other "advanced" features that might be problematic, even if they are TWAIN compatible. There is - JFYI - a (Commercial) software that was born specifically to allow people to use older scanners that have no longer drivers for new OS's: https://www.hamrick.com/ (never used it personally) that lists the MFC-240 among the supported ones: https://www.hamrick.com/vuescan/brother_mfc_240c.html#technical-information jaclaz

You can try with some additional (double) quotes, see here: https://techcommunity.microsoft.com/t5/windows-powershell/batch-file-filename-with-ampersand-amp/m-p/3284432 but cannot say if similar trickery will apply to your case. jaclaz

Very likely there is no "MBR emulation", they simply are "native" 4K sectored disks that expose 4 KB sectors, plainly MBR partitioned or however the actual USB enclosure exposes 4 KB sectors. This shifts the MBR limit by 8 times (4096/512) so that the maximum accessible area becomes up to around 16 TB. Such disks won't be bootable (from BIOS) without - maybe - a "special" loader, as most (if not all) MBR loaders assume 512 Bytes sectors. See also this other thread: jaclaz

Possibly the simplest would be plain batch using nircmd: https://www.nirsoft.net/utils/nircmd.html should have all the commands you need. Probably next (what I would use, mind you not necessarily the best idea) would be either AutoIt or AutoHotKey, as AFAICR they have many easy functions to manage wiindows. This exists (written in AutoHotKey, source included): https://sourceforge.net/projects/winsize2/ But I think there are many more "dedicated" freewares/low cost sharewares for this, though finding one with all the features you want may take some time, as I think many are single display only, anyway a couple ones: https://www.displayfusion.com/ https://toddnelson.net/ https://github.com/Todd1561/TANWindowMgr jaclaz

I missed it , I thought your post was about VSS. However, as a side note and JFYI, there is still something "queer" or at least not fully explained in XP/Explorer/NTFS: http://reboot.pro/index.php?showtopic=19746 @justacruzr2 please ignore the above link it is just a digression jaclaz

Are you talking of Last time accessed? It is a Registry setting, it is a feature of NTFS that can be toggled on/off. Check: http://shiftwiki.nl/disablentfsaccesstime jaclaz

Typically it is the MCC that fries in my (personal, little) experience, this usually results in a multi-pin chip with a burn hole on it, but if a component was missing altogether it was more likely a TVS diode (there are generally two of them on 3.5" disks, one on the 5V and one of the 12V rail), see this: https://www.hddzone.com/hard_drive_pcb_components.html but it cannot logically be the TVS as if the component is missing there is no short anymore, and your PSU didn't go in over protection mode: https://community.wd.com/t/hdd-tvs-diode-faq/14692 maybe the TVS actually fried and *something else* (a nearby component) popped off. jaclaz

No you weren't, you probably had a different issue. There is no software on earth that can recover ANY data from a disk with the PCB "fried" (which is what happened to the OP). jaclaz

It is back online, now. jaclaz

Corollary (old Italian/Tuscany saying): "Le bestie non conoscono feste comandate" which translates roughly to "Animals don't know about Sundays or holidays". jaclaz

Due to the next 5G cellular introduction, here in Italy they are moving television to HD, DVB-T2, H265 trasmission . While at home it is possible (but not easy particularly for the older people) to retrofit an external decoder to most "old" TV's , the only possible way out for (say) hotels, hospitals and similar (short of throwing away and buy new tens or hundreds of otherwise perfectly working TV's, many only 3-4 years old) is to install a "MUX", a sort of centralized converter that AFAICT has a serious cost limitation (per channel). Roughly we have some 200-250 channels (of which - maybe - 50 at the most actually *somehow* worth anything). A retrofit decoder (that has the issue of having a separate remote) is anything between 30 and 60 Euro. A new TV (non -smart, "normal", 32" size) is anything between 200 and 300 Euro. A 16 channel (yes, only 16 channel) MUX is in the order of magnitude of 2000-3000 Euro, additional channels should be around 1000 Euro every 8. Only a minority will be willing (or be able to) choose the "keep the old TV" possibilities, just think of the amount of (definitely not eco-friendly) waste that will be generated . Essentially we will be paying a "tax" AND senselessly increase electronic waste to let the kids[1] have faster and better youtube and tiktok. jaclaz [1] but not only them, many adults will have better streaming videos and football matches zoom calls that are essential for their businesses

Older versions of ccleaner should install and run on Win95 and on Win 98, should be 1.32 for Win95 and 2.36 for Win98: https://community.ccleaner.com/topic/27011-ccleaner-for-windows-95/ https://msfn.org/board/topic/178116-windows-95-support-and-software-information-2019/ jaclaz

Oww, come on , no need of any conspiracy theory . Why not 2000, WIn98 or Windows 95 (OEM 2 or 2.5) or BeOS? Someone just made a list and omitted several older or less used OS's, I just offered you a possible explanation on why the line was drawn at 8. And no, Windows (All versions) would have caused NT 4.00, Win3.x and Windows 95 first release users to whine. jaclaz

I think it is just like there isn't XP or Vista on the list, 7 is considered "end of life" since 2020, maybe 8 and 8.1 are still there because "extended support" for them ends in January 2023. jaclaz

Well, there is very little to write on the specific topic. It simply works. It is essentially an additional choice/possibility, personally I prefer (on USB as well as ln any other device) to use (if an XP or a 7 is involved) this approach, as it allows booting grub4dos without mingling with the MBR and following few sectors and because (though nowadays it is far less common) the grub4dos MBR code might have some incompatibilities with a given BIOS (making, whilst the MBR->PBR->NTLDR->BOOT.INI chain is more likely to be compatible (at least on not recent hardware) as *any* motherboard would have been booted to XP or 7. The even lesser known fact is that the Windows 7 BOOTMGR (but not AFAICR later versions) parses the "old" XP BOOT.INI just fine for the entries that are NOT leading to a windows (i.e. NOT the (multi) ones), see here: http://reboot.pro/index.php?showtopic=19730&page=2 https://msfn.org/board/topic/140412-release-siginets-plop-usb-boot-manager-installer/ So by adding or editing a simple text file you can add (or remove) the option to boot to grub4dos to both "normal" XP and 7 installs. jaclaz

As said, I cannot confirm (nor deny) anything, I am only pointing you at the little I know on the matter, based on what I read here and there. All the evidence I could find point to the conclusion that the "switch" between IDE and AHCI/SATA needs to happen in the BIOS, whether this needs a modified BIOS or can be triggered (I presume only on some BIOSes/chipsets, not on all of them, but the given resource is actually about the specific ICH-7) via direct editing/poke the PCI settings, at least for Linux. Both the above possibilities are rather low-level and complex, which makes me believe that a much simpler, I would dare to say obvious, solutions such as a Registry edit or the modification of a .inf file cannot possibly work. I have NO idea on how a IDE, let alone SATA/AHCI driver actually works, but I presume that loosely at every request from the OS it checks something (the 8-bit MAP—Address Map Register at offset 0x90 in the PCI area of the *whatever* hold these data) and, depending on what it finds there, issues this (or that) slightly different command, and likely the chips themselves additionally check that value/register. This said, I wouldn't exclude that if you look at your PC with enough intensity (evil eye ) you can switch the settings, but I would classify that event as highly improbable . jaclaz

I don't know, from your previous reports it seems that the "culprit" is the disk (hd2) or the volume (hd2,4) (the disk with 30401 cylinders), yet it doesn't seem from the partinfofw data to be in any way problematic (or at least not more problematic than the other disks). I am afraid I wasn't clear, you don't really need to "save from Tiny Hexer" the text or html of the view, the MBR_Backup makes a 1:1 (or dd-like) copy of the relevant sectors, with "appropriate" names and I can open them in Tiny Hexer and view them through the structure viewers I am starting to suspect that there is some incompatibility between grub4dos and your PCI IDE controller. Right now (question) if I get it right, the only disk that you "really-really" need is the disk 0, connected to the internal IDE controller, right? And on that disk you have on C: a WIndows XP system that is bootable and on E: some data. If the disk can boot (alone) to XP you can add to your boot.ini a line: and copy to the C: volume the grldr file. This should be able to boot (to grub4dos prompt) without any other disk connected. Then try again to boot after having added the disk (the one with 30401 cylinders) only to the other on-board IDE. Does the slowdown happen? Then try again booting after having moved the second disk from the on-board IDE to the PCI controller. Does the slowdown happen? This way we remove from the equation the other disks and compare results for the same disk when differently connected. jaclaz

You can try adding two 27C4 lines BUT it won't work. See it like this, if it was so easy, why the Linux trick, the BIOS provision (missing in your case) or the suggested need of a specific BIOS mod? jaclaz

Hmmm, I don't know. Seemingly the HD0 is just fine (this should be the one you just re-partitoned). The HD1, HD2 and HD4 have the same issues (or non-issues): The Extended partition entry in the MBR points to sector 16065 (correctly represented as CHS 1/01/) first partition should normally be on 63=0/1/1 or, with the new MB alignment 2048=0/32/33, but it is perfectly possible that a whole head is reserved when making the Extended partitioning the first and only one. The entry for the volume in the EMBR is not balanced, the sectors before are 63 (correct, same as in the bootsector) that translates to 0/1/1, but the CHS entry is 1/1/1 (which corresponds to LBA 16128), this is IMHO strange, but it shouldn't be a problem. The HD3 is mish-mash, the first partition has 2048 (0/32/33) which is a sign that the partitioning was made with MB alignment, there is a hidden one head partition with ID21 (this could be the effect of using some USB related tools like RMPREPUSB), then there is a partition with ID0 (which for windows is a non-partition) that it is inside the extent of the first partition (this could be an effect of a grub4dos partnew command mapping an image, manually or by some "boot from iso/img" automation for some Linux distro). The volume on HD4 has another issue: Sec Per Clust: 128 (should be 8). But is the slowness/need to issue [ geometry --lba1sector (130) ] now solved (changing cables/HD settings)? about: The grub4dos should see: HD0=2 volumes/partitions HD1=1 volume/partition HD2=1 volume/partition HD3=3 volumes/partitions HD4=1 volume//partition total of 8. If instead of uuid you run: geometry (hd0) geometry (hd1) etc. you should be able to verify how many (and how many are seen as "invalid") volumes/partitions on each disk. If my guess is correct, the invalid ones should be the volumes on HD1, HD2 and HD4 (3 in total because of the unbalanced CHS/LBA) but maybe they are counted differently. jaclaz

The others are seemingly fine, it is only the disk 0 that looks problematic from what I could observe. The ID for the Extended Partition is 0x05 that means (if specifications are followed) "Hey, I am based on CHS addressing". The CHS address is saying "Hey, the EMBR is on sector 16,434,498" The LBA address is saying "Hey, the EMBR is on sector 29,543,538". Windows NT's normally use LBA addresses, so if (as I presume) the EMBR is actually on sector 29,543,538, and from then on everything is correct, the volume inside the extended is normally accessible/mountable. Grub4dos (or any other bootmanager) might look for the EMBR on sector 16,434,498, find it not, then try to find it via the LBA address and attempt to auto-correct internally the addreses/settings, and this could be the reason for the delay/issue (but not necessarily this is the actual cause, there may be other issue not detected till now). You don't need to secure erase the disk, there is no real reason for that, it would take time and stress the disk with continuous writing. jaclaz

First thing rest assured that MBR's and PBR's do not contain any "meaningful" (from a privacy/virus/malware point of view) info, they contain "common" code + a few specific data (geometry/addresses/etc.) that are not of interest to anyone and the Disk Signature (in the MBR) and the Volume Serial (in the PBR) that - while "unique" - are anyway random generated at partitioning and formatting times, so as well not particularly interesting. What you posted are the MBR's which - in a case such as yours with use of logical volumes inside extended are only a small part of the story. To check a primary partition/volume one needs: 1) the MBR (first absolute sector of disk) 2) the PBR/VBR (first sector of the partition/volume) To check a logical volume one needs: 1) the MBR 2) the chain of EMBR/EPBR's (first sector of the extended partition AND in case of more than one logical volume the "next" EMBR until all logical volumes are mapped) 3) the VBR Most of the common tools used in "booting matters" are very useful for primaries but not so much for logical volumes inside extended. About the 4 MBR's you included, they are seemingly just fine BUT DISK0.MBR has a few issues, the Extended Partition is marked as being type 0x05 (which is "CHS mapped") but its extents exceed the CHS mapping limit AND it doesn't fall on a cylinder boundary, then the CHS start data 1023/0/4 doesn't correspond to the LBA value, and there is a "queer" 66 sectors gap between the primary and the extended. Such wrong/unbalanced situation may well be an issue in grub4dos. The other ones look fine, the Extended Partition is marked as 0x0F ("LBA mapped") the CHS and LBA addresses are balanced, they are only unusual as they don't start "normally" at LBA 63 but rather at LBA 16065 (and in CHS at 1/0/1 rather than on 0/0/1). About DISK0, first thing one must understand is if the EMBR is on LBA sector 29,543,538 (the LBA address in the entry) or on sector 16,434,498 (the LBA address corresponding to the CHS entry 1023/0/4). Are you familiar (generally speaking) with hex/disk editors and their operation? You could get Tiny Hexer and my templates for it from here: http://reboot.pro/index.php?showtopic=21999 The MBR backup program by Wimb in the above should be capable of saving also the EMBR's and PBR's. Otherwise there is a little program by Terabyte that should be able to: https://www.terabyteunlimited.com/kb/kb-articles/explanation-of-the-partinfo-utility/ https://www.terabyteunlimited.com/downloads-free-software/#partinfo If you have Excel or a compatible spreadsheet program, you could also find of use my spreadsheet CHS_LBA to check the values : http://reboot.pro/index.php?showtopic=2959 http://reboot.pro/index.php?showtopic=2959&p=74116 Again, I know I am throwing at you a number of "advanced" tools/concepts, don't worry the whole stuff seems more difficult than it really is, but you will need some patience, the TLDR; is: I don't like (and I presume grub4dos also doesn't ) the way your DISK0 is partitioned, the issues - once understood - can be corrected but if you can (i.e. you are experimenting and the disk/volumes do not contain important data or you already have these data backed up) it would be easier to start from scratch re-partitioning the disk and recreating the volumes. jaclaz

The controller 27C4 in IDE mode becomes 27C5 in SATA/AHCI. AFAIK (frankly not a lot on this specific matter) the BIOS setting is simply a switch between 27C4 and 27C5 id, then the driver (either the plain IDE/ATA or the SATA/AHCI) is installed and started depending on this PCI ID. There is some Linux trickery (via GRUB) possible, but no idea if the PCI settings change "sticks" also in windows, nor if it actually works on your specific BIOS: https://dreamlayers.blogspot.com/2016/11/switching-from-ide-to-ahci-on-ich7-m.html I don't think that there is any other way than the above or a BIOS mod, this latter probably non-existing and in any case seriously dangerous/risky. You can of course try UNIATA, but no idea if it will give you any advantage: http://alter.org.ua/soft/win/uni_ata/ jaclaz

It could be due to several reasons, AFAIK: an incompatibility of some kind (between grub4dos and the controller or - more probably between grub4dos and the BIOS+specific controller) an actual issue with the disk *something* unbalanced in the MBR or PBR or both (or in the EMBR of the Extended partition), possibly in the BPB (some data in it may be used/checked when booting but not necessarily when accessing the disk/volume from a booted system, that usually does not rely on some lower level interface such as BIOS) a bad cable/connector (do not underestimate this, in the years I have seen intermittent issues of this kind, sometimes temperature connected, sometimes plain voodoo) The #3 is "normal" as you haven't mapped nor hooked anything. If you can avoid using this interface/disk it would be easier, as this - unless the exact cause is identified and the problem solved - represents an issue that may (or may not) affect the mapping and possibly then the functioning of Svbus/firadisk/winvblock. jaclaz