Leaderboard

To be as polite as possible, I cite an excerpt -- Although shocking that a single application on your machine can consume so many of your system resources, the complaint is relatively misguided, born in part by rose-tinted visions of the way the internet used to work in the olden days and by a fundamental misunderstanding of the way RAM is distributed and used within a computer. https://www.poweradmin.com/blog/why-your-internet-browser-is-such-a-ram-hog/ https://www.reddit.com/r/explainlikeimfive/comments/3r7xnc/eli5_why_do_browsers_take_up_so_much_ram/ https://www.howtogeek.com/334594/stop-complaining-that-your-browser-uses-lots-of-ram-its-a-good-thing/ Divide those tabs among two or three browsers, use one during the day for real-time market news, close it at the end of the business day, bookmark or speed-dial the tabs you don't even look at for weeks, et cetera. If you can't take the advice of closing unused tabs and stop "Page Parking", I really got nothing more for you. I feel that this discusson has "gone full circle" so best of luck to you, I got nothing more.

Of course software that officially supports Vista should not require a .NET version higher than 4.6. Higher versions should be installed only to investigate whether software that officially requires Windows 7 might unofficially work on Vista, but only a small number of success stories are known. I am now convinced that installing .NET 4.8 will break more software than it enables, and suspect that the same is true of 4.7. If @Nandor (or anyone else) is actually running Server 2008, there is something I am very curious about: This thread’s original post states that Microsoft Security Essentials 4.10.209.0 “continues to function normally on Windows Server 2008...” Is that still true? I don’t seem to recall any mention of MSE on Server 2008 since March 2017 when it was shown not to be nagging. I tried to ask @Werewolf about it in December 2019, but he has been inactive since then. MSE did not officially support servers, and I once read somewhere that special installation procedures were necessary.

More or less the issue is the following: 1) the traditional alignment was on "head", which plainly means in 99.9999% of hard disks with a geometry of n/255/63 that the "gap" from the MBR to the beginning of first (primary) volume was (is) 62 sectors (i.e. 63, the amount of sectors in a "head" minus one, the MBR). 2) the SAME gap happens inside extended partition, between the EMBR (first sector of the extended partition) and the first (logical) volume inside it, AND between the following EMBR ant the relative (logical volumes). When the alignment "(non-)standard" changed to 1 MB, these gaps became 2047 sectors (i.e. 1048576/512=2048 sectors minus one, the MBR or EMBR). There is nothing wrong with eoither of the two "conventions". The bug is in Disk Manager coming with (and likely in the Diskpart version that can be used on) XP. In order to do what amounts to changing one single byte in the MBR from 0x80 to 0x00 (or viceversa) *somehow* the disk manager "travels" the whole chain of logical volumes inside extended and when the (normally on 1 Mb alignment 2048 (2047+1) value of "sectors before" is encountered the whole EMBR logical volume entry is "wiped" (i.e. overwritten with 00's) but the MBR and thus primary volumes/partitions are not changed, of course this same happens if other (possibly any) changes in Disk Manager are attempted, not only changing the "active status", I don't think anyone made extensive tests on this. It is as if there is an implied check on current status of the disk partitioning and when something is not the expected value the entry is wiped (silently). Different (third party) tools are usually fine (particularly those that - in the same version - run on both XP and Vista/7), as generally they are written to do what they are supposed to do (change a single byte) and not to *somehow* check the consistency of the partitioning scheme of the disk at every run, but of course you cannot be sure-sure until you try the specific tool on the specific system. As said on the mentioned thread, it is not particularly difficult to find and "undelete" the logical volumes as - luckily - only the first entry in the EMBR is wiped, whilst the second (address of "next" EMBR) is left unchanged, but still it is not exactly "trivial". About speed, generically speaking when we are talking of storage devices they belong to a "bus", where controllers (and relative drivers and protocols) are involved. Notwithstanding whatever you read at the time when SATA (SATA I) came out, there was not any particular advantage in speed over good ol' ATA (ex IDE) disks (at the time already at the fastest incarnation of the bus at , i.e. theoretical 133 MB/s vs the - as well theoretical - 150 MB/s of SATA I) because the actual devices (rotating hard disks), both the 7200 rpm and the more economical (and largely used in laptops due to lower power requirements) 5400 rpm were slower than that. (to be fair there was a tiny advantage because of NCQ, Native Command Queing that was available on some SATA disks but not on ATA/IDE ones). In other words, the bottle neck was the hard disk. Then faster hard disks came out and the bottleneck became the bus or controller or protocol, so motherboards started getting SATA II. SATA II (theoretically 300 MB/s) is usually enough to deal with *any* rotating hard disks, the bottle neck is again the mass storage device. Then came SSD's (that in their SATA version largely outperform SATA II speed) and motherboards started getting SATA III. SATA III (theoretically 600 MB/s) is enough to deal with *any* (SATA) SSD. Still SSD (in themselves) can be much faster than what SATA III allows (the bottleneck is again the bus or controller or protocol) so new faster buses (for SSD's) were introduced, direct PciE or Nvme. Putting a "high end" SSD topping the SATA III standard (like 480-500+ MB/s) on a SATA II bus gives no advantage (the resulting speed will be roughly half of what the device is capable of on a SATA III bus), a "more common", cheaper SSD (with a speed like 350-400-450 MB/s) is already faster than the SATA II bus, i.e. any speed difference in the device speed is cut off by the bus capacity, i.e. leveled down to the bus max speed. jaclaz

i redid the extended kernel and managed to get more things to open

Advance Notice: due to lack of commits from upstreams, no builds will be published tomorrow.

Let's talk about partition disk alignment (if needed). It is largely a non-issue that grew much larger than needed/required. It originated from some very "narrow" cases: Find some more considerations here: http://reboot.pro/topic/9897-vistawin7-versus-xp-partitioning-issue/ particularly my post: http://reboot.pro/index.php?showtopic=9897&p=85960 An actual properly written article about the matter is lost, but you can have it via Wayback Machine: https://web.archive.org/web/20171111042401/http://www.dcr.net/~w-clayton/Vista/DisappearingPartitions/DisappearingPartitions.htm and here: There is no noticeable performance difference (read/write/access speed) on "normal" systems for internal devices, in a top class server even shaving off a few milli-micro-nano-pico seconds from each operation may make sense, but on a normal PC that is largely pointless, you can (and will see) differences on external (USB 2.0) devices such as USB sticks, CF cards and similar, as they are much, much slower and with rotating hard disks, as well, particularly the laptop ones that are slowish, not on internal SATA 3 SSD's that are usually stupidly fast. BUT on SSD it makes sense to use the "new" (since 2006 or so) MB alignment, as the net effect is slightly (and I mean slightly) less memory cells usage which translates in theory in increased life of the device, though - still - if you can make a device that (with the "wrong" alignment) will last 10 years last (with the "right" alignment) 10 years and two months it is not a life changing result, as after three to five years you will likely anyway change the system or the SSD. All in all, on internal SSD's it can be "good practice", but you MUST be aware how the disk manager of XP won't like it, a single change in the status (active/not active) of a partition makes likely that all your logical volumes inside extended will be gone. (they can be recovered, but it is not particularly smart to create the issue), so you either use the "classic" 63 sectors alignment or you shouldn't use the extended partition and logical volumes in it (or - third option - don't use the disk manager or diskpart from XP). jaclaz