jaclaz

No. DOS needs BIOS services/interrupts (like "conventional" grub4dos). jaclaz

Yep but your tools may be deceiving . 7-zip is basically an archive compressor and file manager (and exceptionally good at those ) but it (necessarily and understandably) uses some simplifications in the way it shows data. If you want to actually see what is in the .iso you need other tools, namely, short of an hex editor, ISOBUSTER (the free version is enough): https://www.isobuster.com/license-models.php Back to the topic, specifically, what 7-zip renders as /[BOOT]/boot.img on a XP install CD is what is generally called "Microsoft Corporation.img", it is a no-emulation bootsector, 2048 bytes in size, containing code not entirely unlike the MBR or PBR code that does two things: 1) invokes /I386/BOOTFIX.BIN <- the thing that prompts "press any key to boot from CD" 2) loads /I386/SETUPLDR.BIN In grub4dos, this is in practice the same: map /mynice.iso (0xff) map --hook root (0xff) chainloader /I386/setupldr.bin jaclaz

Only a a single anecdata/datapoint, a couple VIA EPIA motherboards (small factor ones, mini-ITX) dating back to 2002/2003 are still going strong here. Not the most powerful rigs around, either 600 MHz passive cooled or 1 GHz with a little fan, but still more than enough for 9x/ME (mine actually run either NT4 or 2K). It is very possible that being low-low power the (limited) amount of heat generated avoided the capacitor issues (or maybe they have "good" capacitors from the start). jaclaz

Yep, as always happens to "evolved" projects, WinSetupFromUSB has accumulated over the years layers and layers of "crust", to the point that the "core" has been "lost" or however is extremely well hidden. Little by little complications have been added to cover "particular" cases that came out in the experiments (like multi-internal hard disks, "queer" VID/PID assigned to USB devices, the occasional BIOS that doesn't *like* this - or that - partitioning or driver, etc.). It is better, in your case with an even more "queer" BIOS, to start from simpler, more direct methods. Do not worry about CaSe SeNsItIvEnEsS in Windows (DOS and Windows are NOT CaSe SeNsItIvE), the issue (if any) may come on Unix/Linux OS's AND - since grub4dos is actually CaSe SeNsItIvE (on CDFS but not on NTFS or FAT) a minimum of attention/diligence is needed when issuing grub4dos commands. But no problem, if you wish to actually worry , AND choose the red pill, we do have resources for you: you have no idea how deep is the rabbit hole, but, heck, you asked for it. https://web.archive.org/web/20151007005513/http://www.911cd.net/forums//index.php?showtopic=25612 jaclaz dashun9_01.zip

NO. NO. NO. Meaning: NO, there is NO [BOOT] directory on a CD/ISO (but 7-zip will "render" the contents like that), NO, the boot.img may be a no-emulation boot image or a floppy (or superfloppy) emulation one (or even, in some cases, a hd emulation one) NO, you cannot chainload that image "by itself". When you do: map /mynice.iso (0xff) map --hook chainloader (0xff) you are doing exactly that (chainloading what you see as /[BOOT]/boot.img in 7-zip), but you are doing that "correctly", i.e. in context. The whole point that you are ignoring is the concept of HAL. Any NT based system has this intermediate layer (Hardware Abstraction Layer) between a device and the OS. For each and every device that the BIOS "declares" (no matter if real or virtual) the (in the case of XP) NTDETECT.COM, check it and connects it to the booting OS through a driver. In the case of a "real" device, the driver is automatically loaded (and thus the device is accessible to the OS) in most cases. In the case of a "virtual" device the driver is not built-in AND there must be a way to have it "hook" the device presented by BIOS, hence in the given threads either Firadisk or Winvblock drivers are used (these are drivers that can read info from the grubdos settings, one way or the other) OR - if the virtual cd is not the boot device, it is mounted later by using a more normal virtual CD/image driver (such as - commonly - IMDISK). The point is not (or not only) about drive letter assignment, but rather with having *something* to which a drive letter can be assigned. jaclaz

Maybe in this case you need then to "abandon" WinsetupFromUSB and use another approach. Two (please read as three, which means four, actually five) available: 1) offline installation (using WINNT32.EXE on the disk temporarily connected to another computer) 2) good ol' DOS method with WINNT.EXE 3) "plain" install (again using WINNT32.exe) from a PE booted from the stick (if it can be booted, but I don't see why it shouldn't, at the mot using grub4dos to remap disks) 4 and 5) one of the two available "direct from iso with grub4dos" (memory or directly mapped, this, as well as the above may depend on amount of RAM available) I guess we already had this conversation: You have pesky hardware/BIOS, so any of the above may need corrections/adaptations, the "safer" (in the sense of having more chances of success) are #1, #2 and #3 as the installation happens without the USB stick involved in the process (if not as source). On the other hand, now that you are getting more familiar with grub4dos, you can probably try the one (or the other) "install from iso with gtub4dos" methods, in your paticular case it is a hit-and-miss game, no certain outcome. jaclaz

