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

You need a slash (or a full device path) for the filename. root (fd0) dd if=/Sec_6571.bin of=(hd0)65+1 bs=512 count=1 or: dd if=(fd0)/Sec_6571.bin of=(hd0)65+1 bs=512 count=1 Yep, thanks , I meant that the change in the MBR happened after the "cloning", which means that the "cloning" somehow missed the MBR code (as I cannot believe that the "original" had no MBR code as "some" MBR code is written by "every" common tool and anyway the "otiginal" could not have booted). Yes, the partition table is seemingly fine, no problems there: Entry Type Boot bCyl bHead bSect eCyl eHead eSec StartSector NumSectors #0 0B 80 0 1 1 1023 254 63 63 75327777 #1 0F 00 1023 254 63 1023 254 63 75327840 2812320 #2 00 00 0 0 0 0 0 0 0 0 #3 00 00 0 0 0 0 0 0 0 0 jaclaz

Good to know . Do you mean that it was the (booted from floppy or chainloaded by grub4dos) WIN98 that wrote that on the "new" (cloned) disk? Still it is curious how EITHER the original disk had OR the "cloning" program managed to make a "code blanked" MBR. jaclaz

Well, then you are asking a "wrong" question, i.e. you are risking to fail for the chocolate covered banana : https://jdebp.eu/FGA/put-down-the-chocolate-covered-banana.html WinSetupFromUSB is simply not the "right" tool for the scope. You can add grldr.mbr (which is part of grub4dos and NOT of GRUB) as an entry to your existing \boot\BCD (it is not really-really an "install") or deploy the code that chainloads grldr (which is still the same grldr.mbr) to the MBR and thus set grub4dos (and NOT GRUB) as your "main" bootmanager. Until the (stupid) windows 10 it was easy to add a grldr because the BOOTMGR parsed the good ol' BOOT.INI file, starting with 10 it is needed to add the grldr.mbr to the BCD, see: http://reboot.pro/topic/21527-windows-10-bootmgr-no-longer-reading-bootini/ You can get the latest version of Bootice from Softpedia, here: https://www.softpedia.com/get/System/Boot-Manager-Disk/Bootice.shtml And the latest version of grub4dos here: http://grub4dos.chenall.net/downloads/grub4dos-0.4.6a-2018-09-19/ If you don't want to touch your MBR (and a few sectors after it) and don't want to fiddle with the \boot\BCD, you can still try installing the grldr on the 500 MB partition (more like your original plan) but it has to be seen how it works with latest versions of grub4dos. Traditionally (with the "standard" MS bootsector loading NTLDR, i.e. the 2K/XP bootsector for FAT32) it worked just fine with grldr renamed to NTLDR: http://reboot.pro/topic/4423-start-grub4dos-grldr-from-nt-bootsector-why-not-working/ Since your current volume bootrecord is invoking BOOTMGR, you will need to run bootsect.exe with the /NT52 switch on the volume to write the MS bootsector code invoking NTLDR, then copy to the volume the grldr renaming it to NTLDR. The "sample" menu.lst in the grub4dos download already has a provision to automatically search for and chainload a BOOTMGR, so you should be able to boot to your Windows 10 without issue after the "install" of grub4dos. Then we will see how to boot the Linux and make a suitable menu.lst entry for it. jaclaz

