jaclaz

Good. @GoodManeuver I don't know, if I use your link (with the "?product=81530" at the end) I land to a 404 page: However no problem, shockchargeIV's is solved. jaclaz

Is it this one? https://www.cnet.com/products/gateway-500s-mdt-p4-2-ghz-128-mb-40-gb-lcd-17/ The board is seemingly an Intel 845G, so these: https://www.techspot.com/drivers/driver/file/information/1170/ via Wayback Machine: https://web.archive.org/web/20040409055856/http://aiedownload.intel.com/df-support/4773/eng/win9xe114.exe should be the suitable drivers. Check the VEN&DEV , as an example with one of the programs here https://msfn.org/board/topic/179593-alternative-device-manager-for-win98/ Should be: PCI\VEN_8086&DEV_2562 jaclaz P.S.: @Goodmaneuver For some reasons your link doesn't work This one works: https://downloadcenter.intel.com/download/7005/Intel-R-Extreme-Graphics-2-driver should be latest-latest version : https://downloadmirror.intel.com/7005/a08/win9x1361.exe

Try posting EXACT make/model, maybe something can be done. Anyway most probably you can get away with the UNIVBE/VBEMP: https://bearwindows.zcm.com.au/vbe9x.htm but if a manufacturer driver can be found it would be probably better. jaclaz

The issue(s) is/are twofold: #1 is with "old 98SE backup". The EXACT way the backup was made might make a difference as it may contain (or fail to contain) some data useful for the restoring to "pristine" hardware. #2 is with the EXACT new hardware at hand, as a number of drivers and settings may need to be changed (provided that appropriate Win9x drivers for the new hardware are available). All in all I personally would do it in two steps: 1) have the backup restored (and working) in a VM - specifically - in Qemu that can emulate hardware similar to the "original" one 2) make a copy of this latter install and attempt to have it run on the new hardware jaclaz

Yep, happy to have been of use , To be fair, there is a difference in the level of bul***** in the two articles. The difference is that once you read them the itprotoday is "honest", i.e. it is a report of something that happened and that in that particular case was actually a "restore", and misses the link to the userinit possible issue (as the Author didn't need it), whilst the petri one is (as often happens on that site) the usual attempt at "examplification to the masses" of something that by rewording it (without ever testing the method) is likely to induce the reader into committing a (very regrettable) mistake. Still, it has the link to the possible issue with userinit BUT without citing it in the text. So, on one hand the first is not so bad, as reading it, even if it is incomplete, it becomes clear that it applies to a specific situation, while the second is IMHO actually misleading, the : "For the most part, this is not recommended, especially if the drive letter is the same as when Windows was installed." should have been written as : "Do not EVEN THINK of doing this UNLESS you are in the specific case detailed in the linked MS KB" jaclaz

jaclaz

Yep re-installing a fresh system is not that bad, I mean it is not like it was a machine already used for years, customized, etc. Only for the record, one of the good things of grub4dos is disk/drive remapping capabilities, even if you boot from the USB stick (and you then run a floppy image) you can re-map drives at BIOS level. jaclaz

JFYI: https://msfn.org/board/topic/178312-4k-resolution/ jaclaz

Those links are bul***** (no fault of VistaLover of course ). In the end they are essentially these: https://support.microsoft.com/en-us/help/223188/how-to-restore-the-system-boot-drive-letter-in-windows Which apply IF (and ONLY IF) the system was installed to C:\ and later - for whatever reason - the drive letter changed to - say - D:\. I.e. they are fine if you want to restore to C:\ a system installed to C:\ but they will NOT be enough in case the OS has been originally installed to D:\. BUT you won't be able to log in IF your install has a full path to userinit had FIRST followed this one: https://support.microsoft.com/en-us/help/249321/unable-to-log-on-if-the-boot-partition-drive-letter-has-changed so you'd better check that first thing. See also: There are hundreds and thousands of references to the original driveletter to which the OS was installed in Registry (and in links, shortcuts, .ini settings and what not). It is possible to change a system drive letter, but it needs a lot of patience and the use of tools *like* good ol' COA2 and/or Registrar Lite (using plain Regedit would take forever). Basically you need to find - systemwide - each and every reference to D:\ and replace it with C:\, it is doable , but you MUST HAVE an image (or at least an accessible backup AND an alternate booting OS (like a PE) in case something goes wrong. In case you want to try, you need COA2: https://web.archive.org/web/20120321153256/http://digilander.libero.it/rareware/coa2.zip and Registrar Lite version 200: https://web.archive.org/web/20021201100858/http://www.resplendence.com/download https://web.archive.org/web/20021203063147/http://www.resplendence.com/ftp/reglite.exe jaclaz

Well, you managed to have: 1) a non-bootable partition 2) a "wrong" drive letter assigned to it IMHO the above would not be an acceptable result. Issue #1 can be fixed easily by either using SYS from the USB stick or manually via grub4dos or disk editor Issue #2 not so much COA2 would probably work, still it would be easier to reinstall once having booted from the "right" partition/disk jaclaz

Or half-way, maybe? jaclaz

I don' t know if it is the same thing, but once we had the board autocorrect (replacing some characters with asterisks) words like Fukushima (no workaround possible) and Matsushita (we had to write Panasonic to get through the word filters ) Welcome aboard! jaclaz

Sure . requisites for using an F6 floppy are: 1) a floppy drive 2) an actually suitable F6 floppy media requisites for grub4dos floppyless F6 are: 1) grub4dos 2) an actually suitable F6 floppy media image If you miss #2 both methods become complex. jaclaz P.S. Before I forget, a similar approach using Syslinux: http://wp.xin.at/archives/2702

0xc0000142 means missing (or unregistered) .dll Usually tracing the .exe with Dependency Walker the culprit can be found. jaclaz