You mean mapping (fd0) to (hd1), I believe? Yep that goes into the root of the USB stick, but maybe it needs to be changed also in \I386\ folder of the .iso , it has to be seen, your is an "unusual" setup. The general idea (of the simplified setup) is to have the internal hard disk mapped to (hd0) and the USB stick mappped to (hd1), so: map (fd0) (hd1) map --hook geometry (hd0) geometry (hd1) find --set-root /WINSETUP/XPpSP3.ISO map -mem /WINSETUP/XPpSP3.ISO (0xff) map --hook root (0xff) chainloader /I386/SETUPLDR.BIN boot jaclaz

But you get to grub4dos (on the USB)? If yes, it must be mapped to *something* (maybe (fd0) or (fd1), and then you can remap it to a hard disk) and you can also try the internal (to grub4dos) USB stack. (You may need to update grub4dos to a more recent version). http://reboot.pro/topic/19883-improve-grub4dos-boot-speeds-by-using-the-046-usb-driver/ Cannot say if it may detect the USB stick in your case. But there was at least one case where *something* was seen as floppy and it could be remapped to a hard disk device (the thread is unrelated, but the actual remapping is relevant): http://reboot.pro/topic/20907-how-to-boot-windows-installerwtg-through-bios-off-gpt-partitioned-removable-usb-drive/page-3#entry208685 jaclaz

Sure it can be done. It is not *another* boot manager, it is grub4dos extended to support UEFI (as opposed to BIOS). A number of commands (see the post by Alacran) have been removed (as they have been made unneeded by the re-writing of some other commands) AND at the moment a number of grub4dos commands have not yet been implemented, while some concepts may have become obsolete because of different features of UEFI (as compared to BIOS), only as an example, chainloading a volume bootsector makes not any sense anymore, as to boot in UEFI you need to execute a (UEFI) loader. You should consider it as "beta" or "experimental" and "in evolution". jaclaz

Hmmm. But can it boot from the USB (as ZIP)? (I mean, no matter how the BIOS sees the USB, as long as it can see it and load *somehow* the grub4dos on it, we can try remapping it in grub4dos), I strongly suspect that the PloP is the issue. Alternatively, if the issue is the USB current partitioning/format we can try re-partitioning it in such a way that the BIOS sees it as ZIP and can boot it. What happens if you "move" the partition entry to 4th slot? jaclaz

Yep, those are "queer" data, The 1/1/1 to be corresponding to 16128 implies a 255/63 geometry. The 972/240/36 is then not on a cylinder boundary, but neither justifies the issue. BUT, re-reading your post, you are using PloP installed on the internal hard disk, while - if I remember correctly - the shiftd.bat is written assuming that the PloP is loaded by itself (or however from the USB) and anyway PloP support is "ecperimental". Try NOT using the Winsetup.lst. The first part of setup entry in winsetup.lst, simplified (as you do not need the DPMS.iso) amounts to a few commands, in the case of a "normal" setup with an USB stick and a single internal hard disk: geometry (hd0) geometry (hd1) map (hd0) (hd1) map (hd1) (hd0) map --hook geometry (hd0) geometry (hd1) find --set-root /WINSETUP/XPpSP3.ISO map -mem /WINSETUP/XPpSP3.ISO (0xff) map --hook root (0xff) chainloader /I386/SETUPLDR.BIN boot Then - if first part works - second part might be: geometry (hd0) geometry (hd1) map (hd0) (hd1) map (hd1) (hd0) map --hook geometry (hd0) geometry (hd1) root (hd0,0) chainloader +1 boot The geometry commands are there only to check the hard disk order before and after the attempt to remap them. jaclaz

