jaclaz

That would be Hel , it is actually hardware abstraction layer: https://en.wikipedia.org/wiki/Hardware_abstraction jaclaz

Maybe you are thinking of blackwingcat ? Maybe these? http://blog.livedoor.jp/blackwingcat/archives/1165914.html jaclaz

Sure , but specifically we do have the relevant page archived (thanks to the Wayback Machine) to give some context (and attribution of the "discovery" to cdob): https://web.archive.org/web/20160715151517/http://www.911cd.net/forums//index.php?showtopic=21702&st=129 jaclaz

I can only add that it works in DOS AND in NT systems, original release post: http://reboot.pro/topic/8528-how-to-patch-fat32-boot-sector/?p=73205 jaclaz

@dencorso Well, Ranish is DOS, I thought that the request was for something running under Windows XP. @Multibooter Yes, besides your (and other) DELL's, a number of IBM/LENOVO's and some HP's are known to use the 240 heads. But - again - if it is a primary partition, you can use *any* tool to create it manually and then use another program (like the suggested Ridgecrop's FAT32FORMAT) to later format it. If you want to go the "manual" way, you might find of use my little spreadsheet: http://reboot.pro/topic/2959-chs-lba-translations/ http://reboot.pro/topic/2959-chs-lba-translations/?p=74116 and/or my batch (though it won't work directly for a DDOed drive, it should be able to create the partition entry data, then you can use tiny hexer or another disk editor to copy it to the partition table): http://reboot.pro/topic/3191-mbrbatch-001-alpha/ last "original" (working fine on XP): http://reboot.pro/topic/3191-mbrbatch-001-alpha/?p=70584 the "modified/last" version by Lancelot (hopefully running on later systems and x64) can be found here: http://reboot.pro/topic/20213-found-mbrbatch-lancelots-version-x86x64/ jaclaz

You see, most "partitioning software" are (right or wrong) using a "Pareto principle". They are (not all of them, the best ones, a number of them are "terrible") only good in a large number of cases but tend to fail in some "edge" or "non-standard conditions". In this specific case it is not an actual limitation of the software, it is the way the whole stuff work which is problematic, it is basically a "chain of lies". What happens is that the actual hard disk (the actual thingy with spinning platters) actually has 255 heads (not really, but the hard disk on board controller exposes the actual internal arrangement, which is unknown as 255), the BIOS lies to the software/OS telling it has 240 heads and the DOS/9x software/OS cannot but adapt to this wrong info, whilst any NT system will blatantly ignore whatever the BIOS says and re-gather the info provided by the hard disk on board controller. The software usually creates partitions aligned to the cylinder, i.e. with "end sector" as the max sector per head on the max head (which derives from the geometry of the device), this was the old "MS standard" up to XP, whilst newer softwares would align to either "MB", which is the "new" MS standard starting with Vista or you can select between the two . So, in theory, you would need on NT a "filter driver" lying to the software in the same way the BIOS lies. For these cases the way out is manually making a partition table, nothing particularly difficult as long as you are wanting to make Primary Partiitions only, a bit more complex if you are wanting to make more complex setups involving Extended and Logical Volumes inside it. A better (easier) solution is using a virtual disk driver, under XP you should have no issues in using the VDK by Ken Kato, using a .pln descriptor file to set the "wanted" geometry, but unfortunately the VDK driver "hooks" at a level where, while it creates a "physicaldrive", this drive is not seen in Disk Management, a different partitioning tool may still (or it may not) see the virtual disk and be capable of operating on it, and - besides - the tool may well have been coded to have 255/63 as "fixed" geometry. I don't remember right now about any partitioning software/tool where you can choose/set the heads/sector geometry under XP, though I seem to remember there was a nice little tool that allowed "manual" or "almost manual" operation . But what would be the "actual use" of this tool? Remember that if you use a "wrong" HS geometry you will need to patch the FAT32 or the NTFS PBR to remove CHS access, because it won't boot XP or other NT systems on a machine that reports a different geometry, see: http://blog.clemens.endorphin.org/2007/12/removing-chs-based-access-from-windows_3170.html jaclaz

Are you sure it belongs here and not - just saying - "Funny Farm"? https://msfn.org/board/forum/20-funny-farm/ jaclaz

