jaclaz

Sure, the threats you listed are very dangerous, and it is very common to be exposed to them, as an example I have all the PC's at home running XP connected to my domain server to which I often RDP into from my office computer to download (from a set of NAS accessed via Samba) samples of my collection of lolcats. The only good thing is that I don't use Acrobat Reader XL. jaclaz

They do, I provided a link to a reported way to do so (small FAT32 partition+main partition). There may well be this (or that) artificial limitation due to specific UEFI implementations, of course. And of course the good MS guys did whatever they could to prevent you from using MBR style disks with UEFI, so thinking that anything outside the MS (stupidly) recommended paths with MS tools only is unthinkable. To do anything out of the ordinary you need increasingly more complex procedures, third party tools and what not, and little by little they are forcing us to recognize that what they say is the only way. jaclaz

Maybe we should have a COO (Certificate of Origin) besides the COA (Certificate of Authenticity) mandated by Law. The (nonsensical) issue would remain about the political orientation of the Author (and of all the contributors) of softwares, only as an example I suspect that there are many Russians among the contributors of Linux, and also a large number of Communists, regardless of their nationality. jaclaz

It is not like jaclaz has any agreement in his contract with MSFN (nor with any other third parties) to provide comments on each and every post. Unlike you, he didn't mention downvotes, I only tried to tell you how they don't exist and that you were not caring about something that does not exist. I also provided (free of charge) the results of consulting my crystal ball, and - if accurate - that will be good news for you, at least two upvotes on that post. That's it. jaclaz

Sure, no warez on MSFN. But the referenced post has no mention of warez, it is only about the nationality of the Author and how in your country you have the right to have goods labeled with the country of manufacture/origin. jaclaz

You won't get any downvote for this post, simply because there is no way on MSFN to downvote. My crystal ball, which is unfortunately needing some tuning, tells me however that your post will soon get two upvotes or likes (probably by Saxxon and Dixel). jaclaz

I do not understand your question, then, maybe it is a moving one. You seemingly asked a question about a problem that you already solved, both the question and the solution you found do not need the use of RegEx expression. Unfortunately I cannot follow you on the "I have to use" and "All other tools". If you have to use JREPL.BAT, it has a dedicated thread on another forum, ask your questions here: https://www.dostips.com/forum/viewtopic.php?t=6044 it is much more likely to find there people familiar with that tool. RegEx is already - by itself - complex enough, the ways each and every tool implements it may (or may not) be non-standard. TIme for a distraction: https://xkcd.com/1171/ jaclaz

What has RegEx to do with this? You are looking for a very definite text, you can use gsar for this: http://tjaberg.com/ or FART: https://fart-it.sourceforge.net/ Otherwise you might want to try using SED (much more powerful but not as easy to use), a windows port is here: https://github.com/mbuilov/sed-windows A number of other tools/utilities do exist, but - generally speaking - they won't manage gracefully the CR+LF (the one after the [SourceNames.x86]). jaclaz

That's good as in the average you compensate a 60+ year old keeping it around 50 or so. jaclaz

A few notes. Strictly speaking, there is no real need of GPT style disk for UEFI booting, though the good MS guys did introduce a few arbitrary limitations like preventing you from installing on a MBR disk (and it is entirely possible that they added a definite limitation to Windows 11) , but UEFI in itself is compatible with MBR style disks, in this cases it will consider as ESP partition the active (FAT32) partition on the disk, example of what can be done: http://reboot.pro/index.php?showtopic=22482 The requirement for processor matching is instead in the UEFI specs, so you can only install/boot a 64 bit system on a 64 bit processor machine (or a 32 bit on an extremely rare 32 bit processor). There is no "alternative" bootloader (AFAIK) to the bootmgr.efi, so it (and a valid BCD) are always needed, there are various bootmanagers/bootloaders/shims that can be booted "before" the bootmgr, but the final steps all go through bootmgr and the (valid) BCD that call the winload.efi that then proceeds to boot the OS. Specifically for Vista, its support for EFI/UEFI is reportedly since Vista Beta 2 Build 5384, but even in 7 EFI/UEFI support is far from ideal, and you need additional tricks to boot on newer UEFI systems, like using UEFISeven: https://vinaypundith.github.io/windows_7_efi_guide/ https://msfn.org/board/topic/183033-list-guide-list-of-hardware-that-supports-windows-vista-uefi-boot-and-how-to-boot-vista-with-uefi/ In other words, YMMGV. jaclaz

