jaclaz

98 should work just fine on a USB stick, though it may depend on the hardware (motherboard), try following this, the only mod needed is MaxPhysPage value in system.ini and starting the setup with a particular set of parameters from DOS: https://www.youtube.com/watch?v=5Qd7cDbtwj4 setup /c /it /p a;b jaclaz

On BIOS, one of the things that "made a difference" was the presence of TWO (primary) partitions, If you check the RMPREPUSB, you will see how it has an option to make a second (tiny, one cylinder) hidden partition. It is possible (but not given) that even the UEFI implementation on those motherboards is sensible to it, even if the GPT should only have one entry in partition table (the "protective" one) there is the possibility to make a "hybrid" partitioning, with the added second partition entry, no way to know if it will do anything, of course. There is a nice page by Roderick Smith (author of Gdisk) about hybrid MBR's: https://www.rodsbooks.com/gdisk/hybrid.html There are other workarounds, check: http://reboot.pro/index.php?showtopic=12436 it could also be that the "removable" bit is actually meaningful in your specific BIOS/UEFI. jaclaz

Of course it depends on the specific stick controller AND on the specific BIOS. Most of the sticks have a setting (called in jargon "removable" bit) that can be "flipped" by the Manufacturer Tool. Whether a Manufacturer Tool is available or not (and if even minimal instructions/docs for its use exist) vary greatly on the specific make/model of the controller inside the stick. Sandisk (that you mentioned in your other post) is a known exception for two reasons, their tools never leaked (AFAIK) and their controllers are not programmable via the USB connector (as well AFAIK they have on the PCB some contacts that can - presumably - be used with a TTL or similar serial adapter). But - generally speaking - this "removable bit" does not in itself affect in any way the BIOS (and more generally "real mode") part of the booting, issues can happen later in the booting phase and/or in the way the OS behaves after booting. If the manufacturer tool is available and you have the guts for it (a mistake in using it may well make the device not working anymore) setting the stick as "fixed" is a good idea, but there are filter drivers for Windows that can make the "flipping" at OS level, historically a driver called cfadisk.sys was made (originally for CF cards) then a couple similar ones came out dummydisk.sys and its "reversed version" rdummy.sys (making a fixed device removable), the most recent one is diskmod.sys that offers some other features: http://reboot.pro/index.php?showtopic=9461 http://reboot.pro/topic/22249-diskmod/ Windows before 10 treated "removable" (USB) devices different from "fixed", i.e. the stick was either unpartitioned or - if partitioned - only one (first) partition would have been mounted/assigned a drive letter, so the filter driver was needed whenever multiple partitions were needed or wanted, one of the very few good things that Windows 10 did was to allow multiple partitions on removable media, so that nowadays cases where the filter driver is needed are rare. Anyway all the above has historically been irrelevant when it comes to "booting" (defined for the scope of this post as the initial part of booting, up to the choices in the boot manager configuration files). Problems in this early part usually derive from (not necessarily in order of relevance): 1) "wrong" HS geometry of the partitioning/formatting (almost anything partitioned under windows will be 255/63, which may or may not suitable) 2) errors in the MBR or PBR code or data 3) strange settings or quirks in the motherboard BIOS, including (but not limited to) "allergy" to specific MBR code, limits on geometry depending on size of the device, device size limits, and more, like needing two partitions on the stick The above is about BIOS/MBR, I hate to say this but (with some exceptions) UEFI booting often has less issues as it does not usually suffer from #1 and #2 above. You will need to describe the issues you are having and the specific sticks and motherboards involved (and of course the boot manager/OS you are trying to boot). jaclaz

Maybe the issue is "elsewhere", there is no reason why a "normal" USB stick (properly prepared/partitioned/formatted) should not be bootable. There is actually in the USB stick controller a "flippable" bit that can tell to the OS whether the device is "removable" or "fixed", but that does not change if it is bootable or not. The issue could be related to the motherboard BIOS/UEFI settings or (for whatever reasons) expecting something "particular". Is that MBR or GPT? And are you booting BIOS or UEFI? You could start a new thread, possibly here: https://msfn.org/board/forum/169-hard-drive-and-removable-media/ detailing the make/model of the stick, how you partitioned/formatted it, etc., and we could check it and (hopefully) find out a way to make it bootable (up to loading - say - the BOOTMGR and BCD ). jaclaz

https://www.doomi.ch/mtcp-tcp-ip-for-dos/ http://wiki.freedos.org/wiki/index.php/Networking_FreeDOS_-_mTCP http://www.brutman.com/mTCP/ jaclaz

Those are hex values, so - if they represent a readable string - they are somehow encoded/encrypted/transformed. There are like a zillion ways this could have been done, maybe - just maybe - if you provide some actual info (name/path of the key, what the value should represent, etc.) then someone might know which specific encoding is it. jaclaz

