Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


jaclaz

Member
  • Content Count

    20,215
  • Donations

    $0.00 
  • Joined

  • Last visited

  • Days Won

    37

Everything posted by jaclaz

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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.
  7. 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
  8. No. No, Who knows? No. No. Cannot really say, it may depend on BIOS, chipset and even IDE cables, let alone adding in the chain an IDE-SATA converter. You can try, and test thoroughfully, if it works, it works, if it doesn't, it doesn't. Now, is the update to 240 GB actually *needed*? Or could you try using a 128 GB SSD and it would be enough? BTW, remember that you can have a 240 GB SSD and on it a 128 GiB/137 GB partition/volume on it without issues. AFAICR, nothing changed in the last 10 years or so: jaclaz
  9. So we can tentatively list on the blackboard, on the "bad" side a few kids: win32 WinClient5270 greenhillmaniac I am not so sure about adding Ximonite , if they are "private" it shouldn't be relevant. jaclaz
  10. The usual 137 GB barrier or 28-bit LBA, you need a suitable driver (not the built-in ATAPI.SYS) or UniATA: https://nt4ref.zcm.com.au/bigdisk.htm jaclaz
  11. Have you checked this? https://www.raymond.cc/blog/12-file-copy-software-tested-for-fastest-transfer-speed/ Results of tests are in a graph on page 2: https://www.raymond.cc/blog/12-file-copy-software-tested-for-fastest-transfer-speed/2/ jaclaz
  12. A good question would be - before making such a general/generic appeal - WHO actually uses mega.nz on MSFN, Anyway, only for the record: jaclaz
  13. I am not fully convinced by the last statement: in the sense that it is probably very true that common drivers do not, but it is not a non-fixable issue, as said the Microsoft own VSS drivers work just fine with 512 and 4096 bytes/sector , and on the other hand there is the Paragon driver (that - with alternate results from reports of people who used it - *somehow* works ), so I would say that "a special driver is needed on XP" (it is the same thing, with a slightly more optimistic view). About the switching between the exposed 512 and 4k sectors (on some WD disks) I am rather convinced that with the right (low level) tools it is entirely possible (in the disk controller itself or in the enclosure controller) to change some firmware settings (as after all the exposing of 512 bytes sector in 512e/512AF disk drives happens to an added - inside the controller - "translation layer") the point is that - even if we find out the undocumented command it may be enabled or disabled (at the whim of the good WD guys) and if it is enabled it is (or will in a next release in case of a new disk/encloure model ) also be supported by the WD quick formatter, but that if it is disabled you will need anyway the hypoyhetical low level tool to enable it. Once said that, there is the additional issue (that we saw in the thread about the MBR 2.2 Tib+rest up to 4 Tib formatting style, that works on 7 but dosn't on XP) of some 32 bit addresses somewhere in some key (files) that unlikely (even if the issue is found) can be patched/corrected. So, the "right" solution for bigger than 2.2Tib disks viable on XP is at the moment only about disks that expose (directly or through an enclosure controller) 4 Kb sectors, Even if it would be a bottleneck/slowing down overlay, I wonder why third party USB enclosures with a selectable pass-through vs. sector size conversion setting aren't available (or maybe they are and we don't know?[1] ) , probably due to the thinning number of XP users, and while I am at it (dreaming) I don't see how a SATA to SATA converter (similar to the el-cheapo's IDE to SATA converters) capable of the sector size conversion cannot be made. UNrelated, but not much: https://www.sabrent.com/acronis/ssc/ jaclaz [1] Possibly the ADU31ESP-X model of Addonics? https://www.addonics.com/products/adu31esp.php P.S.: I found hints - here and there - that the VLI (VIA) 701 is one of these chips that do 512->4K conversion (though I believe it is auto-switching with bigger than 2.2 Tib disk drives): https://goughlui.com/2013/10/02/experiment-usb-to-sata-bridge-chips-and-2tb-drives/ https://www.usbdev.ru/files/vli/ and the "Intenso" controller (whatever it is): https://superuser.com/questions/1271871/4k-emulation-sata-usb-controllers
  14. Yep , your way, "normal" DIR without switches and DIR /b to have "DIR /B" output is also perfectly fine . Maybe you could use (like in other grub4dos commands) the hyphen as separator for switches, i.e. -b, -s, -q, etc., otherwise something *loosely like* : set param1=%1 if not "%param1:~-1,1%==/" <do something inserting a / as first parameter> might do. this should "catch" lines where you omit the / (because in this case the second parameter (switch) is shifted to first) while keeping untouched the provided one, either a single / or a path (like (hd3,0)/) terminated with /. jaclaz
  15. den, the WHOLE point is that disk drives settings CANNOT be changed normally by the end user, if that WD 5 Tb is 4kN, it will remain 4kN, if it is 512e (512AF) it will remain 512e (512AF). SATA disks DO NOT have an OS level tool to change the way sectors are exposed, some (not all) SAS disks (please read as Serial Attached SCSI) do have such a feature. There could well be a manufacturer tool or some other third party software that can enable/disable the 4 kb to 512b translation in the controller (possibly via a TTL interface, not via the SATA, let alone via the USB), but IF it exists, I have never seen/heard of one. jaclaz
  16. Sure , that is exactly where the terminology is confusing. A 4kn disk is 4k sectored AND exposes 4k sectors. A 512e (512AF) is 4k sectored BUT exposes 512 bytes sector. Nowadays anything bigger than - say - 500 GB or maybe 1TB is internally 4k (or at least this is what the manufacturers declare). Actually 4kN disk are pretty much rare, compared with the much more common 512e (512AF). jaclaz
  17. When you copy a file on a "target" disk it is copied (if there is enough contiguous available space) as contiguous, so when you copy a whole set (contents of whole volume) on another (just formatted) volume, it will arrive "defragged". On NTFS there is an exception due to the placement of some of the filesystem metadata files "not at the beginning" of the volume, but it may affect at the most one or a few files, and only if they are extremely large and if they happen to be copied at the "right" moment. (as a side note remember how on NTFS it is a good idea to NOT fill a volume up to the brim, but rather leave some 5/10/15% unused) Once upon a time, in NT 3.51 and early NT 4.00 times there wasn't a "defrag" tool built in in the OS and the "poor man's" solution was exactly that of (using XCOPY) to copy the contents to another volume and then reformat the original and copying them back to the freshly formatted volume. What you propose is essentially a more sophisticated version of the "poor man's" solution above, with the added complication of - if I get this right - the need to phisically disconnect and reconnect the disks exchanging them and the BTW solvable, but not to be underestimated issue with Disk Signature and volume serials (unless you clear the source and copy back the data from the target, that will however take time) . It is a "nice" idea, but I doubt that its objective complication (a second "identical" - or bigger - hard disk available) is either worth it or it applies to more than a few, very particular scenarios is compensated by an increase in efficiency. What makes "normal" defragmentation a bit slower is actually the availability of enough free and contiguous space on the volume, so - in case - it would IMHO make more sense to copy to the second volume only the largest and more fragmented files until you have enough free space, then run a "normal" defrag on the source and then copy back the temporarily moved files from second disk. Another form of optimization (for the booting times only) was once (for the BartPE's and similar) to burn files on CD in the exact sequence they are loaded at boot time. On CD/DVD (please read as very slow media) this had dramatic effects. Later on USB sticks we tried the same approach with (obviously) decreased effects the faster was the stick, on (fastish) USB disk drives the boot time decrease was negligible, I have to presume that on internal disks it will be something that while it can be observed and measured by timing the process, is in practice unnoticeable. The "only" advantage that I can see in this or similar approach on NTFS is that the $MFT will be at its minimal size, but - on the other hand - on a "normally used" volume the $MFT does not usually grow much more than needed (the exception being if you create a zillion files and you later delete them). jaclaz
  18. I don't think that the ls can have the dates/times (on non-fat), it is an internal command, it would need changes to grub4dos itself. What you got now in FATLSDIR.G4B seems to me very good "as is". Personally (but it is just an opinion/preference), I would: 1) shorten the batch name to FATDIR.G4B or DIRFAT.G4B or even FDIR.G4B 2) have the (simplest) output similar to the ls output (only filenames, BUT with a filename per line) without switches 3) have the output with filename and size (and directory total) with the /z switch (I know that it would make more sense to use the /s one, but that is usually associated with the normal DIR /s, where the s is short for recursive , and on the other hand in batch variable expansion %~z1 is size) 4) have the output with added date and time with the /v (verbose) or with the /dt (date-time) switch jaclaz
  19. Side note. When you output a "DIR" listing, you'd better "format" the strings to fixed size. Usually this is done *like* (right align to length 12): set myvar=something #after the = in following line there are twelve spaces set "myvar= %myvar%" set "myvar=%myvar:~-12%" and (left align to length 12) set myvar=something #after the = in following line there are twelve spaces set "myvar=%myvar% " set "myvar=%myvar:~0,12%" jaclaz
  20. I don't know, maybe it is something specific to the WD disks. A virtual disk with 4kb sectors can be partitioned/formatted just fine in XP, at the time I put together the mentioned dual mode batch it has been tested extensively and what I could do on the virtual disk has been replicated just fine on the real disk. It is possible that you need to make the partition table manually, though, @SamirD You have to make up your mind, either most drives are 4kN OR most drives are 512AF (512e). Generally speaking, and AFAIK, disk drives up to 4-6 TB are usually 512AF, larger one are 4 kN (but not always, only as a very rough "rule of thumb") , I would say that 512AF are much more common than 4kN. Changing sector size on SAS (please read as SCSI) is only possible on certain models of disks, and the possibilities are usually between 512 and 520 or 528 bytes/ector: https://linux.die.net/man/8/sg_format https://forums.servethehome.com/index.php?threads/how-to-reformat-hdd-ssd-to-512b-sector-size.4968/ jaclaz
  21. A Sata drive may be EITHER 512 or 512 AF or 4KN . The 512 has 512 bytes sector. The 512 AF has 4 Kb sectors BUT they are translated by the disk controller to "simulated" 512 bytes sectors (the OS can see them a 512 bytes each). The 4KN (4 kb Native) has 4 kb sectors AND they remain 4 Kb (the OS sees them as 4 Kilobytes each). sector sizes CANNOT be changed (a 512 or 512AE translated to 4 kb sectors is not a 4 kb Native). An (external) enclosure with eSata or with USB connections may (or may not) provide an additional layer of translation, i.e. a 512 or 512AF disk in it may (or may not) be translated to 4 Kb sectors . We have a documented specific case of one of such external enclosures that translates from 512 to 4 Kb on the USB bus BUT NOT on the eSATA one: https://msfn.org/board/topic/173265-formatting-an-external-drive-using-different-interfaces/ https://msfn.org/board/topic/173642-mkprilog-batch-to-access-a-same-disk-under-two-different-interfaces/ in practice the eSATA is "pass-through" and exposes the disk "as is", the USB is converting sector size. Such a huge drive (14 TB) is very likely 4kN, it should be possible to partition and format it "normally", without needing the WD tool. jaclaz
  22. You need to create the ,vhd as dynamic, see here: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/gg252579(v=ws.11) OR create the fixed size .vhd as sparse file: https://xenotrope.blogspot.com/2020/04/making-vhd-files-in-qemu-that-work-with.html jaclaz
  23. The router is "self standing", it has a html server for settings, you normally don't need any particular software, *any* browser will do. Likely (check with the provider of the 4G SIM) you have to set a particular APN, compare with: https://www.blinkit.net.au/sites/default/files/blink_s3/HUAWEI_ E5573_User_Guide.pdf Or maybe you need the Huawei "Hilink" app? (some of the router settings may be "locked" by the specific vendor/provider) https://www.youtube.com/watch?v=J0D-5Zdu8mQ jaclaz
  24. As a general note, the VHD can be created as a sparse file (on NTFS fileysystem) or created as a "dynamic" VHD. This way the space taken will be little more than what is actually used (size of contents), BUT you have to consider how - since the file is "growable" and once (partially) expanded cannot be easily re-shrinked - you have to be careful to have enough free space to allow this expansion and be careful on the amount of data you write to it. The usual approach that I personally recommend is to try with a sparse file (or dynamic ,vhd) and use the system, letting the image grow, then make it a fixed size, as the needed size depends on its actual use. If you go for the "sparse" file approach you have to know that unless you take special provisions the file cannot be copied/moved unless special tools are used, in case, see: http://reboot.pro/topic/20487-any-tut-on-expanding-c-partition-on-many-ramdisk/?p=192898 while the "dynamic" .vhd is (externally) a "normal" file (and it can be "compacted" with diskpart). jaclaz
  25. As a side-side note, did you realize that by asking that (needed) single question you indirectly highlighted a whole lot of what is wrong with current Microsoft? jaclaz
×
×
  • Create New...