jaclaz

Is it a system image (i.e. a .vhd or .vhdx file)? If yes it can be normally mounted in the plain (10) OS, like any other vhd(x) disk image: https://www.techrepublic.com/article/how-to-access-a-system-image-and-restore-individual-files-using-windows-10s-native-vhd-support/ jaclaz

No idea, it works from here (Basilisk/Serpent) up to the basket (Warenkorb) and up to the page where you have to give your data/register. There is however a page Versandkosten: https://www.brainzap.de/versandkosten#versandkosten but there are only tariffs for Germany and EU, our friends on the other side of the Mare Britannicum seem to have not been considered. Dave however may look for one on local online shops or on e-bay UK, as an example here is one allegedly shipping from Wisbech, United Kingdom: https://www.ebay.co.uk/itm/155420573507 jaclaz

Well, I am notoriously cheap (besides old and grumpy) but I find that a a "high end" simple cable (shielded) costing 80-100 Euro (like the Thermaltake one) is "pure folly". Risking a few Euros for an el-cheapo one could be a fun experiment, if it doesn't work you have overpaid a short USB 3.0 cable ...

The "high quality" ones cost one arm and a leg, though. I have seen also some "riser" (that is the term to use in search) cards that (mis-)use a USB cable. They are used (generally) for mining rigs, cannot say if they can be used in this specific scenario, the original idea is being able to use several graphic cards/GPU's, search for "Riser Ver009S", or "riser ver010S" example: https://www.brainzap.de/crypto-mining-equipment/mining-equipment/pci-express-riser-adapter/brainzap-pci-express-riser-ver010s-plus-mining-karte-adapter-x1-auf-x16-usb-3-0-mining-v010s-10240 Here is a comparison between various types: https://videocardz.com/review/pci-express-riser-extender-test They are slower, but eliminate the problem with power lines as they are powered separately. DeLock (to name an usually reliable brand) has many different models on its catalogue: https://www.delock.com/produkte/G_1176_Riser-card.html jaclaz

And are you going to share a link to the actual driver or at least to the specific Reddit post ? jaclaz

If you are completely new about programming, and if it is for 9x I would advice you look into Delphi (basically what everyone else does NOT use). There are lots of (old, which in this case means good) books and manuals for the language that you can find used/second hand and - once you become familiar with it - you can still use your acquired knowledge using Lazarus (which is open source but only early version of it are Windows 9x/Me compatible) on newer OSes. I am not a programmer (at the most I can manage to half-@§§edly put together some scripts) and C and its variants (which are the alternative) are (to me at least) completely incomprehensible, Delphi is usually at least readable. For simple programs it is probably not worth the effort and I would go for some simpler environments, such as Autoit, up to 3.2.something it was windows 95 compatible. jaclaz

fltmgr.sys could be anything. In my ignorance I would ignore it and until it happens again (and again) sleep well without worries. jaclaz

It could (or it could not) be. The disk is seen (directly or indirectly) as SCSI. There is *something* in the SCSI commands that was limited to 32 bit in older implementations, but no idea if it is connected/applies to your case. Since the disk is not seen in Disk Manager you may be right, or maybe not, I don't really know. jaclaz

I thought that using "Scan for hardware changes" would have worked, maybe it depends on the controller or on the OS or on both. jaclaz

Maybe HotSwap would be useful? http://mt-naka.com/hotswap/index_enu.htm jaclaz-

Yep, though still we don't know if the issue is there or it is in the controller inside the external case. Dave-H is known for having in the past managed to find the least compatible to anything external case , JFYI: https://msfn.org/board/topic/173265-formatting-an-external-drive-using-different-interfaces/ https://msfn.org/board/topic/173642-mkprilog-batch-to-access-a-same-disk-under-two-different-interfaces/ maybe he is trying to set a new record... (besides, he is already the forum champion in "let's find the laptop with the least supported touchpad ever", but that's another story ...) jaclaz

There is a third possible position, let's call it "climate change ignorant" or ,"climate change agnostic" someone that believes that noone actually knows what is happening[1] (and why it is happening). [1] or not happening

