jaclaz

The differences may be due (indirectly) to the sizes of the images, with small disks (or images) it often happens that different programs or BIOSes or OSes attribute a different geometry or calculate differently the geometry, and then similarly both the partitioning and formatting processes may result in differently sized voiumes. jaclaz

No, maybe that applies to (large) corporate environment, in smaller ones (while there could still exist the odd old database based program) the (say) invoice must be made with a new format (that the old program doesn't support) and must be loaded to a given website (that possibly only supports a given browser, in a recent version), then you need to access another government connected website (that supports another browser) and the bank (which has been updated to some new dashboard, that you need not but that as well requires a "current" browser). jaclaz

Poor little gamers, I feel for them, I cannot imagine how tough it could be for them living without being able to play modern games. Still I am more concerned by all the small (and large) offices and businesses that actually need to update OS and programs continuously to be able to do those minor, trifling, things, like calculating and paying wages and taxes, creating and paying invoices, dealing with Law requirements, etc.. jaclaz

Sure, grub4dos mapping is the easiest/most convenient, though of course it has the limitation of needing to either reboot or know before booting that you will need to mount the image. Being essentiially a plain BIOS mapping it surely works reliably in DOS, under the Win9x GUI I would be anyway careful. I don't think that anyone is going (today) to attempt writing a driver/program for DOS/Win9x of such complexity. I believe that one of the reasons why there aren't as many - please read as "none" - such programs/drivers for Win95 while there are (were) quite a few for NT and 2K is due to the lack of some handy sub-systems/cpmponents. It is more likely that some of the good people working on FreeDOS may create something (for DOS/FreeDOS), more like srdisk or XMSdisk, but for filedisk mounting as opposed to ramdisk. At least good ol' SHSUFDRV: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/shsufdrv/ http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/shsufdrv/fdrv-3.txt is fine with DOS and WIn 3.x, but not with Win9x. jaclaz EDIT: Before I forget, check also this: http://hp.vector.co.jp/authors/VA013937/editdisk/index_e.html (again not what you asked for but maybe useful)

Not what you asked for, but older versions of Diskinternals Linuxreader *should* run on 9x (at least there is a .vxd in version 2.0). It allows mounting disk images and save files from them (read only access), but no drive letter. jaclaz

Good morning, y'all. jaclaz

@legacyfan Was it really needed to revive a 2018 "Introduce yourself" topic (BTW by someone that in the meantime unsubscribed - the Guest in his name means that he is not a member anymore)? @XPerceniol and @msfntor Please, do check dates of posts AND context when replying, I can understand how you have this urge to exchange niceties at every possible occasion, but maybe the handful of topics on which you already do this daily are enough? jaclaz

Yep, from what I can understand the IGN in ignrando: https://geoservices.ign.fr/ignrando is the national geographic institute, not a company, but rather (directly or indirectly) a department of the government, I don't think they would do anything based on a single complain (nor, for that matters, on many complains ). jaclaz

What would you expect? https://www.imdb.com/title/tt0079470/quotes/qt0471984 jaclaz

Now that reboot.pro is online again, here is the thread about GOP hardware and windows 7: http://reboot.pro/index.php?showtopic=21108 Maybe useful, maybe not. jaclaz

Maybe you need to use devcon (no idea if it works on 10 or 11), on older systems it was the only tool capable of re-starting some devices without reboot: https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon-examples We have a copy re-compiled from the original MS source code here: but possibly you will need a neer version from the WDK: https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon# jaclaz

There worm drive: https://en.wikipedia.org/wiki/Worm_drive https://www.imdb.com/title/tt0072431/quotes/qt0484648 jaclaz

Is it the same (13 pin) as this one? (this is attributed to the VL5) https://pinoutguide.com/Power/hp_vectravl5_power_pinout.shtml jaclaz Edit: Here is picture of the actual connector: https://h30434.www3.hp.com/t5/Desktop-Hardware-and-Upgrade-Questions/HP-Vectra-486-33VL-PSU/td-p/7970352

There is no mountain, OP is in a climbing gym. As long as there is awareness.of the futility, it's alright. Still, floppies are not a good substitute to recreate the ZIP disk experience, and it is not like your friend played with floppy disk images in a VM. A small gift for your friend, zippier: https://www.flickr.com/photos/dvsjr/albums/1489687 jaclaz

Not to be more grumpy that usual, but then your project makes no sense whatever. If you don't have the actual hardware AND some very valid reasons to use ZIP disks, there is not any reason (if not some peculiar form of masochism ) to choose a format (the ZIP disk) that is poorly documented, terribly supported by the various (real or virtual) BIOSes, and cannot be re-used by anyone else (if not in a VM) unless these other users have the actual hardware (and BTW something developed in a virtual environment very rarely will run on real hardware without changes). Just use a "normal" disk image, make it 100 Mb or so if you like the challenge of using a small size system. jaclaz

"Zip disk" is meaningless in the context of "drivers". There used to be 5 (at least[1]) ZIP disk drives, with different interfaces (and obviously difference drivers were needed for them): 1) Parallel <- normally NOT bootable 2) SCSI 3) IDE 4) ATAPI (almost same as above) 5) USB The "type the name of the command interpreter" error you are having (I presume it to be in text mode) is coming from the underlying DOS, it happens well before the Windows 95 (the GUI part) loads (and thus the needed drivers). Is the error you are having similar to this screenshot, right? https://www.betaarchive.com/forum/viewtopic.php?t=35451 If this is the case it is happening at a time when the boot is from the disk supported by the BIOS, no driver is needed/in use at this time. Either you have command.com missing or - for some reasons - the DOS cannot access the ZIP disk as C:\ (or as another drive letter, if it is not partitioned it may be A:\). This may have several reasons behind, a common one (but again it may depend on which specific Zip disk drive you are using) is the way the disk has been partitioned (ZIP disk "standard" was an active partition in fourth MBR partition table entry) or "not partitioned" (formatted as superfloppy), and in the specific BIOS you have and how it behaves in these cases, additionally ZIP disks used to have a "peculiar" CHS geometry, which may or may not be involved in the issue. It is also possible that again for *some reasons* the SYS.COM didn't transfer COMMAND.COM properly or it (or its directory entry) is corrupted. some related to ZIP disks info: https://www.win.tue.nl/~aeb/linux/zip/zip-1.html Maybe if you provide some details about the exact hardware you are using and the exact way you prepared the disk, a solution or a workaround could be suggested. jaclaz [1] a more detailed, though not necessarily complete, list is here: http://reboot.pro/index.php?showtopic=12436&p=108810