I am not sure to understand. Copy /b means "force" copy to copy binary data (i.e. "as is"), notmally (but it depends on versions if I recall correctly) copy will automatically switch to "/b" if it encounters binary data, but it is better to be sure and use the switch. I don't think that there is a /c switch in copy. Anyway, the file you posted is fine (in the sense that it actually contains the sectors I was interested in) . As expected there are two (separate) issues. Issue #1: the third sector of the VBR is blank (should contain boot code) Issue #2: the MBR code is (almost) blank Issue #1 may be due to some quirk of the program you used to make the "clone", the third sector of the FAT32 bootrecord of DOS/Windows 9x is actually the 3rd sector, whilst in 2K/XP and later it is the 13th (and in FreeDOS it is 15th), so a so-called-cloning program developed for 2K and later may well have provisions to clone the 13th sector because it assumes that the code is in it, "jumping" over the third sector . Issue #2 is stranger, the MBR code is almost blank with only four non-zero bytes written at offset 0xDC. no idea on what could have caused it . There are a few more minor issues, but nothing that cannot be fixed. Anyway, get the attached, it contains four files: Sector_0.bin <- this is the MBR or LBA0 (with your data AND the standard Win98 IPL booting code added) Sec_6369.bin <- this is the first sector of the VBR or LBA63 (and a copy of it is on LBA69), this is not changed as it is just fine, but see later in the instructions Sec_6470.bin <- this is the second sector of the VBR or LBA64 (and a copy of it is on LBA70) this is not changed as it is just fine. Sec_6571.bin <- this is the third sector of the VBR or LBA65 (and a copy of it is on LBA71) this is the "main" culprit How to fix the whole thing, after having copied these files to the floppy and booted from it : 1) deploy the third sector, in grub4dos: root (fd0) dd if=()/Sec_6571.bin of=(hd0)65+1 bs=512 count=1 at this point , if you run (still in grub4dos): root (hd0,0) chainloader +1 boot the system should boot to the DOS on hard disk C:\ (this is the same test #2 that previously failed) 2) write the MBR with the code (reboot from the floppy, get to grub4dos): root (fd0) dd if=()/Sector_0.bin of=(hd0)0+1 bs=512 count=1 at this point , if you run (still in grub4dos): rootnoverify (hd0) chainloader +1 boot the system should boot to the DOS on hard disk C:\ (this is the same test #3 that previously failed) So if both the above work , you should be pretty fine BUT there are a couple things still to do. Boot again to the floppy and grub4dos and: root (fd0) dd if=()/Sec_6571.bin of=(hd0)71+1 bs=512 count=1 <- this is to put the copy of the third sector where it should be dd if=()/Sec_6369.bin of=(hd0)69+1 bs=512 count=1 <- this is needed because (for *whatever* reasons) the copy of the bootsector has a wrong value in "sectors before" field If you have doubts/questions, ask them before doing something you haven't confidence with. jaclaz pathway.zip

Hmmm. It depends on which message they will get. https://www.zdnet.com/article/ms-linux-lindows-could-microsoft-release-a-desktop-linux/ jaclaz

Well, if I had to tackle the issue I would have a (temporary) English install of XP, and from it extract to .reg file the whole: HKEY > CURRENT > USER > Software > Microsoft > Windows > CurrentVersion > ShellNoRoam > MUICache then do the same on the Italian one and compare the two files. jacla

I am not sure I understand: https://ccm.net/faq/14662-windows-xp-change-the-name-of-the-recycle-bin or: http://www.syschat.com/how-rename-recycle-bin-windows-xp-5863.html (make the "rename" feature available) jaclaz

Hey, this is "Funny Farm", the whole point was about the info on MS support pages being blatantly incorrect. jaclaz

I suspected that. I checked and the 0.4.4.2009-10-16 actually has the internal dd command (in an early version, anyway working ), but you need the "target file". Since you have SYS.COM on the diskette, that is around 19 KB, do the following (booted to the DOS on the diskette, i.e. on the A:\> prompt): copy /b sys.com+sys.com+sys.com mysects.bin DIR mysects.bin you should have a file mysects.bin that is 56901 bytes (enough) Then: grub.exe on the grub4dos command prompt root (fd0) dd if=(hd0)0+100 of=(fd0)/mysects.bin bs=512 count=100 jaclaz

You have a phone? Luxury! ... why, in my day all we could do was to shout very loud to call someone! ... and we liked it! ... kids today ... https://tinyapps.org/blog/misc/200702250700_why_in_my_day.html jaclaz