Not my field of expertise (I always used and still use only IP static addresses on my networks, bar the Wi-FI). The 169.254.x.x nebtmask 255.255.0.0 is "normal", it is a so-called APIPA address, it is actually a symptom, it means essentially "the network stack is set to get an address from a DHCP server, but none could be found, so I am using temporarily this address": https://www.techtarget.com/whatis/definition/Automatic-Private-IP-Addressing-APIPA But what happens if you manually set a static IP address? If everything works, than the issue is only related to the DHCP, if it doesn't there may be "wider" issues with the network stack. What do you get with: ARP -a in the case of a missing DHCP and in the case of the static address? jaclaz P.S. Also, check the Registry in: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VXD\DHCP in it there may be one (or more keys) like DHCPINFO00, DHCPINFO01, etc. Save/backup them (just in case), then delete them and reboot.

Well, the good ol' method was to use a car tail lamp, double filament, 5/21 Watt @12V. The 21 W on the 12 V rail, the 5W on the 5 V one. On older PSU's you had to have some load on both rails.

Hmmm. Never heard of Plop, right? https://www.plop.at/en/bootmanager/features.html

No, not really. If you connect the disk directly you bypass a number of things, including the connector, but also the enclosure controller and/or the e-sata card you may have on your PC. If a connection (intended as EVERYTHING is between A and B) works with a given OS BUT does not work with another OS it is NOT an issue of the cable or of the connector, it is an issue with the software (driver of the controller or *something else*). You have three different layers of possible incompatibility: 1) the disk partitioning style (that is NOT supported in XP if not through the Paragon software) 2) the disk size (that may or may not be supported by the OS) 3) the driver of the controller and/or of the add-on e-sata card (that may or may not in the version for XP have the same capabilities than the version for 10), I have seen you posted a reference to a (pseudo/virtual) SCSI path: \Device\Scsi\SI31121Port5Path0Target0Lun0 and Scsi devices are known (not necessarily it is your case) to have drivers using 32 bit-limited Scsi commands. If the enclosure has an external power supply, you could try one of these simple cables: https://www.startech.com/en-us/cables/esataplt18in (of course if you have a free sata port on the motherboard) jaclaz

No, strictly speaking, you haven't. You partitioned it as GPT or - even better - you initialized it as GPT. Then you created one or more partition(s) or volume(s) in it, and then formatted this/these partition(s)/volume(s). The sector address you are having an error with is not very high 0x5bc5e0 is 6.014.432 which multiplied by 512 (sector size) makes 3.079.389.184 bytes offset, it doesn't seem connected with the size of the disk. Anyway, if you haven't already done so (i.e. if you have now only one huge 3TBish single partition/volume), I would try to make two partitions on that disk, the first one within the 2 TiB/2.2TB limit, and a second one for the rest. This should eliminate or reduce possible conflicts with this (or that) 32 bit limit, at least for the first volume/partition. About the HFS error, if a find is not found and if the service doesn't start, not a surprise that it doesn't show in Disk Manager. You will have to trace with filemon or procmon to find which file is missing/is not found (if any).

I have not much experience with these settings, but I remember how sleep on Vista and 7 can be troublesome. Have you already gone through the steps proposed here?: https://www.vistax64.com/threads/power-options-and-sleep-mode-problems.63567/

Usually you choose it when you use the Open With, choose a program that is not in the list and check the checkbox "always open with this program" or similar, but a number of programs will also associate with a given file type when running, I believe. I think it is somehow intertwined with "file association": https://learn.microsoft.com/en-us/windows/win32/shell/fa-how-work jaclaz

Yep, it is now an old software, still available (as an example) on Softpedia: https://www.softpedia.com/get/Others/Miscellaneous/tiny-hexer.shtml jaclaz

I don't think that disk management/diskpart will allow you to shrink that partition. Personally I would use directly a hex/disk editor, but of course it isn't advisable if you are not familiar with one or you don't want to waste some time learning how to use one. In case you are interested, since you are also running XP[1], I would suggest you good ol' Tiny Hexer, optionally with my MBR view script: http://reboot.pro/index.php?showtopic=8734 Your mission, should you accept it , is to change four bytes in the partition table (second entry): 976771071=FF57383A should become 721614847=FFF7022B so, actually, three bytes. jaclaz [1] it should work just fine in Windows 7, but if I recall correctly Windows 7 has a mechanism to protect the MBR so - again if I recall correctly - the disk needs to be put offline (or maybe it was the PBR that had this protection? )