The IDE/SATA is irrelevant as long as the disk is accessible by BIOS. As well usage of plop should be "transparent", though there may be something connected to the exact way the "ZIP" disk is made, there are two types of original ZIP disk formats: 1) partitioned, where there is a single, active partition on slot #3 of partition table 2) non-partitioned, aka "superfloppy" additionally (original) ZIP disks have a particular geometry (64/32 if i recall correctly), the actual motherboard BIOS may require this or that format or possibly plop is more permissive It is possible that shiftd.bat is tricked by some of these particular settings (if any). Let's first see how your USB stick is partitioned. You could use my little script, MBRview.g4b, but it is on reboot.pro (which is currently offline), I am attaching a copy. Alternatively, in grub4dos it would be enough to issue: cat --hex --skip=446 (hd0)0+1 and cat --hex --skip=446 (hd1)0+1 and report. it is possible that some changes are needed in shiftd.bat or that its execution can be bypassed and disk (re-)mapping can be done manually instead. Do post the contents of the shiftd.bat and of the menu.lst you are using now, as I seem to remember that there are various version of them, so we are sure we are using the same data. jaclaz mbrview-no-wenv.zip

To be fair, you are actually SHOUTING from experience. jaclaz

https://www.cable.co.uk/broadband/pricing/worldwide-comparison/ Ukraine is #2 this year (it was #1 last year) jaclaz

I will gladly rephrase: As: Only as a marginal note, I just happened to notice that nomachine is still XP compatible (more than one year later last report, on another thread, by RainyShadow). [1] jaclaz [1] it remains only a note and a marginal one, nothing more, nothing less.

Only as a marginal note, I just saw that nomachine is XP compatible: https://www.nomachine.com/download jaclaz

What differences (if any) are there in IPCONFIG /ALL run with DHCP on and with static address? Run with the DHCP on, run IPCONFIG /ALL>C:\dhcp_ipconfig.txt. Set the static IP, net mask and gateway the same manually and run again IPCONFIG /ALL>C:\static_ipconfig.txt. Does the behaviour remains the same? I.e. is the behaviour independent from a same IP address assigned to the machine? The behaviour you decribe seems like connected to the gateway, so Dylan Cruz may be right, but he doesn't specify where to uncheck that setting (that BTW I doubt is called exactly as he stated). Could it be the case of some port forwarding? i.e. what do you get if you run: netsh interface portproxy show all ? Anyway, unless you have particular settings, a: netsh interface portproxy reset should do no harm. jaclaz

Have you tried the (old version) PDF-XChange Viewer? : https://www.tracker-software.com/product/pdf-xchange-viewer It has a "typewriter" mode that should be what you are looking for. jaclaz

The Winnt.exe runs from DOS, this implies FAT16/32 AND NOT Ntfs (but you can convert the volume later), it will be slower in the copying of files. Beides it misses the features of WINNT32.exe to make an "offline" install (i.e. the syspart/makelocalsource/tempdrive/noreboot/etc): https://www.informit.com/articles/article.aspx?p=102260&seqNum=6 A "complete" howto (via USB and DOS, well before the "install XP from USB was born) is here (via Wayback Machine): https://web.archive.org/web/20160417164143/http://www.911cd.net/forums//index.php?showtopic=16713 What happens when you run Winnt.exe (or Winnt32.exe) is basically: 1) the creation on the active, primary partition of the disk of the (temporary) folders: $WIN_NT$.~BT $WIN_NT$.~LS 2) the writing of a Disk signature (if there isn't already one) 3) the writing or updating of the MBR boot code 4) the writing or updating of the PBR boot code 5) the creation of a (temporary) BOOT.INI and the copying of NTLDR+NTDETECT.COM in the root of the volume At next reboot the files in $WIN_NT$.~BT will be used to boot and the ones in $WIN_NT$.~LS will be used to install. At next reboot the system will actually be installed and the temporary files/folders deleted. Yes and no, drive lettering during the install is not that easy to manage, and it is (slightly) different from when the OS is already installed. Search for "migrate.inf", you might need to use it. Besides, you need to be familiar with arcpaths, as - again it depends on the EXACT method and devices involved - there may be the need to change paths in BOOT.INI or txtsetup.sif. Using grub4dos re-mapping features, most of these issue can be worked around, but it is not the "only" way to deal with (possible, but not necessarily happening) issues with booting and/or drive lettering. jaclaz