So it definitely is (was) something "queer" with the USB drivers you had before, and that now are probably either another set of drivers or re-initlalized/reinstalled. I have no idea if Windows 98 uses or can use "filter drivers" (like NT family, like the mentioned cfadisk, dummydisk, etc. ) what you reported might be related to one such filter drivers (installed and "paired" to either the whole USB subsystem or to that specific stick). Still in the NT world, there are similar enough reported misbehaviours with CD/DVD players due to (upper and lower) filter drivers related entries in the Registry, so it could have also been some Registry related issue, hopefully corrected by the sort of "reset" you did by disabling legacy USB in BIOS. jaclaz

Duel->Dual https://grammarist.com/spelling/dual-duel/ jaclaz

So the issue is not the BIOS (in itself) nor (probably) the USB drivers (in themselves) it is a combination of the two. Pure speculation, to be checked/confirmed: Case A, stick connected before booting: A1) when legacy USB is disabled in BIOS the OS knows nothing about the USB stick and when the drivers load they load/mount the device fully A2) when legacy BIOS is enabled in BIOS the stick is mapped by BIOS and when the USB drivers load they *somehow* load/mount the device partially Case B, stick connected after booting: B1) no matter if legacy USB is enabled or disabled in BIOS, the OS knows nothing about the USB stick until the drivers load and ... (either mount the stick fully or not) In theory A1 and B1 should behave the same, but there could be a difference between the USB drivers enumerating the stick when loading (case A1) or after having already loaded (case B1). jaclaz

FDISK won't allow anyway making more than one (primary) partition, the second can only be extended (with inside it one or more volumes), but it shouldn't crash on devices with more than one primary (i.e. it is another sign that *something* is "wrong" and specific to USB devices that are not BIOS mapped). jaclaz

