jaclaz

The file is downloadable only if you click on the link from the given page, not by directly clicking on the link (on another page, like this thread) to the file, it is - i believe - a security feature to avoid excessive (automated) downloads.. Yes, nlite should work fine, though it may depend whether the main OS install files have been fiddled with: https://msfn.org/board/topic/181433-nlite-slipstreaming-sata-drivers-for-windows-2000-sp4-install/ But check also the WinRAID guide: https://winraid.level1techs.com/t/guide-integration-of-intels-ahci-raid-drivers-into-a-windows-xp-w2k3-w2k-cd/25310 jaclaz

There are no such things as "UEFI HDD" or "normal HDD", there is GPT style of partitioning and MBR style of partitioning. BIOS is ONLY compatible with MBR style[0]. UEFI is (should be) compatible with BOTH MBR and GPT style, though often GPT is forced by some artificial limitation by either the firmware or the OS or both. https://en.wikipedia.org/wiki/EFI_system_partition The normal BIOS booting sequence (on MBR) is: BIOS->MBR code->PBR of Active partition in MBR partition table->PBR code-> OS loader or bootmanager The UEFI booting sequence (on GPT) is: UEFI->EFI loader on ESP (normally FAT32[1]) which has its own ID of C12A7328-F81F-11D2-BA4B-00A0C93EC93B The UEFI booting sequence (on MBR) is: UEFI->EFI loader on partiion (normally FAT32) that is considered the ESP (or EFI System Partition) with an ID of 0xEF (some wrong implementations may want to use the "generic" 0x0B or 0x0C[2]) jaclaz [0] though there are tricks/workarounds to boot GPT from BIOS, besides hybrid MBR's there are a few ways here: http://reboot.pro/topic/19516-hack-bootmgr-to-boot-windows-in-bios-to-gpt [1] though according to the specifications "FAT" is to be used, so also FAT12 and 16 should be possible [2] An example (solved): https://github.com/raspberrypi/rpi-eeprom/issues/126

The drivers are on his site, it is not that easy to navigate it, as it is mainly in Japanese. Is this the driver you want/need? (Intel Matrix Storage driver): https://win2k.org/blog/2009/04/17/813816 https://win2k.org/cgi-bin/dl.cgi?file=iata76_cd2kh.cab jaclaz

That's another thing, it is a "new" level of the UEFI specifications (UEFI Class-3), this class of hardware didn't exist in times of VIsta or 7, so it is not at all surprising. The surface/surface PRO installing of Windows 7 is talked about on another thread: https://msfn.org/board/topic/184183-how-can-i-install-windows-7-pro-or-ultimate-on-a-microsoft-surface-go/ As said before there may be "tricks" around that limitation. jaclaz

OT, good ol' joke about engineers and mathematicians (and physicists): jaclaz

You will need to start adopting mount points, they are possible since Win2k version of NTFS came out: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc938934(v=technet.10) .https://www.itprotoday.com/windows-78/magic-mount-points My personal advice is to have on each physical disk a (can be very small) NTFS volume with the mount points of other volumes on the same disk, though mount points can of course be made cross-disk it is easier if they are self-contained. jaclaz

The post above yours is about removing entries in the Registry about a service, not about deleting files in a (protected by some system integrity provision) folder: https://ss64.com/nt/sc.html jaclaz

Though it doesn't seem at all like there is a RegEx expression anywhere in that. Anyway, the only important thing is that you are happy with your solution. jaclaz

NTLite has its own support forum/community board since several years: https://www.ntlite.com/community/index.php and it is essentially a commercial software, unlike the previous Nlite (which - years before - was largely developed and supported on MSFN), no surprise that is not (anymore) talked about much here on MSFN (I believe that many MSFN members that are NTLite users are also members of that official support board). jaclaz

Sure, but those businesses should (in theory) have experts capable of mitigating them, no need to (further) scare to death common users about vulnerabiliities they won't ever experience (simply because they don't use the affected services/programs). If we want to scare them, as general advice, we have the (evergreen) opinion by Armand Gracious : https://www.dedoimedo.com/computers/experts.html 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