I cannot say "why" you have that situation, but you have a hole between sdb1 and sdb2. Please follow me. sdb1 starts on sector 2048 (right) it is 67149824 sectors in size which is evenly divisible by 8 (as the device has a physical sector of 4096 bytes it is 8 x 512 bytes or 8 logical sectors), disk management/diskpart normally creates "rounded to megabyte" partitions and 32788x1024x1024/512=.67149824 so this is also "right". sdb2 starts on 67167765 but, (and this is "queer") before it you have 2048+67149824=67151872 so WHAT is this hole of 67167765-67151872=15893 sectors? sdb2 is a an extended partition, the unused sectors for the extended partition would anyway normally be - again - 2048m so everything would remain alignedm but sdb2 has an odd number of sectors, 310423995, which make no sense to me, unless this extended has been aligned to the cylinder (I just checked it is, it virtually starts at CHS 4181/0/1 and end - like the logical volume inside it - at CHS 23503/254/63). Also, sdb5 is the actual logical volume inside extended, but it starts at 67167828 and 67167828-67167765=63 which is the "old" offset. So, it seems to me like you used the "new" Windows 7 partitioning for just the first partition and then you used XP (or another "old" convention tool) to create the extended and the logical volume in it. jaclaz

No, no, no. Partition alignment has nothing to do with partitioning style. It is not particularly smart to have a GPT disk aligned to cylinder (i.e. with 63 sectors before first partition) but it is technically possible, as in most implementation of GPT at the most 32 sectors are used for the GPT Partition Table (which is not 2048 sectors) the GPT uses: LBA 0 Protective MBR LBA1 GPT header LBA2 - 33 Partition entries (each takes 128 bytes so 32x4=128 max number of partitions) So 34 sectors for the whole stuff. Windows VIsta and later when partitioning will align to 2048 sectors INDEPENDENTLY from the style (MBR or GPT) you choose. You DO NOT want to use GPT: GPT is not compatible with BIOS and it is not compatible with XP booting, ONLY use MBR. You can have alright a MBR style partitioning with Mbyte alignment BUT you should NOT use EVER the XP disk management IF you have on the disk logical volumes inside extended. The XP disk management has no issues with primary partitions, only logical volumes inside extended are at risk. jaclaz

Well, for whatever reason your initial partitioning did not respect the "new" paradigm (that - just for the record - is not sector 64 but rather sector 2048). If you are dual booting XP and 7 you risk (unknowingly) to lock yourself out of all the logical volumes inside extended: http://reboot.pro/index.php?showtopic=9897 (if you are using the "new" alignment AND use the XP disk management, once you have parittioned with the new alignment NEVER use the XP disk management on that disk/ssd) The old paradigm was "align to cylinder" (hence 63) while the new one is "align to Mbyte" (hence 2048 as 2048x512=1048576). The setting for this behaviour is - since Vista - in the Registry, it is a set of four keys in CurrentControlSet (that could be ControlSet001 or ControlSet002): HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment\LessThan4GB HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment\Between4_8GB HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment\Between8_32GB HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment\GreaterThan32GB The defaults are 1048576 for the last three and 65536 (128x512=65536) for the first one, for smaller devices, as said it started with Vista and all later Windows use the same, here are some details for Server 2008: https://frankdenneman.nl/2009/05/20/windows-2008-disk-alignment/ The 64 sector offset was used by a few hard disks, but is not common. Check that you have these keys with the default values in your Registry, then if you partition normally using Windows 7 Disk Management the partition will have the "new normal" 2048 alignment. jaclaz

It seems like you miss: HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\Open With default should be set to {09799AFB-AD67-11d1-ABCD-00C04FC30936} See also: https://www.nextofwindows.com/how-to-add-the-missing-open-with-option-back-to-context-menu-in-windows