The motor is usually powered at 12V, very likely it can stand a 15-20% voltage increase, at 14.4 V it would probably reach 8,640 RPM, give or take 33 and1/2 tolerance. You can replace some 15-20 SMT components on the PCB board and write a new firmware for it. You only need 5-10 years in UNI+experience in hardware engineering, some 5-10 years in software development for embedded devices, another 5-10 years experience with access to hard disk manufacturers codebase, a semiconductor factory willing to create a new SMOOTH chip and you will probably have a working prototype. Ah, wait, before I forget, you will also need a soldering iron and a USB to TTL converter. jaclaz

Sure. https://en.wikipedia.org/wiki/Sleepwalking#Sleepwalking_as_a_legal_defense Better than "officer, the Devil made me do it...", still ... jaclaz

Fact is that noone really knows for sure, some versions are plausible. others not so much: https://unix.stackexchange.com/questions/6804/what-does-dd-stand-for jaclaz

dd (which is the shortening of copy and convert , don't ask [1]) is a traditional Unix/Linux command that simply copies bytes (or in the case of hard disks sectors/blocks) as they are. Of course there are several other programs that do the same, either command line or GUI. dd-like or "forensic sound" means that the output (be it an image or directly another device) is EXACTLY the same as the input, i.e. it is an EXACT, 1:1 copy. For whole disks, it means that the target image (or the cloned disk) is exactly the same size as the source, as it contains all sectors, unlike many (commercial) cloning/imaging tools that - in order to save time/space - either interpret the filesystem and only copy files indexed in it or (swiftly?) ignore already 00ed sectors in the source, usually adopting proprietary file formats for the images (an image taken with dd is usually called RAW as it contains nothing but the contents of the source, no headers, no footers, no checksums, etc.). About 1 or 0's it doesn't really matter, the 00 is a convention, new disks (usually) are all 00's, if you want to check at the bit level the values used are (normally) 55 and AA hex, i.e. 01010101 10101010 so that (in two passes) every bit is actually flipped. jaclaz [1] If you need to ask, and have some time, enjoy: http://reboot.pro/index.php?showtopic=15207

Well, it is useful in some cases of data recovery, in the sense that for some time after a 00 wipe, deleted/de-indexed data will be easier to rebuild, but the effect is only marginal (and temporary, once the disk has been used for some time intensively, and possibly filled up there won't be many 00ed sectors anymore). Another reason (not particularly relevant on modern disks) is that when wiping a disk you are write-touching (and verifying) each and every sector, so that possible "bad" sectors or areas that weren't detected as such by the controller will come up (and be replaced or excluded). It has to be considered that, exactly because each and every sector is touched (and it is done sequentially, at the fastest possible speed, in a single session) it is actually provoking stress to the disk (just like restoring a dd-like image), it is a good idea, when possible, to make sure that the disk is cooled adequately (and if needed add a fan to keep it cool), with today largish sizes, a 00 wipe or a dd-like copy restore often takes several hours and for that long period of time the disk is working continuously at the fastest speed possible, generating heat without the inactivity times that in normal operation would allow it to cool down. jaclaz

... that has nothing to do with USB, let alone with WinSetupFromUSB with GUI (this topic) . jaclaz

Yep, but the "traditional", caveman approach I always used (integral dd copy) is not faster than "specific tools" (that can skip unused sectors) unless the volume is full up to the brim. Making a backup of first sector (to be later restored or used as source to replicate the disk signature only, that can be done even with grub4dos before booting to windows) takes only a few seconds, costs nothing and allows to gave the two disks mounted at the same time if needed. jaclaz

That is another aspect, the (ab) use of hardlinks in more recent MS operating systems, this has started (AFAIK) with 7. But on NTFS the problem should only be a lot more space taken on a "flat" (without hard links) filesystem. For 10 it seems like there is the possibility of a hard link migration store: https://learn.microsoft.com/en-us/windows/deployment/usmt/usmt-hard-link-migration-store (I have no experience whatsoever with these Scanstate and Loadstate tools, with the /hardlink switch) jaclaz

Good to know. So, it is very possible that this is the 0.1% hedge case, though the main culprit still seems to me the UEFI NTFS driver, I mean, if the mkfs.ntfs tool did anything "wrong" chkdsk would have surely throw a fit and/or the root directory would have had some other issues under windows. jaclaz

I don't think that gparted can actually format (apply a filesystem to) a NTFS volume, it may create the partition but the actual filesystem should be created by Windows . Or the feature has been added to it? Otherwise it should be irrelevant, unless (for whatever reasons) the GPT partition entry triggers something strange in the MS format tool used. Anyway the confirmation with your next experiment will be useful. jaclaz

It is NOT renaming it, it is mounting the System file (of the copied system) under a temporary hive in the current Registry (of the PE, or other booted OS) in order to edit values. It is either that (mount in current registry under new name) or using an offline registry editor tool. AFAIK some of the new Windows (I believe since 8 or 8.1, but I may well be wrong and it is only since 10) do not (anymore) automagically and silently change the Disk Signature, when they detect a "duplicated" disk they put it in "offline" mode. Only when you manually (why?) put it online again the disk signature will be changed to avoid the collision. jaclaz

Yes, or using an offline Registry editor. But there are TWO keys involved, one is easy (the \DosDevices\C: one), the other one will be something *like* "\??\Volume{317d75f2-eaca-11eb-90ac-806d6172696f}", but it is easily identifiable as it has the same value/contents of the "\DosDevices\C:". And here you open a (small) can of worms, there is another thing that will change (another reason why it won't be a "clone"), the actual 317d75f2-eaca-11eb-90ac-806d6172696f is a V1 UUID that is generated the fitrst time the XP "sees" (and mounts) the volume, and V1 UUID's are generated from some hardware values (MAC address) and from the current date/time. This won't prevent the XP with the newly generated keys to work, of course, still you will alter a data point. It has to be tested, but I don't think that the disk signature/drive letter assignment or the Registry have changed. jaclaz

Robocopy is fine, only the result isn't a "Clone". it is a "Copy". But it should work fine, the possible issue (that you seemingly did NOT have[1]) is with Disk Signature, clearly the SSD has a different disk signature from the original disk. XP identifies partitions/volumes (and assigns drive letters to them) through a combination of disk signature+offset to the beginning of the volume stored in the Registry. Normally you would have to either: 1) restore on the newly initialized SSD the "old" disk signature OR: 2) delete the related keys under HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices (or the whole set of keys under that path) In case #1 XP would boot exactly as before (no possible issues [2]) In case #2 XP would recreate the proper keys from the disk and partition(s)/volume(s) data (this in some cases may lead to a different drive letter assignment) So, all in all, you were lucky (or your setup was so simple that the failsafe provisions implemented in the OS worked), after all life is good . Rest assured that in case of multiple disks/multiple volumes/manually assigned drive letters you need one (or both) the above described procedures in order to boot and have the same drive letter assignment as before, not really-really a problem, since the worst that can happen would be a failure to boot, but nothing would be "damaged" and to fix it is just a matter of deleting a couple keys from a booted PE and reboot. Though in theory the disk signature could be used by any other program, in practice this doesn't happen AFAIK (most probably because the sheer existence of it is not documented by the good MS guys) Good to know that in your case it wasn't needed. jaclaz [1] there is a possible explanation, being that you had at first boot only the SSD and only a partition on it, so the XP auto-fixed the Registry, all in all it had an assignment of C: to a disk and volume that was not (anymore) present and the only volume it found was the single one on the SSD, from which it booted, so it had to assign to it drive letter C:, this is very likely a sort of failsafe (not entirely unlike the one in NTLDR that attempts booting from C:1Windows if BOOT.INI is not found. [2] except in your specific case , as it would not have worked as you would have had a same disk signature but a wrong volume offset (since you aligned it to 1 MB or 2048 sectors instead of the traditional 63)

Latest news I have: https://msfn.org/board/topic/182107-grub4dos-for-uefi/page/4/#comment-1233863 In a nutshell, there were some issues with the hosting/provider AND the actual machine, so it was shut down and Nuno is going to re-deploy on a new machine from last backup. jaclaz

I was thinking that you could make a short video of when you do these updates, and create a Youtube channel to publish these videos, the simple text description may not transmit to the audience enough the emotions you feel when implementing these updates. Besides (right now) the site gives a 404: jaclaz

And don't forget, other reasons why you could be dead, a short, non exhaustive list: floods lightnings meteorites wars trains derailing drunk drivers or more generally traffic accidents robbers and rapists other crazy people with weapons slipping in your bathroom falling from stairs poison in your food or environment lethal viruses and bacteria ... It's a tough world. jaclaz

Isn't it inside the Windows 98 reskit? A copy is on archive.org, cannot say if it contains what you are looking for: https://archive.org/details/mswin98rskt jaclaz EDIT: it should be also on the "normal" 98 install CD: https://kompy.info/deploying-windows-98-using-batch-98-and-infinst-exe-table-of-c.html#Creating_the_Msbatch.inf

https://en.wikipedia.org/wiki/Kaspersky_bans_and_allegations_of_Russian_government_ties jaclaz

I see now, ignored (content) is not blocked (user) in my dictionary, thanks. I actually have (since years) a couple users' signatures ignored (only because they are confounding me). Didn't know I was "unblockable", it is years that I am not anymore a mod, maybe something remained sticky from back then, or maybe I am just senior enough. jaclaz