No, If you want to install from another system (meaning with the hard disk attached to another PC) you need to use WINNT.EXE or WINNT32.exe, NOT setup.exe, that is the whole point. What happens with syspart/makelocalsource/noreboot is not an actual install, but rather the creation of the same booting situation as a normal install procedure, that will start only when you reboot on the target machine. There is a whole section of the board dedicated to different ways to install XP from USB, Ventoy (which is an exceptionally good software BTW) is simply not suited/tested enough for XP installs, the various methods here have been used successfully for years: https://msfn.org/board/forum/157-install-windows-from-usb/ You will have anyway issues (that can be worked around) with: 1) drive letters assignment 2) multiboot with the existing OS hence you need to get familiar with grub4dos, the EXACT way your disk currently boots and how (EXACTLY) it is partitioned makes a difference, as most tools/tutorials are about installing XP from USB on an "empty" disk, and your current situation cause the need to some changes/avoiding automatic settings. jaclaz

If it works (if doesn't work for *all* Dos programs), DosBox. Otherwise Qemu, where you can install a "real" DOS (and also a Win3.x or 9x). Next would be IMHO VirtualBox. Since there is a "performance penality" in running a VM, it makes more sense to use in the VM the simpler/less resource hungry OS (i.e. you can install in the - say - Qemu VM an XP, but it will be slower than DOS). jaclaz

But the target machine can boot from USB? Or you want/need to prepare the internal hard disk in such a way that, once transferred, the XP can be installed (or it is already installed)? Forget (for one moment) anything about the CD. The actual common way to install an XP, well before USB existed, was to copy the \i386 directory off the CD and install the XP by either DOS (via WINNT.EXE) or from another booted windows (via WINNT32,exe), no need of an actual CD drive, if not to get the \i386 directory out of it. There are/were anyway some limitations by using WINNT.EXE, connected to the OS they are booted from, type of filesystem, sizes of disks, etc. The simplest, if you can connect that hard disk as secondary disk to a PC running 2K or XP would be running WInnt32 from it, otherwise, using a PE (1.x, aka BartPE or similar, or a later version), https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/winnt32 Later ways to install an XP "directly" from a .iso image of the CD (residing on an external USB device) were developed. The same methods can be used - with some small modifications - to do the same from a .iso image resident on the internal hard disk. https://msfn.org/board/topic/149675-install-xp-from-a-iso-file/ https://msfn.org/board/topic/137714-install-xp-from-a-ram-loaded-iso-image/ but they are anyway a complication, when compared to a "plain" WINNT32.exe setup with tempdrive, syspart and makelocalsource parameters. jaclaz

But there isn't a simple answer. CD and DVD's can be "normal", floppy emulation or hard disk emulation. The BIOS knows that the device is an optical media and chainloads sector 16 (size of sector on optical media is 2048 bytes). The contents of that boot sector determine what happens next, it can be a "straight" bootsector loading a OS loader or system file or more complex multibootmanager, like syslinux/isolinux or GRUB/GRUB2/grub4dos that can mount filesystems, etc. before loading the OS. But I don't see what the way a CD/DVD can boot has connection to "your situation" (which is not at all clear to me). If the question i "can I boot from a CD image saved on hard disk as if it was a CD?" the answer is yes, depending on what (which OS) you want to boot syslinux/isolinux, GRUB2 and grub4dos are suitable[1], but you need to provide more details if you need assistance on the exact "howto". jaclaz [1] personally I would go for grub4dos which IMNSHO is more flexible/has more features, but it depend on the exact requirements.

Maybe you are having the NULL issue at boot . https://askubuntu.com/questions/1218006/cant-boot-from-usb-drive-on-lg-gram-running-windows-10-pro Drivers for Window 8 might be another problem, though. jaclaz