Not to be grumpier than usual, but the specific issue has already been diagnosed EXACTLY (and how to fix it provided) no need for further speculations: And - for the record - the partition is actually active (in practice it is the only thing that is "right": https://msfn.org/board/topic/178018-windows-98-hard-drive-cloning/?do=findComment&comment=1157698 This said, good to see you around . jaclaz

Only for the record, a number of Commercial programs, particularly of the DOS/WIN9x era, use hidden sectors or volume serials (and what not) to "validate", so if you have any of these you can only do a "clone". jaclaz

SCOOP! Destro is affected by https://en.wikipedia.org/wiki/Polydactyly jaclaz

I don't understand , I believe that anyone going to a GitHub page would first thing read the README https://github.com/Skulltrail192/One-Core-Api/blob/master/README my doubt was that by compiling the project source code the results would come out not similar to the binaries provided (actually they should come out identical, if the thingy is reproduceable). jaclaz

Hah, I like the idea of https://it.wikipedia.org/wiki/Affirmanti_incumbit_probatio So, someone could compile the source code and then compare the result to the contents of the pre-made binaries linked to. I doubt (but am far from being able to convincingly demonstrate it) that the source code, once compiled, will ever produce binaries containing file versions *like*: FileVersion 6.0.6001.18000 (longhorn_rtm.080118-1840) LegalCopyright © Microsoft Corporation. All rights reserved. or FileVersion 6.0.6000.16386 (vista_rtm.061101-2205) LegalCopyright © Microsoft Corporation. All rights reserved. or ProductVersion 6.0.6002.18084 FileVersion 6.0.6002.18084 (vistasp2_gdr.090806-2338) or ProductVersion 6.0.6002.18005 FileVersion 6.0.6002.18005 (lh_sp2rtm.090410-1830) We can use some statistics, however, on the results of running filever: 1 Copyright (c) PJ Naughter 2007 - 2015 All rights reserved. 1 Copyright (C) Microsoft Corp. 1981-2001 2 Copyright (C) Microsoft Corporation. 2005 63 © Microsoft Corporation. All rights reserved. 8 Copyright (c) 1993-2017 the Wine project authors (see the file AUTHORS for a complete list) 1 Copyright 1998-2014 ReactOS Team 218 Copyright 1998-2014 ReactOS Team, 1993-2014 the Wine project authors We can say that the project is largely based on Open Source and that less than 30% of the files in it have a MS Copyright (which doesn't of course mean that they are non-redistributable). jaclaz

Yep, at the time I got some 50 or 100 of them for free (but most probably it was a couple years later, at a time the cost of the sticks had plummeted) when subscribing I don't remember which advertisement contract. If the ones you got were similar to the ones I got, they were bulk-bulk, what is called "promotional twister", loosely like: https://www.flashbay.com/flash-drives/twister Not only, after having had a few of them that failed for no apparent reason, I tracked the appropriate "Manufacturer Tool" to see if I could revive those that had failed. All fine and dandy, found the right tool, made a total factory reset/wiping of a few sticks (like 2 or 3 out of 6 or 7) succesfully, Then on the fourth one the tool didn't work. Nor on the fifth. The manufacturer tool couldn't "connect" to the controller. The tool worked fine for a few other ones (although not all of them could be "revived"). Next time I had some spare time, I re-analyzed the two that weren't connecting and found out they had a different controller inside. Since I couldn't believe what the USB Genius was showing, I opened the case of a few failed ones and confirmed that although the external case/looks were the same, inside some there was a completely different controller/chip (different make). jaclaz

Ow, comeon , are you telling us that this guy Matt Ayers (Program Manager in the Microsoft Windows Client Performance group and "owner" of the ReadyBoost feature) LIED to us? : https://blogs.msdn.microsoft.com/tomarcher/2006/06/02/readyboost-qa/ The key is in the bolded part. And right from day one (including the above statement by the "owner") it made very little sense, compared to getting an adequate amount of RAM, and tests confirmed that: https://www.anandtech.com/show/2163/6 I am including the reference as it makes clear that even at the time (end 2006/beginning 2007) there was not much of an economic advantage, only the advantage to not having to open the machine (and possibly a very few cases where upgrading the amount of RAM wasn't technically feasible), and anyway it was related only to low RAM configurations. AND : https://www.tomshardware.com/reviews/windows-vista-superfetch-and-readyboostanalyzed,1532-6.html jaclaz

0x0000007b means "Inaccessible Boot Device", typically (there could be other reasons of course) it means that your machine is SATA (and a SATA disk is used) with the BIOS set to SATA (as opposed to "Legacy IDE compatibility mode" or similar AND your XP CD does not have integrated the SATA drivers. Can you post the make/model of the motherboard? Very likely there is a setting in BIOS that needs to be changed (if you are OK with IDE mode, which is slightly slower in disk access/transfer times), the alternative being that of integrating/slipsteaming to the install CD the appopriate SATA drivers or installing them with the "F6 floppy" method while running the main install. jaclaz

Cryptic? Definitely. Poet? <- that is the question, the debate is whether Vogon Poetry counts jaclaz

Your explanation is even more cryptical than the original. jaclaz

Well, maybe you didn't buy any of the (initially way overpriced, in some cases with double or triple than "street prices" for corresponding devices) devices that were certified/sponsored by MS. Gains were only visible if you had in Vista the minimum amount of RAM MS put in requirements, 512 MB (you know that number that you need to double to have a minimally working system and quadruple to have a fully working one). jaclaz

Not only I have no real reason to believe you , even if I wanted to, I fail to understand what you mean. Anyway the cited article is obviously a widely speculative one, a so called "opinion piece", but the proposal/idea in itself does make some sense (which is the actual issue, given the propension of the good MS guys to only take senseless "shifts", it is improbable that they will choose this one) . jaclaz

Well, no, there has been a misunderstanding. After having copied the third sector of the VBR (sector 65) that went OK., you need to test the bootsector, i.e.: root (hd0,0) chainloader +1 boot it should boot. Then you need to copy the MBR (sector 0), only after you have it copied you can test the MBR, i.e.: rootnoverify (hd0) chainloader +1 boot You don't need to try and get a copy of the MBR, I already provided it (with your partitions data) in the form of the file Sector_0.bin. Do re-read the previous post, you ran command #1 but then did the test intended after the command #2: https://msfn.org/board/topic/178018-windows-98-hard-drive-cloning/?do=findComment&amp;comment=1157673 jaclaz

No, I wasn't referring to the disconnection and reconnection of a PS/2 mouse (though normally modern motherboards have electronic fuses on PS/2 ports), and anyway that is the single experience of your friend, single point anecdata. I have a cousin (actually the husband of my cousin) that once disconnected a PS/2 keyboard and then reconnected another one with the PC on, and the new keyboard worked just fine, until eventuallt the motherboard caught fire because of a lightning (that one missed the postillion but got the PC ) 1:1 jaclaz

Well, you have also to wait several minutes for the capacitors to self-discharge AND ground yourself (with a anti-static wrist band or similar) before touching anything inside the case, if you are going along the "theory of operations". The only description for this sentence is "electro-technical terrorism" . Of course the motherboard may have been damaged by not following to the letter the procedures, but "big chance"? Come on ... jaclaz

I re-checked and yes, my bad , there is a little bug in the parsing of dd , grub4dos allows using [TAB] completion on command line after the slash, BUT the dd command actually needs "full" path, i.e. including the device. Adding the leading (fd0) should work. As well, once rooted to the device, you can use empty brackets (that mean current root), i.e.: root (fd0) dd if=()/Sec_6571.bin of=(hd0)65+1 bs=512 count=1 should also work. jaclaz

... but allow me to doubt that anything BUT a Toshiba OEM image will activate with a Toshiba OEM key : jaclaz

The screenshot from BOOTICE seems just fine, of course you need to add grldr.mbr and grldr to the root of your D:\ drive. After having saved the BCD at next boot you should have two options, Windows 10 and Linux Mint, if you choose the latter you should find yourself on the grub4dos command line prompt grub>, if you also copied to D:\ the menu.lst you will have a number of "default" options, press key "c" to get to the command prompt. Now you can try the commands to boot your Linux Mint (if the commands work, then you can add them to a menu.lst). Loosely the needed commands are three (+1 in command line only): 1) establish root to the proper volume 2) load the kernel 3) load the initrd 4) issue the "boot" command (only on command line, when you write this on a menu.lst entry the "boot" command is implied and executed at the end of the entry) So it could be something like: root (hd0,0) kernel /boot/vmlinuz-4.4.0-57-generic root=/dev/sda1 ro kernel /boot/initrd.img-4.4.0-57-generic boot The name of the kernel and of the initrd depend on the exact version of Linux Mint. As well the name/numbers of the drive may need to be adapted: First partition on first disk grub4dos=(hd0,0) Linux=/dev/sda1 Second partition on first disk grub4dos=(hd0,1) Linux=/dev/sda2 First partition on second disk grub4dos=(hd1,0) Linux=/dev/sdb1 ... etc, ... If you already installed the linux on the first disk or disk 0 (the one that contains the D:\ volume), and you installed the "default" GRUB2 on this first disk, you may be able to chainload the MBR of the first disk and have the GRUB2 boot the linux, i.e.: rootnoverify (hd0) chainloader +1 boot If you can boot to a "live" version of Linux (or however have a way to access the volume where linux is installed) you can check the GRUB.CFG file, find the entry that should boot the Linux Mint and post it, then we can "translate" from GRUB2 syntax to grub4dos one. jaclaz