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

Since we are in an anti-virus related thread, JFYI: https://www.pcmag.com/news/avast-to-end-browser-data-harvesting-terminates-jumpshot jaclaz

Only for the record, I am the exception that confirms the general rule (nice to meet you ). And yes, besides my "everyday machine" that runs XP SP2 I also have an old PC with XP SP1 (vanilla or "gold" XP sucked even more) and yet another one with good ol' Windows 2000. jaclaz

Ok, so you have three five slightly different set of commands. It makes no sense to provide --heads=0 --sectors-per-track=0 to have then grub4dos default to 255/63, use instead, (and you can well specify (to avoid possibel issues a definite disk drive number), i.e. map --mem --heads=255 --sectors-per-track=63 (fd0)/hdd-512mb.img.gz (hd0) The result of parttype (hd-1,0) may also be an artifact of some kind, if the source image is all 00's you shouldn't have neither 0E nor 06 until a partition table is established. even here, use an explicit disk number (to be sure) and, besides the: parttype (hd0,0) Run also: geometry (hd0) and: cat --hex --skip=446 (hd0)+1 and (you will need to add to the floppy the batch) try using mbrview.g4b (reboot.pro is down right now, I am attaching a copy to this post): https://web.archive.org/web/20170826082957/http://reboot.pro/topic/17728-release-mbrviewg4b-a-bat-tool-for-grub4dos/ /mbrview.g4b (hd0) These three methods will confirm (or deny) that there is actually a (valid) partition table on the (hd0). It is as well possible that the fat mkfs is not really-really making a volume in a partitioned device, but rather a superfloppy. after (in the fourth set of commands) you run: fat mkfs (hd0,0) run again the three commands before (geometry/cat/mbrview) to check the differences. UNLESS you run (on the mem mapped device) a partnew command, *like*: partnew (hd0,0) 0x06 63 1048289 I doubt that a proper partition table will be made on the disk. To recap, try the following: insmod fat map --mem --heads=255 --sectors-per-track=63 (fd0)/hdd-512mb.img.gz (hd0) map --hook parttype (hd0,0) geometry (hd0) cat --hex --skip=446 (hd0)+1 /mbrview.g4b (hd0) fat mkfs (hd0,0) parttype (hd0,0) geometry (hd0) cat --hex --skip=446 (hd0)+1 /mbrview.g4b (hd0) then, from fresh, try this instead: insmod fat map --mem --heads=255 --sectors-per-track=63 (fd0)/hdd-512mb.img.gz (hd0) map --hook parttype (hd0,0) geometry (hd0) cat --hex --skip=446 (hd0)+1 /mbrview.g4b (hd0) partnew (hd0,0) 0x06 63 1048289 geometry (hd0) cat --hex --skip=446 (hd0)+1 /mbrview.g4b (hd0) fat mkfs (hd0,0) parttype (hd0,0) geometry (hd0) cat --hex --skip=446 (hd0)+1 /mbrview.g4b (hd0) and see if you find any difference. jaclaz mbrview-no-wenv.zip

You can still find around the (read only) version of Sysynternals NTFS driver: https://www.techrepublic.com/article/installing-sysinternals-ntfs-for-windows-98-driver/ or this one : https://www.diskinternals.com/ntfs-reader/ https://eu.diskinternals.com/files/NTFS_Reader.exe or this one, use with care (read/write): https://www.paragon-software.com/home/ntfs-win98/ this is I believe an earlier version, latest cannot be obtained anymore AFAIK: https://www.softpedia.com/get/System/Hard-Disk-Utils/Paragon-NTFS-for-Win98.shtml or you can use the : https://www.softpedia.com/get/System/Hard-Disk-Utils/Active-NTFS-Reader-for-DOS.shtml Another option: https://msfn.org/board/topic/86932-helpaccess-ntfs-from-dos-boot/ These latter two are however DOS, not windows, cannot say if they will work in a DOS window. jaclaz