Hmmm, I don't think that version really qualifies, that could even (slowly ) run on "Vista Capable" hardware (unlike all the "real" versions of Vista): https://www.nytimes.com/2008/03/09/business/09digi.html Seriously, besides the grossly underestimated hardware requirements (that made in most cases the upgrade process on existing hardware result as a slow as molasses Operating System) the (initial) lack of drivers was a nightmare, and also (cheap) new hardware with the Vista Ready sticker was - generally speaking - low performing (again because the minimal requirements were - as it is traditional with MS - way too optimistic, the rule of the thumb, since NT 4.00 times, has been that you need double the processor speed, and four times the RAM to get a decently running machine). jaclaz

Maybe the expectations were too low. The article you linked to is an opinion by an analyst written while Vista was made available, january 2007, compare with these (written two years after launch): https://content.time.com/time/specials/packages/article/0,28804,1898610_1898625_1898627,00.html https://www.technologizer.com/2009/08/10/sixteen-reasons-the-windows-vista-era-never-quite-happened/ Vista was not a success for Microsoft (no matter if rightfully or wrongly people did whatever they could to avoid it). Windows 7[1] release was accelerated as much as possible, hoping to replicate the success of XP. jaclaz [1] please read as Vista SP3

Well, Seagate hard drives 40-120 Gb of those years (some 20 years ago) were not exactly the most reliable anyway. It is not like NTFS writes in a same place whilst FAT32 writes in a different one, there is a setting in NTFS to NOT update last accessed data/time that eases the writing on the hard disk, but apart from that it is not like there is that much excess writes in normal operation between NTFS and FAT32, NTFS is surely more hard disk intensive, but all the world has used and is using it in the last 25 years or so and the sky hasn't fallen on our head (yet). exFAT is (IMHO) not a particularly "good" filesystem, but for storage/backup it is just fine, and it is "lighter" on disk than NTFS (in the normal version, AFAICR there is a "transactional" version used on some devices that may be disk intensive). I cannot really see a difference between (should you be the target of an attack) someone encrypting your filesystem (using NTFS/EFS) and just encrypting your files (like most ransomware do) or plainly deleting/overwriting them, as a matter of fact, though it is not given that you can decrypt EFS, at least with it you have some chances, whilst with a "random" ransomware encryption it is much more probable that the decryption is impossible or, if luck is on your side and a method of decryption is found, it takes usually months or years to be available. Stretching the size of FAT32 volumes the way you are doing it is risky because it is largely unexplored territory, and there is always the possibility of an implementation bug that unexpectedly destroys the data. The issue, as often happens, is with your need (or desire) to have these gargantuan[1] volumes and keep compatibility with 2K and/or XP, otherwise you could make more (smaller, please read as "of reasonable size") FAT32 volumes, the chain of logical volumes inside Extended partition has a few limitations/us more prone to possible corruption (though normally a broken chain can be easily repaired), if you could migrate to GPT you would have 128 primary partitions available. jaclaz [1] You know, I've always liked that word "gargantuan", I so rarely have the opportunity to use it in a sentence.

Obligatory XKCD: https://xkcd.com/612/ jaclaz