That is probably fine since there is NO image in my post. There is instead a preview - auto-generated by the stupid board software - of a youtube video, link is: https://www.youtube.com/watch?v=3mbd9qEzU5Q jaclaz

Well, yes and no. It supposes that you have a network and one of the machines is running a recent OS and has internet connection. Unlike a virtual machine, this is simply a "proxy", but it allows connecting your "real" machine running an old OS to the modern Internet. jaclaz

You mean something *like*: jaclaz

Basically, AFAICU you are replacing (forcing) the driver to a not-the-right PCI/VEN. IF - for whatever reasons - the new driver doesn't start AND the old IDE driver does not (on reboot with the BIOS back to IDE) still work you are left with a non-bootable system. Of course recovery of such a system is always possible, think of the good ol' mergeIDE, but it is not like it is (anymore) common knowledge: (currently the above link resolves to ANOTHER MS KB page, use an archived version to get the mergeide.reg: https://web.archive.org/web/20100723171255/http://support.microsoft.com/kb/314082/ And you need to somehow boot the computer with a PE (or have another OS or another computer) to use that. jaclaz

@Luweitest I cannot think of anything more risky than what you reported doing, however, if it worked for you, good. Still it is not the "right way", which is the one already posted by me and cdob (i.e. have the driver be "parallel" to the IDE one), allowing, in case of issues with the new driver to re-set the BIOS to IDE and have the previous driver (almost) surely working. It is very possible that XP has some "safety mechanism" that allows anyway to revert to the IDE driver if the SATA one fails and you re-set the BIOS to IDE, but it remains IMHO risky, if one makes before an integral copy of the disk, then it may be attempted, but otherwise ... jaclaz

Sure you can, that is the whole point of the first links I gave you and of the one cdob provided . jaclaz

Well, the RMPREPUSB tutorial actually loads two (or more) drivers, in that case it is a single SATA driver + Firadisk (or Winvblock), but you can replicate the same with the two drivers you have: http://rmprepusb.blogspot.com/2013/06/txtsetupoem-files-for-f6-floppy-disks.html AND check how the TXSETUP.OEM in the floppy Steve6375 provides is made: https://www.rmprepusb.com/tutorials/install-xp-from-an-iso/winvblockJmicron_C600.ima.gz.gz?attredirects=0 But also the manual you posted seemingly uses the "Press S to add driver" approach, maybe the issue is specific to the "Marvell shared library (install first)" ? jaclaz

Conventionally the "pipe" sign "|" means "or", these (from JFX's post) are valid options: BootMountExclude=\Device\HarddiskVolume1 OR BootMountExclude=Disk0 OR BootMountExclude=Disk1 jaclaz

Maybe useful, maybe not, just found this : https://github.com/tenox7/wrp jaclaz

No, the mapping is "volatile". But there should be not AFAICR the need of a reboot, or - better said - after the reboot text mode-> GUI setup there should be no need of the floppy. What happens (or should happen) when you press F6 and choose the files is that the files on the floppy are copied from the floppy to the C:\$WIN_NT$.~BT folder Maybe there are still some issues with the floppy contents and/or oemsetup.txt? To verify that a file in contiguous in grub4dos you simply run the command "blocklist", i.e.: blocklist /floppy.img the result will be something *like* 322158+2880 (which means that the file starts at LBA 322158 and extends by 2880 sectors, and the file is contiguous, if it is not you will have more that one result in the form start+length, one for each extents of the (fragmented) file. Being contiguous is a requisite if you do "plain" mapping, i.e.: map /floppy.img (fd0) while it is not needed if you do a memory mapping, i.e.: map --mem /floppy.img (fd0) Review this tutorial/approach: https://www.rmprepusb.com/tutorials/install-xp-from-an-iso and this one (about the F6 floppy): http://rmprepusb.blogspot.com/2013/06/txtsetupoem-files-for-f6-floppy-disks.html In that method - if I recall correctly - the Winvblock (or Firadisk) driver is used only to keep the .iso accessible during the GUI part of the setup, and the floppy is not re-accessed after the reboot, from what you report it looks like some file is not found and the GUI asks for the floppy. If you cannot find the reason why, you can still prepare a USB stick with Winntsetup from USB or follow the RMPREPUSB tutorial above. jaclaz

If you want/can start DOS (Win 9x DOS is fine), you just: 1) put in a reachable path grub.exe and the floppy image you want to map 2) execute it 3) at the grub4dos command prompt run the needed commands (or have a menu.lst with them) 4) boot to *whatever* you want to boot to start the XP installation Example, imaging that you boot to the C:\ drive and you have in it C:\grub.exe and C:\myF6floppy.ima At the dos prompt: grub.exe [ENTER] at the grub prompt: find --set-root /myF6floppy.ima [ENTER] map --mem /myF6floppy.ima (fd0) [ENTER] map --hook [ENTER] chainloader /io.sys [ENTER] boot [ENTER] Back to Dos prompt: DIR A:\ [ENTER] should list contents of the F6floppy The guide here is old (but good enough for this use): http://diddy.boot-land.net/grub4dos/Grub4dos.htm Starting XP installation from DOS (i.e. via WINNT.EXE) you are limited to FAT filesystem, of course, though you can later convert it to NTFS. You can use either an oldish, stable grub4dos 0.4.5c: http://grub4dos.chenall.net/downloads/grub4dos-0.4.5c-2016-01-18/ or a recent grub4dos 0.4.6a: http://grub4dos.chenall.net/downloads/grub4dos-0.4.6a-2019-06-17/ (later versions may do as well, but since they are experimental you'd better stick to older ones). In some cases (it really depends on moptherbards) you may need to map the floppy also to (fd1) besides (fd0). jaclaz