jaclaz

They are other tools similar to the RunasTI by joakim I linked to earlier, the topic contains also some background/why/how the approach works: jaclaz

Naah, I only happen to know quite a few things on a very narrow set of data (like you know this or that set of 512 bytes). The CHS/LBA being not balanced is more or less as old as partitioning, the fact is that until a certain point *everything* was CHS based and after a certain point *almost anything* was LBA based, whenever both come into play, if they are not balanced/corresponding, it is likely that issues arise. Though this specific case is actually "queer", the difference between "absolute" or "relative" path should be not influencing the mounting, so the only possible explanation is (very much similar to your hint about timing) due to using the "find" (or "find --set-root") before mounting, it should mean that *somehow* finding the file allows for a different parsing mechanism, but it remains "queer". It is like there is a difference between "cold mounting" (i.e. mapping a file that has not been accessed before) and "hot mounting" (i,e. mapping a file that has been already accessed by some other grub4dos command, it is like grub4dos is "taken by surprise by the contents of the file" and tries to "invent" a suitable set of partition data (and failing at it). The origin is of course the unbalanced partition data (GIGO paradigm) still it is baffling. If you still have the "bad" image, can you try: root (fd0) ls /hdd-512mb.img.gz and ls (fd0)/hdd-512mb.img.gz before the mapping? (I mean instead of find or find --set-root) jaclaz

I am missing something, what are the differences in the commands you issue (between the ones that end up with a "bad" mapping and the ones that end up with a "good" mapping")? They seem to me exactly the same, at first sight this one: is a "hardcoded/absolute" path to the image, this one: is a "relative" path. Both are "wrong" (theorically/philosophically), what happens with the "right" one?: Or there are other differences that I missed? Anyway the MBR partition table of the two (bad vs. good) mapped drives is different, what is actually in the original image? If it is the one in the "good" mapped image, at least part of the issue is likely in the "unbalanced" CHS vs. LBA values. The geometry is clearly 32/63 (as it is confirmed in the bootsector BPB data) The data in CHS values is: Start: 0/1/1, that translates to 63, OK End: 520/31/63 that translates to 1050335 (521*32*63-1=1050335) from which you subtract the 63 and obtain the amount of sectors 1050335-63+1=1050273 sectors in the partition, 1050273 converts to 0x001006A1 BUT the MBR partition table LBA has 0x000FFEC1 instead that is decimal 1048257 So, THAT partition table entry is NOT balanced CHS vs. LBA, and as such it won't "behave" correctly in a number of cases. Then, as a matter of fact, the actual bootsector has in its BPB data 1048257 sectors. You should try starting with a CORRECT image. To correct the image, you need to change the end cyl in the partition table from 520 to 519, i.e . change the: 80010100061FBF083F000000C1FE0F00 to: 80010100061FBF073F000000C1FE0F00 Or you can get to where you have the image "badly" mapped and issue in grub4dos a partnew (hd0,0) 0x06 63 1048257 geometry (hd0) What happens to the partition table entry CHS values? jaclaz

Well, you can use extract (command line): https://www.winimage.com/extract.htm it should have the same capabilities (needs to be tried in this Qemu setup, though). jaclaz

I like the idea of the post being "swallowed by the Internet ogre" , maybe it spat it out later, you know, like ... jaclaz

There may be. You can probably do it using Trusted Installer credentials or by direct disk writing (IF the new file is the same size as the old one). Example of Trusted Installer approachI: Direct disk writing approach (again only valid if the new file is the same size of the old or - maybe - also if it is smaller), consists in finding out the extents the file is in (if needed make it contiguous) and then attempt dd-ing the new file on that same location, you can use mygrafmenter or extents here: http://reboot.pro/topic/18570-extents/ to get LBA extents data then use dd for windows or similar (dsfi of the DSFOK toolset ) to try if the write "goes through".[1] jaclaz [1] if I were you, and IF the new file is same size or smaller, I would personally rather use direct disk writing before booting using grub4dos blocklist and dd commands.

Well, you could try this: http://reboot.pro/topic/18855-windows-file-search-utility-that-is-fast/ https://sourceforge.net/projects/swiftsearch/?source=dlp that is possibly even faster (but limited to NTFS) and needs not a "catalog". jaclaz

Sure you can . This has always been true, even for logical volumes inside extended (but a few caveats applied to this particular case) but since you are on EFI/UEFI all volumes are primary partitions, i.e. they are self-standing and have an "own" entry in the (EFI/UEFI) partition table. Though - generically speaking - there is not any real reason to actually delete and recreate a partition/volume, if you are "not happy" with the contents of a partition/volume you can zero (i.e. wipe IF needed) the contents and re-format the partition/volume without "erasing and recreating" it. As well there are tools to move/resize partitions (if the contents are fine but the issue is with size). Maybe you could provide some more info on your needs and we could assist you in a better or simpler procedure? jaclaz

Today's news : https://www.bleepingcomputer.com/news/microsoft/windows-10-search-is-broken-and-shows-blank-results-how-to-fix/ jaclaz

Very good (that the issue is *somehow* solved). It is not at all "strange", it isn't the first, nor it will be the last of something that "just happens", it simply needs to be tagged as "voodoo" . On reboot.pro we have even a smiley for these cases jaclaz

Just in case: https://archive.org/details/icafe-winxp-9.00.300.3010-beta1-br294594-sep24 jaclaz

No exe is involved in booting to a floppy image. You need the floppy image of course, and you can extract it from your CD or get one of the many copies of "Windows 98 boot disk" available online, if you got one of those they may be packed in a self-extracting .exe, as an example, get from here the suitable .img (not the .exe) file: https://www.allbootdisks.com/download/98.html Then you mount it in (say) IMDISK or VFD or use a similar driver or tool capable of editing the contents of the boot image and add the GCDROM.SYS (actually I would suggest XGCDROM: http://www.mdgx.com/drv.htm then you store the image on the same stick as you have the grub4dos (easy2boot is essentially a more handy way to use grub4dos) and from that you load the floppy image, *like* (press "c" to get to the command prompt of grub4dos), assuming that the image is called "mynice.img" and it is in root of the USB stick: map --mem /mynice.img (fd0) map --hook root (fd0) chainloader /io.sys boot jaclaz

Look , noone said that. What was said was that the iPhone is good for BOTH those users that "do not have unlimited time or ninja search skills to figure out what works"[1] AND for those "users who need video tutorials spoon-feeding them in baby steps", EXACTLY BECAUSE it "just works". Before feeling insulted, please make sure that someone actually insulted you (if you want I can insult you so that you can appreciate the difference ). jaclaz [1] short definition: busy people [2] short definition: inexperienced people

Yep, but IF there is a timing problem (or race condition or *whatever*) on the bus that won't likely change it. SImplified, if the BIOS is made of 1 byte, with contents 00110011 you can rewrite it as 00110011 as many times as you want, it was 00110011 before, it is 00110011 now, it will be 00110011 after you have rewritten to it 00110011. On the other hand - maybe - changing the IDE cable, changing the settings of the drive Master/Slave/Cable Select may make a difference, particularly with coloured cables it is not unheard of "queer" conflicts. JFTY, you don't actually *need* a physical floppy, you can use a USB stick and have on it grub4dos to load a "virtual" floppy (floppy image). jaclaz

@bphlpt If I may, both sides of the arguments have some good reasons backing their stance, but it is not unheard of developers that just develop (and in the process create a mess of mostly unreplicable *whatevers* that need hours of reading and experiments, that only the most dedicated and knowledgeable users can actually get to work properly), and as well there are a number of (clueless) wannabee users that simply fail at that, due to lack of previous knowledge, lack of time, lack of dedication. So we have a population made of - say (to remain in Siria's example) 5% that know where their towel is and succeed, 5% that won't ever make it (and have anyway their nice shiny iPhones according to deocorso) and between these two extremes the 90%. But this 90% is not a "monolith", there are many "levels" composing this category, tentatively, let's say: 8% near the top - bordering the successful ones - lacking only some dedication or some marginal piece of knowledge 12% right below - lacking both some knowledge but also some dedication 70% even below - lacking knowledge, dedication and interest/motivation (and - still according to dencorso - happy with their Windows 7 SP1 / Android / TrueOS / Ubuntu ) There is nothing to do for the 70% with Windows 7, etc. + 5% with iPhones. What can be done is only about the 8% and - maybe - part of the 12%. The nice twist (that you were probably waiting for ) is that part of the population is not necessarily to be taken care of by the developer, there could well be some of the top 5% that succeeded that wish to share their knowledge and create sum ups, tutorials, etc. and assist those in the 8%+12% that need help. In other words, siria may well start writing down in one place all the issues he found with the files (missing or needing to be modified), where to get them from, how to install them, etc., etc. and more generally make the contents produced by the developer(s) more accessible or accessible to a larger part of the population [1]. The time that the developers have at their hands is limited and they already gifted us with the products of countless hours of their time, it is perfectly fine to disagree with this or that aspect of these products, but as opposed to the armchair expert attitude, maybe one could be more proactive. This approach has worked fine for a number of similar (similar in the sense of projects being dedicated to old OS's or very "niche"). The project in itself may be a mess or being difficult to find or missing documentation or having it in another (complex) language like (for us westerners) Chinese or Japanese, think - only to make an example - of all the nice things by BlackWingCat, or grub4dos, still through the dedication of a few people on boards like msfn.org or reboot.pro they were made accessible to a larger part of the population. jaclaz [1] as opposed to making snarky comments on how the developer should have managed this or that issue

It could be some sort of "weird" timing issue, maybe having the 80 GB disk (or just the IDE-to-SATA converter) on the same ribbon cable could have changed this slightly (possibly slowing a bit the booting). jaclaz

Yep, good , BUT the "forced off" is ultimately the same as the "reset" by (after having made a backup/copy , etc. ) copying cmd.exe to either sethc or utilman, I personally do not suggest or endorse it because the event triggering the "advanced boot menu" revolves around essentially (intentionally) corrupting some files or possibly even some filesystem entry. Most probably, let's say 98.3% of the times this corruption is trivial, and the system will boot to the advanced menu (after having done mysterious things for several minutes), the problem might be in the (still say) 1.7% of cases when the "forced off" for *some reasons* makes deeper corruption and the system cannot boot anymore. Having an alternate booting system (that is a PE or a Linux) is advised when you attempt that, but then again, if you have this alternative booting system you can do the reset faster (as it won't take the several minutes of the attempts to repair) and safely (and without the jumping theought hoops). The "old" (but still OK, at least up to 8.1) way made use of chntpw, the UltimateBootCD does have a provision for a "Offline NT Password & Registry Editor": https://www.ultimatebootcd.com/index.html http://pogostick.net/~pnh/ntpasswd/ so it is very possible that you remembered correctly. jaclaz

Between 2/3 and 4/5 of the results of such a google search will deliver links to (mostly crappy) commercial tools, or to methods that won't work, etc. @MarkJohnson in this case it is particularly important to be exact in the terms used, there are 3 approaches possible: 1) reset 2) bypass (and reset) 3) recover Normally for #1 (reset) above you can use any windows 7 install CD, or USB or PE or any bootable OS with NTFS support (make a backup copy of sethc.exe or utilman.exe, then copy cmd.exe to either sethc.exe or utilman.exe) *like*: http://www.infosecisland.com/blogview/15031-How-to-Log-In-to-Windows-Without-the-Password.html For #2 (bypass and reset) nowadays the easiest is to use a USB stick with Easy2boot and PassPass: https://www.easy2boot.com/ https://www.easy2boot.com/add-payload-files/windows-install-isos/passpass If you want to actually recover the password, the procedure is more complex, doable but if not strictly needed, I would advise you against it, as it will also take some time. jaclaz

What do you mean? Download link for the driver is on the 6th page of the article: http://www.wintricks.it/faq/usbpen98_6.html http://www.wintricks.it/download/wtgenusb.zip and it works just fine. jaclaz

As said above you can try to map the physicaldrive, thus by-passing the 98 USB driver in the VM. Alternatively, you can try the good ol' plain "Lexar" driver, see here: the original article is in Italian ( a Portuguese should be able to read it without particular issues): http://www.wintricks.it/faq/usbpen98.html just in case a short English translation of the most relevant part is here: https://web.archive.org/web/20100622043413/http://www.boot-land.net/forums/index.php?showtopic=2411 jaclaz

No problem , it is just a matter of terminology, I read "empty image" as "empty image" (which is what I call an image consisting of only 00's), mainly to distinguish it from: 1) not completely empty images 2) images that are empty BUT for the MBR 3) images that are empty BUT for the MBR and PBR 4) images that are empty BUT for the MBR the PBR and the filesystem 5) other kinds of empty images that are different from the above but still are not fully empty (i.e. composed entirely of 00's) The whole point that surprised/perplexed me was this one: Which I would now translate tentatively to: Surprisingly, giving the command insmod fat before map --mem and commenting out fat mkfs (or - in other words - without touching at all the gzipped image and only copying/expanding it to RAM), resulted in a fully formatted FAT16 Memdrive with partition ID 06 and a valid bootsector (from a non-empty image that was most probably already partitioned and containing a FAT 16 type 06 formatted partition) Anyway the idea (mine) was to assist you into making the thingy work from scratch, i.e. from an "empty image", if the image is pre-made, as you later found, there is no need to have the insmod fat, and if the pre-made image is all 00's ...(see spoiler) . Most probably (and this is what should be confirmed by the experiments ) at least some of the "different" behaviours you reported (that you connected to issuing this or that command before or after another one or by loading the fat module. or making root to (fd0), etc.) are side-effects (or collateral damages) deriving from the "wrong" geometry used to map the image. jaclaz

If I were you I would first try to reduce chrome memory usage, besides the glitch in startisback you just reported, it is not a good thing to have 15 GB out of 16 GB used. You can try The Great Suspender: https://github.com/deanoemcke/thegreatsuspender or The Great Discarder: https://github.com/deanoemcke/thegreatdiscarder jaclaz

Yep , you see, you said you had a 00ed image, while you had an image with ALREADY both a valid partition table entry and the Magic Bytes signature in the MBR (and also - irrelevant for non NT systems - a Disk Signature). Not only, the actual entry values in that partition table lead us to the fact that it was created using NOT a 255/63 geometry, but rather a 32/63 one (which is appropriate for the overall size of the image). Which makes me think that not only the image is partitioned, but it is also formatted. I.e. run insmod fat map --mem --heads=32 --sectors-per-track=63 (fd0)/hdd-512mb.img.gz (hd0) map --hook geometry (hd0) then, since we already know that the partition table exists, and leads to a bootsector on sector 63, try: cat --hex (hd0)63+1 if it is all 00's then the base image is partitioned but the volume/partition in it is not formatted, if you see non 00's values it is likely that also the FAT filesystem exists. try also: root (hd0,0) then, go anyway on: fat mkfs (hd0,0) geometry (hd0) then, try again, this time making sure that the image is actually all 00's, like this: insmod fat map --mem --heads=32 --sectors-per-track=63 (fd0)/hdd-512mbALL_00s.img.gz (hd0) map --hook geometry (hd0) partnew (hd0,0) 0x06 63 1048257 makeactive (hd0,0) geometry (hd0) /mbrview.g4b (hd0) fat mkfs (hd0,0) geometry (hd0) You should get, from a completely blank image, the same results. jaclaz

Not any particular good (nor misterious) reasons, I simply have on this machine a bunch of old programs that *for some reasons* are less stable on SP3 (which doesn't mean that on a newly installed OS updated to SP3 they won't work just nice). jaclaz

Hmmm. I don't know, it is entirely possible that the VmWare you are running is not fully compatible with the USB drivers. Whay is the "host" OS (i.e. the system where you are running the VmWare)? Maybe it is possible to disable the USB and map the physicaldirive, *like* (this may depend also on the VmWare version you are running): https://www.vmware.com/support/ws5/doc/ws_disk_add_raw.html jaclaz