The amount of files in a directory is limited (and this is actually the "only" reason why it is possible to install Vista on FAT32 but not Windows 7, unless the contents of some of the WinSxS sub-directories is reduced), JFYI: http://reboot.pro/index.php?showtopic=19643&p=182961 the limit is not "fixed" as it depends on the length of filename. So in theory you have 65,536 (2^16) or 65,535 (2^16-1) entries available, but each file (unless it is a "kosher" 8.3 name) will take at least 2 of them, that makes in practice the number be below 32,768, with (nowadays common) stupidly long file names it is not so rare that you have (as in the \winSxs\Manifests example above) a limit around 7,000 files. Personally I wouldn't use a cluster size bigger than 32 kb (but then I wouldn't also use such large volumes in FAT32). jaclaz

In theory the limit of a FAT 32 volume is given by the number of addressable clusters in the FAT table(s), notwithstanding the name, of the 32 bits of a FAT entry, only 28 can be used, which makes the limit at 2^28-1=268,435,455. So: 4K clusters= 268,435,455*4,096=1,099,511,623,680 8K clusters= 268,435,455*8,192=2,199,023,247,360 16K clusters= 268,435,455*16,384=4,398,046,494,720 32K clusters= 268,435,455*32,768=8,796,092,989,440 BUT the sector count (in the BPB) is a 32 bit field, so the limit is the number of sectors 2^32-1=4,294,967,295 512 bytes sectors=4,294,967,295*512=2,199,023,255,040 4096 bytes sectors=4,294,967,295*4096=17,592,186,040,320 (which are the same limits of the MBR style of partitioning). In practice, each and every OS (and also each and every MS or third party tool) may support only volumes up to much smaller sizes. Creation of a FAT32 is (in Windows) artificially limited to 32 GB by the good MS guys, and there are reasons for that, but even if they were a bit too "cautious" (probably actually attempting to "push" for NTFS adoption) the cluster sizes adopted for the various ranges make sense[1], so the 32 KB cluster size for volumes over 32 GB in size should be respected. Making volumes/partitions larger than 32GB (manually or using third party tools) is possible, but it may well (as you just found out) lead to issue with this (or that) OS or tool. At the time Dencorso reported testing FAT32 partitions on different operating systems successfully, but he put his limit to around 232 GB: https://msfn.org/board/topic/118623-clone-easily-windows-98-and-xp-in-the-same-computer/?do=findComment&comment=866879 so, roughly 8 times the MS limit (using 32 KB clusters), in order to limit the number of clusters to 6-8 millions, he also reports how the Windows ME (which came out around the same time as Windows 2000) has a limit in CHKDISK around 27 million clusters. Your volumes, being bigger and using (too) small sized clusters have 3 or 4 times that amount of clusters, I am not surprised that Windows 2000 has issues with them, maybe not at the same 27 million, but low enough to cause the issues, and there could be other issues related to cluster size for boot volumes or some other implementation limit. The 760 GB volume has around 99 millions clusters (8192 bytes each). The 1208 GB volume has around 79 millions clusters (16384 bytes each). The 1208 GB volume that you tried to make with 8192 bytes clusters would have around 148 millions clusters, as well I wouldn't at all be surprised if in XP there is a (possibly higher than in 2K) limit to the number of clusters and/or some other limitations. Besides these (evident) issues, there may be other ones, that could happen only when using this (or that) MS or third party tool. You should try using the (recommended for volumes larger than 32 GB) 32 kB clusters, if there is some limit in number of clusters, by lowering it you may be able to have your (very large) volumes working fully. jaclaz [1] basically the larger the cluster size, the smaller the FAT is, thus the faster it is to parse it to access files. while - if you have many small files - a large cluster size implies having more space wasted on disk (which is not a real problem anymore)

You don't need a hdd (or ssd) driver (they do not exist, all hdd and ssd's are in themselves "standard") you need a driver for your specific motherboard chips (usually the missing piece that causes the 0x0000007b bsod are the drivers for the PCI SATA bridge and/or the IDE/SATA/AHCI controller). Post the exact specifications of your laptop/motherboard, so (if a suitable driver for Vista exists) members may be able to point you to one. You can try (if your BIOS has this option) to install in IDE compatibility mode, though in this mode you will probably loose much of the increase in speed the ssd may offer. If a suitable manufacturer driver cannot be found, you may check/try the UNIATA driver: http://alter.org.ua/en/soft/win/uni_ata/ jaclaz