Only for the record since 2010 (or was it 2007?) or so Office formats (.docx and .xlsx) are actually zip files, and of course android .pkg are also .zip files, as such the whole preamble is pure nonsense, then the article goes on to list a case in which the archive is encrypted and prompts the user to download a fake pdf that is a html that is a wrapper that prompts user to input a password to view the contents of the archive. Surprisingly the password is used to decrypt the archive. So many words to say: NEVER trust anything that comes from someone you don't know, particularly if it has an attachment, let alone an encrypted file that prompts you for decryption Besides the actual HP/Wolf report being largely useless for anything except some vague statistical data, I rarely happen to read poorly written articles such as this one, the Author cannot even cite the right percentage written in the report (that is 44% and not 42%) then suggests that all these archives behave like a few specific malwares (that represent only a minimal percentage of the malware delivered via an archive). jaclaz

RMPREPUSB (to workaround a similar issue in some BIOSes) creates (optionally) a second (very small, only one cylinder, and with a hidden ID, 21 if I recall correctly) partition, but that is intended for bootable sticks, if you see multiple partitions than *somehow* the MBR is read (though it is still possible that it is not "hooked"). To make a comparison, on NT systems, the known IMDISK driver (which should be called IMVOLUME, instead as it does not mount the disk, but rather the volume) "hooks" at a level "higher than disk manager/diskpart. Does FDISK see the disk? <- I believe that all other tools (including Partition Magic) have the same type of access as FDISK I don't think, in the case of USB attached to an already booted OS (I believe this is the case you are referring to), that there can be a workaround, as essentially the Windows 98 USB drivers "filter" whatever they want, if you actually boot from the USB stick, things should be different as the device is "mapped" by the BIOS. There could be (very likely limited to DOS, NOT to the GUI Windows command prompt) a workaround through grub4dos, if you can see when booting (even if booting from another device) the USB stick, if needed using the grub4dos USB drivers (aka usb --init) then the device would be BIOS mapped and (possibly, it has to be tested) available to FDISK in the DOS session, directly or though some form of remapping in grub4dos. Still the USB stick need to be connected before booting, so, even if it works it would be only a very partial workaround. jaclaz

Under DOS: SYS or FORMAT shouldn't affect the MBR anyway. FDISK should. It is very possible that *for whatever reasons* the drivers you are using mount only the volume (partition). How (exactly) are you using HxD? I mean, what are you accessing? If it is the drive letter then the MBR is not there, I don't know if under DOS/Windows98 there is an object similar to what the \\PgysicalDrive is in NT, the "Hard Disk n" in HxD seen here: https://thestarman.pcministry.com/tool/HexEds.htm I wouldn't be too surprised if your drivers or something else consider the USB stick a "removable" device and mount it only as "superfloppy", automatically "filtering out" the MBR and the sectors before the volume. jaclaz

The good question is why the original would BSOD. The "clones" may have issues (it depends on how exactly they were cloned but also how they were "managed", in the sense that if they were connected at the same time of the original you may be having issues with disk signature collisions). Almost any Windows PE will likely have issues with SCSI hardware, unless you build your own PE including the needed SCSI drivers. Boot sector analysis will anyway lead you nowhere, the issues you are having are not connected to possible bootsector issues. The 7b is due to some mis-configuration of the drivers (or of the BOOT.INI, which you seem to have corrected). The (Bios) boot sequence is: Bios->MBR->bootsector of active partition->NTLDR->BOOT.INI choices since you are loading the NTLDR and BOOT.INI, the bootsector is "good enough", as usually the two main possible issue with it are: 1) corrupted boot code 2) "wrong" geometry of device in the data and both will lead to different errors, like a hung boot with a flashing cursor (or a J or a G) on black screen, disk errors embedded in the bootsector like "Cannot fins NTLDR" or similar. The c000021a (and 0xc0000005 status) are more likely to be an issue connected to a mismatch in the Registry with a number of things, including disk signature, drive letter assignments, SCSI device ID's, in the case of (if I understand correctly) an external SCSI to SATA adapter for the SSD it could be also that the "adapter" is detected "differently" from a "native" SCSI disk. I am afraid there is little that can be done if even the "original" is not booting or gets a BSOD as you cannot use it as a reference to make comparisons and finding info online on NT 4.00 is very difficult these days. jaclaz

bbc.com redirects to https, that may be (part of) the issue. Try: http://info.cern.ch/ jaclaz