jaclaz

Actually, the point is that the point isn't yours (exclusively), as it is (partially, i.e related to apply only) the same JFX and wimb had already made (and that you confirmed through your experiment). jaclaz

What was said by JFX and wimb was that wimlib was faster (or better or both) for capture and that wimgapi was faster (or better or both) for apply. A single test comparing wimlib against wimgapi for apply and showing that wimlib is slower (some 10%) doesn't seemingly change anything in what was stated earlier. jaclaz

As a matter if fact whether it makes a difference (at all) is subjective, and it depends on the context. Shaving of 1 minute out of 10 is roughly a 10% increase of speed (objectively), but if you: 1) launch the apply and go get a short walk or a cup of coffee and come back after 15 minutes it becomes totally irrelevant. or: 2) keep staring at the screen for 11 minutes, staring at it one minute less is a huge improvement. jaclaz

Queer point, since on this forum someone actually already suggested diagnostics (and diagnostics only) steps: 1) to check cooling 2) to disconnect EVERYTHING from the motherboard but the keyboard and video (which BTW would have solved your issue #1 - but probably not #2) well before hinting that it could be CPU or RAM were bad (the PSU was already changed). Besides PSU having been already excluded by the OP, it remains however a very likely cause when a computer either shuts off suddenly or fails to fully boot or starts booting than suddenly switches itself off (as it was the OP case), so that would have been recommendation #0. The next (good) ones were provided by Tripredacus: 3) check visually electrolytic capacitors for any bulging ones 4) try rotating or removing RAM sticks Your #2 case is different, and as you say "rare", you were having a beep code when attempting to boot, and it remains - since it was not reproducible - an "unsolved" case, for all we know it could have been an oxidized ground that re-gained contact when you wiggled the PS/2 connector (or even a bend in the PS/2 keyboard cable) or *anything else* that was somehow reset moving the case. In absence of a better explanation, I tend to categorize these issues as "voodoo". jaclaz

Sure , as said it was only a generic note. jaclaz

OT , but this seems - sad as it it is - like a very good reason (not-so-often cited) to release the source code/publish it, that generally speaking applies to any non-Commercial/Free program. jaclaz

Here is some reference (on BootIce versions): http://reboot.pro/topic/21956-bootice-v1332/ according to wimb/alacran 1.3.4 has an issue with UEFI. jaclaz

Roses are red (at least they were red 9 years ago). Any chance that you can start a new thread actually describing in detail what you are looking for/asking? (as opposed to reviving a not connected old-old thread with your vague references)? WHAT is "QSoft-2"? In which way is FLTK: https://en.wikipedia.org/wiki/FLTK which is a "widget GUI interface" connected with Windows 9x? Or with WINE? jaclaz

Yes and no, meaning that - for whatever reasons - that is the first localized version that survived, a NL 3.80 version actually existed: https://web.archive.org/web/20090228151900/http://www.winrar.nl/ https://web.archive.org/web/20081216004617/http://www.rarlab.com/download.htm And, as Trip stated the Wayback Machine didn't archive the file. I wonder if plainly asking winrar.nl via info@winrar.nl for a copy wouldn't be feasible. jaclaz

Myabe you are looking for FTP SYNC programs, or better for folder synchronization programs with FTP access. Examples (not necessarily doing what you want to do, and doing it the way you want to do it): https://freefilesync.org/ https://winscp.net/ http://www.beanland.net.au/AutoVer/ https://fullsync.sourceforge.io/ https://www.2brightsparks.com/syncback/compare.html jaclaz

Only a word of warning, at least historically, imagex (and by extension similarly working programs) are not entirely valid backup solutions: https://support.microsoft.com/en-us/help/935467/you-cannot-use-the-imagex-exe-tool-as-a-backup-tool-for-a-windows-comp jaclaz

Yep, now the MBR is the right file , here is the partition table: Entry Type Boot bCyl bHead bSect eCyl eHead eSec StartSector NumSectors #0 05 00 0 1 2 1023 254 63 64 167927381 #1 06 00 1023 47 49 1023 254 63 167927808 176652 #2 07 80 1023 59 61 1023 254 63 168105984 808662079 #3 00 00 0 0 0 0 0 0 0 0 As said the only possible issue is the type of the partition #1 which is now 0x06 but that could be either 0x06 (with the drive letter not assigned to it in Disk Manager) or 0x0DE (or other "hidden" type of partition). But as said if you actually need to access that DELL partition and it doesn't work you can always try to change the ID at the time you will actually need to use it (if you will ever need to use it). The partition offsets (StartSector) are a bit "queer", but nothing to actually worry about, the only thing that I would NOT dare to do (but that you have not ANY reason to ever do it, so it is only a hypothetical problem in theory) would be to change the active (Boot) status of the partition with XP Disk Management, as it is known to do "queer" things to the Extended partition (and volumes in it) when it finds "queer" values, but nothing to worry about in normal operation of the PC. All in all I would leave everything "as is". jaclaz

Good , so the "hidden" volumes inside Extended are (let's say conventionally) "normal", no, wait , let's call them completely abnormal but expected. Back to the MBR. I don't know what you are doing/did but the two files you posted are EXACTLY the SAME and BOTH are NOT the MBR (they are both the bootsector of volume C:\). Very likely you made some confusion either in reading them or saving them. I need the MBR, that is 1st sector of PhysicalDrive 0. Even in the (I know, confusing) view that HdHacker provides, in BOTH the files you posted you can easily read at the begining ".R|NTFS" and then "NTLDR" a couple of times and near the end "Press Ctrl+Alt+Del to restart", the file I need is likely (if it is the standard XP MBR) to begin with "3." and have near the end "Invalid Partition Table.Error loading operating system,Missing operating system," If you follow EXACTLY my previous instructions you cannot get the bootsector of drive C: Anyway, if you are OK with the current status, let it be. Normally (but it depends on the model, and the way the good DELL guys configured it) having the partition ID set to 0xDE is needed to use its contents the way they are intended, but it is entirely possible in your specific case that the current partition ID (either 0x06 or 0x0E) is fine and even originally it was simply removed from the drive letter assignment pool. The question (to answer wich the "old" disk MBR is also needed to make a comparison) is if what Macrium calls "Fix Windows Boot Problem" actually does, as three things are possible: 1) it simply deletes the MountedDevices key in the Registry (this way the hive will be re-populated by Windows at next boot, taking into consideration the new Disk Signature) [1] 2) it restores the original Disk Signature [2] and doesn't touch the Registry 3) does - additionally to either 1 or 2 above - some automagic changes on the MBR partition ID's [1] jaclaz [1] and then the disk is not anymore a "clone" [2] and then the disk may be a "clone"

That is a DELL utility partition. Your (only) system and boot volume is seemingly the C:\. Anyway you have (why) an extended partition (before the D: and C: volumes) containing two logical volumes with an unknown tag. Maybe after all Macrium didn't do very good work (or maybe the source hybrid drive was a mess to begin with?). The MBR is a Master Boot Record, and it is stored on the first absolute sector of the disk (or LBA 0). It is made of four relevant parts: 1) boot code (that is executed by the BIOS when you boot) 2) Disk Signature (on NT based systems which is what Macrium fixed under the generic "Fix Windows Boot Problem") 3) the Partition Table, consisting of 4 entries, 16 bytes each, each one being able to contain the addresses of up to 4 primary partitions or up to 3 primary partitions and 1 Extended partition (this latter can contain more than one logical volumes) 4) the "Magic Bytes" 0xAA55 Now, entering the details of item #3 above, each partition entry is composed of 4 fields: f1) Partition ID (this indicates to the OS which type of partition is the entry relative to, an extended is either 0x05 or 0x0F, Primary volumes have an ID that usually corresponds to the filesystem applied to the volume f2) CHS start adrress values (in Cylinder/Head/Sectors) f3)CHS end address values (in Cylinder/Head/Sectors) f4) LBA start address value (in sectors) f5) LBA extension value (in sectors) Now, normally a DELL Utility partition like the one you have is a small FAT 16 volume, and such a a FAT 16 volume has normally a partition ID of either 0x06 or 0x0E, BUT many OEM change the partition ID for their recover/utility volumes to an ID that the OS would consider "hidden" and thus refrain from assigning a drive letter to it (i.e. the volume is not mounted/visible in Explorer). DELL uses normally for these partitions the 0xDE partition ID. It is entirely possible that Macrium, while doing what it calls "cloning" or while doing what it calls "Fix Windows Boot Problem", decided that the volume after all was a plain FAT 16 one and changed the ID back to either 0x06 or 0x0E. Fixing this is simple and can be done in no time, What is perplexing is the extended partition containing: 1) a 78 MB FAT volume 2) a 80 GB NTFS volume without any drive letter assigned to them Only you can say if this is "normal" (it is entirely possible that the 80 GB . In theory you should: 1) switch off the PC 2) remove the new hard disk 3) re-attach the old hybrid hard disk 4) boot the PC from it 5) take a screenshot of disk manager corresponding to the one you just posted Since views on the disk manager are not "exact" data, you should make a direct copy of the MBR when booted from the old hard disk, then reverse the procedure, detaching the old hard disk and re-attaching the new one, etc. IT IS VITAL THAT THE TWO CLONED HARD DISKS ARE NEVER CONNECTED AT THE SAME TIME TO A PC RUNNING A NT BASED SYSTEM as this will create a Disk SIgnature conflict and the NT OS will silently change the Disk Signature of one of the two devices. To make the copy of the MBR use this simple tool, HdHacker: http://dimio.altervista.org/eng/ You want to choose "Physycal Drive (MBR)" (and 0 in the dropdown on the right, should appear automatically) and below "First sector (MBR)". leave "number of contiguous number of sectors to read" set to 1 then "Read sector from disk" then "Save sector to file" Save them as oldhd.mbr and newhd.mbr to a USB stick (so that you can connect it to the PB both when the old hard disk is in and later when the new hard disk is in the PC), then compress them together in a .zip file and attach the archive file to your next post or upload it *somewhere and provide a link to it. jaclaz

Well it is not that difficult to experiment manually. Just use a "normal" format command (without applying a label). See what comes out by default. Then (if needed) increase the Reserved Sectors value (in the bootsector). Then (if needed) increase the FAT size (again in the bootsector) . Then copy the first sector of the first FAT to the shifted beginning. (or just write F8 FF FF 0F FF FF FF FF FF FF FF 0F to the shifted first sector) Unmount and remount. Run CHKDISK /F on the volume, reply no to saving lost chains. As a side note, and curiously enough, the backup bootsector is not updated by running CHKDSK, but the second FAT table is alright. Quick experiment with an IMDISK volume 50 MB in size: BEFORE: Changed with Tiny Hexer (only "random" changes without any calculation behind): Reserved sectors 32 -> 34 Fat Size 788->800 And written F8 FF FF 0F FF FF FF FF FF FF FF 0F to sector LBA 34 Unmounted and re-mounted, AFTER: jaclaz

I love standards, there are so many of them ... jaclaz

@dencorso The "label" in the bootsector is in practice ignored by most OS's, what counts is the label (as an effect of the label command or similar) that is - and here comes one of the ifs you appreciate could be 0x08 or 0x28 depending on the specific OS formatting the filesystem. https://msfn.org/board/topic/154648-dos-format-b-and-label/?tab=comments#comment-984466@Mathwiz @Mathwiz There is a post I made to try and clear the matter ( the good MS guys sometimes are not being capable to write plain English): http://reboot.pro/topic/16783-rmprepusb-faster-fat32-write-access-on-flash-memory-drives/?p=153550 The point about the label applies only if the label is applied first thing after (or during) formatting (or however before the number of files entries fill cluster 2), it applies in the case of RMPREPUSB, but if you do not use the label or apply it after having copied to the filesystem a sufficient number of files of course it won't be inside first cluster (of the file and directory data region). About FAT size/alignment, there is no rule written in stone that the FAT area must actually correspond EXACTLY to the amount of FAT entries needed. Imagine a (completely hypothetical) filesystem with 1000 clusters. You will need no less than 1000 32 bit (or 4 bytes) entries in (each) FAT. So roughly (for the sake of simplicity let's ignore the leading "lost" bytes) you need 1000x4 bytes 4000 bytes for the FAT, but you cannot have less than 8 sectors, i.e. 7*512=3584 < 4000 < 8x512 = 4096, which means that you have 96 more bytes than needed. What if instead of an 8 sectors FAT you use instead a 9 sector (one)? Nothing, i.e. you will have 512+96=608 excess cluster address space (that will be ignored just like the 96 in the previous example) and the volume/filesystem will work just fine. So, if the "normal" format will produce - say - a 785 sectors sized FAT, nothing prevents you from "extending" it to - still say - 800 sectors, thus making it an exact multiple of 8 sectors. This way, if the "Reserved sectors" are already a multiple of 8 sectors, the first FAT is also a multiple of 8 sectors and so is the second FAT, with the result that everything, including the "file and directory data region" are aligned to 8 sectors. But, since there are 2 FATs, you can only have cluster 2 aligned (and not cluster 3, i.e. jumping over the cluster where the "label" and the actual "virtual" root directory is), the only way would be to create a given number of (fake/empty) directories to fill cluster 2 and 3 and have the actual files start on cluster 4 (which would result in a "mess"), of course if cluster size is compatible with the alignment that doesn't matter. jaclaz

Well, to be picky as usual, no. In theory the "perfect alignment" in FAT32 (in volume) needs TWO "corrections": 1) Number of reserved sectors to align the first FAT 2) Size of FAT 1 (multiple of alignment) to align 2nd FAT and contents What is still up to debate is whether to align contents or "contents - Label" when both are not aligned with the same value and the actual alignment value to choose (that may offer better performance if aligned to the "erase page size" of the specific device. With exFAT, the equivalent of #1 is represented by the FatOffset Field (i.e. both touching the reserved sectors in FAT32 and putting a value in the FatOffset field in exFAT result in shifting the beginning of the FAT) And the equivalent of #2 is the ClusterHeapOffset. Still in theory in exFAT there is ONLY one FAT (in TexFAT there are two, as well as two bitmaps): How actually that is implemented in practice might be an entirely different topic. jaclaz

I don't think anyone tested this approach on exFAT, where most probably it is not needed (as it is not needed for NTFS, though for dfferent reasons). But from these tests here: https://www.flexense.com/fat32_exfat_ntfs_usb3_performance_comparison.html it's not like there are any sensible increases in speed with exFAT. And BTW we don't know if the FAT32 in those tests were "properly" aligned or not,, most probably they were not, so if you take into account the recorded increases in speed obtained by properly aligning the FAT32 volume, the exFAT will come out as slower than FAT32 (and it has already been found slower than NTFS in most cases). As a side-side note the specifications for exFAT were just released by MS: https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification Since there is actually a FatOffset Field and a ClusterHeapOffset Field : it is very likely that (at least using MS tools) exFAT volume contents are properly aligned already. Most we had till now was some reverse engineering (just for the record): https://www.sans.org/reading-room/whitepapers/forensics/reverse-engineering-microsoft-exfat-file-system-33274 that (understandably) didn't enter in the actual use of the alignment fields and areas. Also a filesystem that may be worth a couple tests is the rarely mentioned UDF, which is built-in since Vista, it seems like noone ever properly tested it against FAT/exFAT, the only one I could find: https://www.sami-lehtinen.net/blog/exfat-extended-file-allocation-table-vs-udf-universal-disk-format-file-system-for-flash-drives seems leading to much faster reads but slower writes, so I guess using the one or the other really depends on a case by case basis. jaclaz

Yep, what you report is on the "high" side but in any case the improvement is substantial. In the topic that more or less started it all JFYI: pointertovoid registered smaller increases, though at the time he did it manually, whilst with Steve6375 (Author of RMPRPUSB) several slightly different approaches were tested at the time (and of course the fastest one chosen), again JFYI: http://reboot.pro/topic/16783-rmprepusb-faster-fat32-write-access-on-flash-memory-drives/ jaclaz

I put together the usual half-@§§ed set of batches+spreadsheet, find the whole stuff attached, create a new folder, and uncompress the contents of the archive to it (to work with new data you will need to copy the pitlist.mps and batlist.mps to the TinyHexer scripts\Structure Viewer folder) In folder "NewFiles" there are: Batters2019 Pitchers2019 Address2019 files which I re-generated to see if the procedures work. Basically I took "Address2016" and regenerated, re-ordering them according to their position in Address2016 the Batters2019 and Pitchers2019, then re-created a new Address2019 file re-indexing the new Batters2019 and Pitchers2019. In practice the result should be the same teams as in the 2016 files, but "more ordered", let's call the new files "defragmented" . At first sight the files seem correct (though due to the way the cmd generated by the spreadsheet there are still some "holes") but the only way to know is to try the files in the program. I split the Batters and Pitchers (both the "old" and the "2016" versions) in single entries (single files, stripped of the "prefix" or Team#) and the spreadsheet "MkNewFiles" creates a batch (in column N, copy and paste to MkNewFiles.cmd) that reassembles them and creates in column J the new address file (copy and Paste to New in TinyHexer selecting "Hex text"). jaclaz Trip_Baseball.7z

No, meaning that there is no "direct" link between an upgrade/update and a hard disk failing. What may happen, in the case of a "huge" update/upgrade, could be that the hard disk works continuously for some time and heats up, but the same happens if you cause *any* "sustained" hard disk activity, like - say - a whole disk defrag (if the filesystem is seriously fragmented) or creating a whole disk or volume backup/image. Not to say that definitely it in your cases they were coincidences, but they actually were coincidences. If the machine is the same where another 2 hard disk failed in 2015, you may want to check the temperatures the hard disks reach[1], as often there is a correlation between hard disk failures and their (high) operating temperatures, but again it is little more than a statistical correlation, hard disks largely tend to fail "suddenly" for "unknown" and "random" reasons (in 99.99% of the cases noone spends the huge amount of money needed to examone a failed disk, and even if the disk is actually examined to attempt to recover data, rarely the actual cause is investigated and a definite reason why found). jaclaz [1] in some cases adding a fan bringing some "fresh" air to the drives bays is a good idea

What Eve Wang (MSFT CSG) wrote, is (blatantly) incorrect AND the article she linked to contains NO detail whatsoever about the possibility to redistribute a PE (let alone differentiating between commercial and non-commercial purposes). In the same thread Tripredacus replied, stating correctly the situation: in simpler words, a PE has NEVER been redistributable, but it was available for a few years in a "special" redistribution agreement (for a fee) intended to allow selected Commercial software firms to redistribute it as part of their install/recovery/whatever software. Since several years this special redistribution agreement program is over. Provided that the MS' EULA is an actually enforceable and legally valid document (which is something I personally doubt, BTW) it is the document that regulates the license of the software, and the EULA explicitly states how ONLY the "samples" in the ADK are redistributable. But I will make anyway an example of how I personally read the reply by Eve Wang (MSFT CSG) : Q: Do elephants fly? A; Yes, but only on wednesdays, if there is a full moon, and here is a nice poem about elephants: https://www.poemhunter.com/poems/elephant/page-2/36807454/ jaclaz

@bphlpt Good , and do you believe that a Windows 10 PE [1] is actually redistributable? I mean, all these years spent with Bart's PEBuilder and Winbuilder, were them totally wasted? Now would you tend to trust more Eve Wang (MSFT CSG)[2] or - say - Tripredacus?: https://social.technet.microsoft.com/Forums/Lync/en-US/050e7a61-4ca6-42eb-865d-7eaddff90ddb/is-windows-pe-for-windows-10-redistributable?forum=winserversetup Of course the moment the EULA for the ADK (or a separate one for PE) will have something to the effect of "You are free to re-distribute any of the binaries included" or a REDIST.TXT with a full list of the files, things will change, right now the relevant part is: https://forum.acronis.com/sites/default/files/comment_attachments/2016/11/397321-134896.pdf jaclaz [1] or - for that matters - *any* Microsoft binary not expressely released as redistributable [2] you will find many similar questions on social.msdn.microsoft.com invariably replied to with non-answers or answers by clueless people (RCSAKIT PHART), I pointed you to one answered by someone we can trust

Very good (though obviously I only understand half of the baseball terminology ). But the point is (now that we have defined and know exactly what those data are) do we (actually you) *need* to edit them? Or they can be treated like if they were - say - a block of data representing the date of birth of the player (which you won't change/touch at all )? Now that we know how the contents is arranged in records, Managing them with a spreadsheet and a couple command line tools should be straightforward (maybe slow, but simple enough) Jaclaz