To be picky (as I am) it depends on which GUI path you take, the same thread you mentioned shows also the Settings->Recovery->Advanced startup uses "firmware" like the command line, and BTW the "Advanced Options" -> "UEFI firmware settings" you are referencing is "backwards" (it only tells you that the PC will restart in the "final" screen). It's 2:1, command line+GUI1=firmware vs. GUI2=UEFI firmware, democracy at its best . All is normal and the usual way the good MS guys are historically used to mis-label things in their OS's (and documentation). As a side note, the given link: https://www.tenforums.com/tutorials/5831-boot-uefi-firmware-settings-inside-windows-10-a.html says, (last choice about shutdown /r /fw) : so maybe it is not just UEFI, but also BIOS (i.e. firmware is more appropriate) It would need to be tested (by someone with two installs, one in BIOS and one in UEFI or with similar machines set in the two modes to be able to make a comparison), I think that the feature uses some specific UEFI (surely described on one of the more than 2,200 pages of the specifications) parameter/switch/whatever but for all I know it could simply stuff the keyboard buffer with F2's (or whatever key is used to access the firmware at boot time). jaclaz

The /fw switch is shorthand for firmware, but what is not said anywhere is that they intend UEFI, and not BIOS (though it may work for UEFI in CMS mode ) it is very likely that it was introduced post Windows 7. You just run: shutdown /? to list the available switches to the command. Should be like this (no /fw switch present): https://www.computerperformance.co.uk/windows-7/shutdown-command/ jaclaz

@Dixel I think you are confusing matters: 1) how to batch rename files 2) how to open a command prompt when in an explorer window in the shown directory/folder To batch rename files (#1 in the above list) there are of course working command lines and/or you can write a dedicated batch, BUT there are a number of dedicated third party tools with more (or easier, or enhanced) features. My remark and suggestions were ONLY and EXCLUSIVELY about how to open a command prompt in an explore window (#2 in the above list). For that (open a command prompt in an explorer window, #2 in the above list) there is NO available function in Windows XP, there is something similar (and I later posted a link to an article on petri.com about how to use the existing feature) that however opens a command prompt in a selected directory, NOT in the currently displayed one. To do the latter (open a command prompt in an explorer windows in the currently displayed directory) there is the need for a third party tool, and I posted a link to two of them, one tested and used successfully by me for over 10 years, and another one, not tested by me, but said to be working just fine, more suitable to later versions of windows. jaclaz

@AstroSkipper Take it easy. Using another tool instead of Explorer (like you do with Total Commander) is of course perfectly fine, I only posted a reference to a tool that is useful when running Explorer, working "correctly" unlike the very common suggested workarounds, like these ones: https://petri.com/add_command_prompt_here_shortcut_to_windows_explorer/ that are described as "command prompt here" while they are actually "command prompt in the selected directory". jaclaz

But on Vista you probably want one that is compatible with UAC (not tested by me): http://code.kliu.org/cmdopen/ jaclaz

That difference is likely the one between Gb and Gb: https://en.wikipedia.org/wiki/Gibibyte#Multiple-byte_units Disks sizes are usually calculated with the 1000 multiplier, while MS uses the "real" 1024 multiplier, (roughly) a disk 500GB is seen as 465 Gib and a 512 GB as 475 GiB, the exact numbers depend on the specific disk. jaclaz

In Windows XP you need a dedicated tool (shell extension), the one that works (I am running it since many years) is this one: Background Command: http://www.roggel.com/NGNeer/BackgroundCMD/index.shtml It provides a proper "command prompt here" (unlike other "solutions" that offer "command prompt in the selected directory"). jaclaz

So, if I get this right, for the next 14 years, ME users are fine? jaclaz